Implementing Service Traffic Replication with TCPCopy and DubboCopy

TCPCopy is a tool that can duplicate TCP (and even UDP) streams, allowing real production traffic to be replayed on test servers with very low resource consumption, which is useful for functional and performance testing.

Using such a tool enables developers to verify service correctness and performance after changes by replaying actual user traffic, which can be more realistic than synthetic load generators.

However, in many cases only a subset of services should be copied—for example, copying order‑placement traffic without payment traffic—to simplify the test environment. To address this, the authors built a proxy called DubboCopy (based on Alibaba's Dubbo framework) that sits between TCPCopy and the test servers.

After integrating DubboCopy, the architecture changes as shown in the second diagram.

DubboCopy aims to:

Lower the barrier to using service traffic replication.

Support multi‑dimensional traffic selection.

Monitor various performance metrics and collect service responses.

Lowering the barrier : TCPCopy has network‑segment restrictions and requires manual routing table changes, and it does not provide RPM packages. The team built an RPM, stored it in an internal repository, and created an HTTP interface (with OPS assistance) to start/stop TCPCopy on production machines, making the process transparent to end users.

Multi‑dimensional traffic copying : Users select services and target machines via a UI; DubboCopy then calls the HTTP API to start TCPCopy on the appropriate production hosts, using a load‑balanced approach to distribute commands. After TCPCopy forwards traffic to the proxy, DubboCopy partially parses the Dubbo protocol to extract service and method metadata, then forwards the raw payload to the designated test machines.

The implementation uses Netty. To keep memory usage low, data is read into DirectByteBuffer (off‑heap) and sliced with ByteBuf.readSlice so the payload can be forwarded without copying into the Java heap, minimizing GC pressure. Netty’s pooled allocator further reduces allocation overhead, and the Netty server and client worker threads are shared to cut context‑switching.

Monitoring performance and functionality : The copied traffic provides two main testing goals—performance testing (e.g., response time) and functional testing (e.g., checking response correctness). While functional comparison with live responses is not yet implemented, the collected metrics allow effective simulation of a production environment.

The article concludes by inviting readers to discuss their own online simulation setups or new requirements for the tool.