字节跳动自研线上引流回放系统的架构演进

本文选自“字节跳动基础架构实践”系列文章。

“字节跳动基础架构实践”系列文章是由字节跳动基础架构部门各技术团队及专家倾力打造的技术干货内容，和大家分享团队在基础架构发展和演进过程中的实践经验与教训，与各位技术同学一起交流成长。

线上流量引流线下环境是一个通用需求，广泛应用于功能测试、压测等场景。本文介绍了引流系统在字节跳动的发展过程和系统设计，希望能给大家带来一点新的思考和收获。

1. 背景

AB Test (diff 测试) 是在互联网行业中比较常用的验证方法，例如 Google 通过 AB 实验针对广告和推荐的效果做验证，Twitter 研发了 Diffy ，把 Diff 验证能力应用到了 API 接口的质量保障上。通常 AB Test 有两种形式，一种是线上多个服务版本，通过接入侧分流 AB 来做实验，但对于广告这类场景，一旦某个模型有问题，就会造成资损。另外一个模式是通过线上的流量复制回放到内部环境，这种方式对于生产是绝对安全的，例如 Twitter 的 AB 验证服务 diffy 就是走的这个模式。今天字节内部推荐，广告，等很多业务线都是通过线上流量实时回放的模式做 AB 实验。为了满足业务的需求，我们自研了一套线上流量录制回放系统 ByteCopy 来支撑业务的海量流量吞吐和不断产生的对于流量录制回放的新需求。

这篇文章会从业务场景、系统架构、问题分析等几个方面来介绍 ByteCopy 这套系统的演进过程。

2. 基于 TCPCopy 构建第一代引流系统

2.1 业务需求

刚开始业务的需求还是比较简单的，就是希望在业务方部署好了目标服务 (HTTP 和 RPC) 后，引流系统可以把对应线上生产的流量复制一份并转发过去，并且整个引流过程可以灵活管控，只在需要流量的时候开启。

2.2 系统选型

从引流自身来看，主要分为 2 种类型，主路复制和旁路复制，我们分别来分析一下这两种模式的优劣。

2.2.1 主路复制

主路复制是指在调用链中进行流量复制：一种是在业务逻辑中进行流量复制，如在调用 API/RPC 过程中，由业务方编写代码逻辑，记录 request / response 信息内容；另外一种是在框架（如使用 Dubbo、Service Mesh 等网络框架）处理逻辑中进行复制。

优点

• 可以高度结合业务逻辑，实现细粒度定制化流量复制，比如可以只针对某个用户的流量进行复制，可以最大程度上提升引流源上的有效流量采集比。

缺点

• 业务逻辑与引流逻辑耦合度较高，功能上相互影响。

• 每个请求都需要进行额外引流处理，对业务流程存在性能影响。

适用场景

• 对于流量有细粒度筛选要求的，或与业务逻辑有关，可以选择主路复制；如 Service Mesh 中根据染色标记，进行流量复制。

2.2.2 旁路复制

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

优点

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

缺点

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

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

开源方案 TCPCopy

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

TCPCopy 的主要优势：

• 协议无