Baidu Testing Middleware: Architecture, Design Principles, and Application Scenarios

Overview : Baidu Testing Middleware, developed by Baidu QA over ten years, is a foundational infrastructure for testing across Baidu’s product lines. It acts as a network proxy that intercepts module communication, enabling data‑level inspection/modification and behavior control (routing, fault injection, rate limiting, etc.). Its architecture mirrors Google’s Istio with a data plane + control plane design.

What the Middleware Is : It is a sidecar‑style network proxy built on Envoy that can parse and alter packets, enforce policies, and provide capabilities such as recording, replay, routing, and packet modification. Unlike Istio, which targets development and operations, Baidu’s middleware focuses on testing needs.

Testing Environment Challenges : Traditional integration testing requires building full topologies (often >7 modules) for each test, leading to high resource consumption and long setup times. Maintaining a baseline environment for multiple concurrent projects reduces stability and simulation fidelity. The need is to reuse test resources while isolating traffic.

Design Philosophy : Apply a data‑plane (Envoy sidecar) to handle packet forwarding and manipulation. Use a control‑plane (brain) to distribute policies and collect state. Abstract test scenarios into link‑level data or behavior problems.

System Components : Application Platform : Translates user requests into configuration entries. Configuration Center : Stores structured configurations (link info, topology info, policy info) using Zookeeper. Middleware Proxy : C++ high‑performance sidecar that watches the configuration center and applies policies in real time. Data Center : Stores recorded request/response data (Redis‑backed key‑value store). Log Center : Centralized log storage for distributed proxy instances. Control Center : Sends targeted commands (e.g., enable debug logs) to specific proxies.

Work Modes : Cluster Mode : Remote cluster of identical proxy instances; supports up to 20,000 concurrent links. Suitable for latency‑insensitive tests (diff, stable, functional). Local Mode : Sidecar deployed on the same host as the tested module; minimal latency, ideal for performance‑sensitive or chaos tests.

Overall Workflow (four steps): Service request: User defines test requirements via the application platform or API. Link generation: Requirements are stored as policies; proxies watch and create corresponding middleware links. Link takeover: Proxies report their addresses; environment‑building tools connect upstream modules to these links. Policy enforcement: Requests flowing through the links are evaluated; matching policies (routing, recording, modification) are applied.

Application Scenarios : Functional Testing : Create empty links, define mock strategies (AUTO, DATAID, CALL_BACK, USER_DEFINE) to simulate normal or abnormal responses. System‑Level Testing : Record baseline traffic, replay it to mock back‑ends, compare diff between baseline and test versions. Integration Testing : Reuse a single baseline environment, route traffic per test case, achieve multi‑path reuse. Sandbox Testing : Combine traffic simulation, environment simulation, and rapid provisioning; use routing and safety policies (circuit‑break, filter, rate‑limit) to protect production. Chaos Engineering : Deploy sidecar on client or server side, inject precise request‑level faults (e.g., connection drops) on colored traffic, while preserving normal traffic.

Technical Ecosystem : The middleware now serves nine major testing scenarios across Baidu’s product lines, abstracted into eight atomic capabilities (record, replay, routing, fault injection, etc.). The same architecture and capabilities are reused and continuously refined through real‑world deployments.

Core Essence : Starting as a simple network proxy, the middleware evolved into a full‑stack testing environment that controls both data and behavior, becoming an integral part of the test infrastructure.