Traffic Recording and Replay Platform (Pandora) Overview and Practice at Dewu
Dewu’s Pandora platform extends an open‑source traffic‑recording‑replay solution to capture and replay external service responses across Java applications, using a three‑party collaboration model and phased rollout to achieve near‑full interface coverage, while addressing noisy failures, async challenges, and planning real‑time dual‑playback automation for high‑traffic scenarios.
Traffic recording and replay (referred to as "flow recording replay") captures external call responses (DB, cache, third‑party services) on the application side and replays them in test environments to verify interface outputs and intermediate links.
Dewu's Pandora platform extends the open‑source version with many unsupported sub‑calls and entry calls, and adapts middleware to reduce replay failures.
Most market solutions are built on Jvm‑Sandbox‑Repeater and support only Java; they share the same principle of recording production traffic and replaying it for verification.
Implementation adopts a three‑party collaboration model (business testing, platform R&D, business R&D) with tasks divided as shown.
Application of replay is divided into three stages: test‑submission checkpoint, regression checkpoint, and pre‑release regression, focusing on core scenarios, full‑scenario coverage, and reducing noise by aligning recording and replay environments.
Practice phases include:
Phase 1 – trial integration: select 40 % of services, configure P0 interfaces and tags, auto‑sink test cases.
Phase 2 – upgrade: use intelligent analysis to accelerate case accumulation, achieve 100 % P0 interface coverage.
Phase 3 – acceleration: increase application coverage to 90 %+, improve debugging speed, target >65 % full case sinking, and reach >98 % interface coverage.
Summary analysis shows defect categories: production‑blocking bugs (≈45 %), hidden code issues (≈45 %), performance problems (≈6 %). Main defect sources are iteration requirements and technical optimizations.
Applicability: suitable for high‑traffic, data‑intensive scenarios (e.g., ToC products). Not suitable for async scenarios, sandbox‑induced latency spikes, or cases requiring full DB/trace verification.
Challenges include low debugging efficiency due to noisy failures (code changes, unsupported sub‑calls, timestamp differences, random parameters, repeater bugs, data inconsistencies, unordered collections) and handling async thread recording where main thread returns before sub‑threads finish.
Future plans involve real‑time (single) and dual‑playback strategies, expanding coverage, building a robust case library, and integrating automated noise filtering.
DeWu Technology
A platform for sharing and discussing tech knowledge, guiding you toward the cloud of technology.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.