对比主路复制，旁路复制突出了业务无感知的特点，一般是由第三方服务在网络协议栈中，监听复制流量

优点

• 与业务解耦，可以独立部署升级引流模块，业务方无需关注引流功能实现；通过在协议栈底层进行流量复制，性能较好。

缺点

• 4 层网卡层面的网络包抓取后，仍需要进行数据包的重组和解析，需要额外的消耗计算资源。

• 往往需要全量抓包解析再进行筛选，无法结合业务逻辑进行定制化的采样。

开源方案 TCPCopy

虽然 Linux 提供了 libpcap 这样的底层 packet capture 库，不过本着快速交付业务需求的目标，我们选择了开源的 TCPCopy 来作为整个引流系统的核心基础。TCPCopy 在这里就不多介绍，只在下面附上一张简单的架构图，其中 TCPCopy 和 Intercept 是 TCPCopy 的两个组件，相关细节感兴趣的同学可以自行查找资料。

TCPCopy 的主要优势：

• 协议无感知，可以透明转发，能够支持基于 TCP 的任意应用层协议，如 MySQL，Kafka，Redis 等

• 实时转发，延时较低

• 可以保留原始请求 IP 端口信息，测试服务器可用于统计

同时，也具有以下不足：

• 无法动态添加多个下游服务器

• 由于透明转发，不做协议解析，无法发现数据异常，如部分 TCP 包丢失，测试服务器将收到不完整的数据；此外，也无法对应用层数据进行筛选和修改进行修改

• 核心组件设计时未进行多线程设计，处理能力存在瓶颈

• 需要修改 iptables 来丢弃下游服务的回包，用在生产或公共的测试环境存在较大风险

为了满足字节的需求，我们在整体架构上引入了一些其他组件来弥补 TCPCopy 自身的不足。

2.3 系统架构

为了解决 TCPCopy 存在的不足，我们在通过 TCPCopy 直接进行流量转发的方案基础上又进行了一些优化。

首先，在 TCPCopy 和被测服务之间额外引入了七层代理进行数据转发。七层代理本身可以校验请求的完整性，避免不完整的请求被转发到测试服务对干扰测试造成干扰。

此外，我们将七层代理和 TCPCopy 的 intercept 组件部署在一批专用于流量转发的服务器上，进行转发任务时只需要修改这批服务器的 iptables ，而被测服务只需在测试机上正常运行，不用进行额外配置，因此可以尽量避免修改 iptables 带来的风险。

为了能够更好地融入公司的技术生态系统，同时支持更丰富的测试场景，我们还专门实现了一个用于测试的七层代理。具体加入了以下能力：

• 接入了公司的服务发现框架，被测实例只需注册指定的服务名，就可以收到代理发送的流量。因此流量可以被同时转发到多个被测实例，也可以动态地添加或删除被测实例

• 支持流量过滤。从收到的流量中筛选出指定方法的流量进行转发。比如可以过滤掉转发流量中包含写操作的流量，从而避免对存储造成污染

• 引入流控机制。支持对转发的流量进行限速，以及通过将收到的请求多次重复发送实现加压，从而支持简单的压测场景

最后，为了让引流功能变得易用，我们把 TCPCopy 的两个组件