Online Traffic‑Based Functional and Performance Verification System for Order Processing

The article introduces a practice solution that uses live online traffic to verify the functionality and performance of a refactored order‑processing system. It explains how traffic is intercepted, recorded, stored, replayed, and pressure‑tested, providing a reference architecture for similar needs.

Business Background : The Baichuan project consolidates multiple order‑entry points (ECLP, various BPs) into a unified system. Different entry points use JOS HTTP requests, JSF calls, or MQ messages. To minimize risk during traffic migration, a full‑scenario traffic verification system is required for both functional (AB) and performance validation.

Terminology : The system consists of four core modules – traffic proxy, recording service, replay engine, and pressure‑test engine. Key concepts include traffic diversion, recording, replay, traffic cut‑over, and AB verification.

Design Idea : MCube determines whether to fetch the latest template based on cache status, loads the template into a view‑tree, resolves expressions and custom events, binds them, and finally renders the view.

System Design – Overall Architecture

The architecture comprises a traffic proxy that captures requests via JSF filters or AOP, a recording service that persists traffic to Elasticsearch, a replay engine that invokes target interfaces using generic JSF calls, and a pressure‑test engine that drives multi‑machine, multi‑threaded load generation.

Detailed Design

4.2.1 Traffic Proxy : A generic proxy intercepts traffic and forwards it asynchronously via MQ to the recording service. For JOS traffic, a virtual service with the same interface as the original is deployed, allowing seamless traffic diversion.

4.2.2 Traffic Storage : Recorded traffic is stored in Elasticsearch. Each record is identified by a task‑specific primary key (e.g., RT7625109167934456_1 ) and contains the request body, arguments, and metadata.

Example record body:

{
  "args":[{"fakeNo":"fakeNo001"}],
  "argsType":["cn.jdl.baichuan.router.replay.contract.domain.fake.FlowFakeRequest"],
  "attachments":{"traceId":"8112206384546625","type":"1"},
  "clazzName":"cn.jdl.baichuan.router.replay.contract.service.RouterFlowFakeService",
  "methodName":"match",
  "resultObj":true
}

4.2.3 Traffic Replay : Supports single, batch, and task‑level replay using JSF generic calls, avoiding direct dependencies on business‑system JARs. A comparison service can be configured to compare inputs and outputs of old and new interfaces for functional validation.

4.2.4 Traffic Pressure Test : Implements a master‑slave architecture where the master distributes load tasks to slaves. Data is allocated to threads using an average‑plus‑remainder strategy with a sliding‑window mechanism to ensure each thread processes a distinct subset of records.

Business Practice : Before cutting traffic from the legacy ECLP‑SO system to the new order center, the verification system records live traffic, replays it against the new system, and compares results. Only after successful functional verification is the traffic fully switched, dramatically reducing migration risk.

The article also mentions the system’s application in product‑center validation, where real online traffic is used to test complex product‑verification services before release, enhancing stability and safety of production deployments.