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

为了满足字节的需求，我们在整体架构上引入了一些其他组件来弥补 TCPCopy 自身的不足。
2.3 系统架构为了解决 TCPCopy 存在的不足，我们在通过 TCPCopy 直接进行流量转发的方案基础上又进行了一些优化。
首先，在 TCPCopy 和被测服务之间额外引入了七层代理进行数据转发。七层代理本身可以校验请求的完整性，避免不完整的请求被转发到测试服务对干扰测试造成干扰。
此外，我们将七层代理和 TCPCopy 的 intercept 组件部署在一批专用于流量转发的服务器上，进行转发任务时只需要修改这批服务器的 iptables ，而被测服务只需在测试机上正常运行，不用进行额外配置，因此可以尽量避免修改 iptables 带来的风险。
为了能够更好地融入公司的技术生态系统，同时支持更丰富的测试场景，我们还专门实现了一个用于测试的七层代理。具体加入了以下能力：

接入了公司的服务发现框架，被测实例只需注册指定的服务名，就可以收到代理发送的流量。因此流量可以被同时转发到多个被测实例，也可以动态地添加或删除被测实例
支持流量过滤。从收到的流量中筛选出指定方法的流量进行转发。比如可以过滤掉转发流量中包含写操作的流量，从而避免对存储造成污染
引入流控机制。支持对转发的流量进行限速，以及通过将收到的请求多次重复发送实现加压，从而支持简单的压测场景

最后，为了让引流功能变得易用，我们把 TCPCopy 的两个组件，以及我们的七层代理进行了封装，打包成了一个平台提供给用户。用户只需要指定引流源和被测服务的 IP 和端口，以及引流任务的持续时间，即可进行一次引流测试。
线上的整体架构大概如下图所示，用户提交任务后，我们会负责进行各个组件的调度、配置和部署，将流量从线上转发到用户的待测实例。

文章插图

2.5 存在的问题随着规模的逐渐发展和更多用户场景的提出，这套架构也逐渐暴露出了一些问题。
2.5.1 TCPCopy 存在性能问题TCPCopy 在实现上没有进行多线程的设计，因此实际的转发吞吐能力较为有限，对于一些高带宽的测试场景无法很好地支持。
2.5.2 现有实现无法支持响应录制等更多场景TCPCopy 定位只是请求复制转发工具，只会复制线上流量的请求部分，而不会复制线上流量的响应。我们接到了一些想要对线上流量进行分析的用户的需求，他们希望能够同时收集线上流量的请求和响应，TCPCopy 没法支持这类场景。
3. 自研 ByteCopy，开启海量流量和复杂业务场景的支持前面提到了第一代引流系统存在一些性能和灵活性的问题，与此同时业务也提出了一些新的需求，例如支持 MySQL 协议，支持历史流量的存储和回放等。考虑到在现有的 TCPCopy 的架构上很难做扩展，所以我们考虑推翻现有架构，重新构建字节新一代的引流系统 - ByteCopy (寓意是复制线上每一个字节)
在以上演进的基础上，我们可以按职责把七层流量复制大致分解为下面三个模块

流量采集
流量解析
流量应用

针对 3 个模块我们分别展开介绍
3.1 流量采集

文章插图

流量采集模块会依据服务部署的平台以不同方式拉起，如在 Kubernetes 会由 Mesh Agent 唤起，使用 libpcap 监听特定端口流量，在用户态重组 TCP 层包，batch 发送至 Kafka 。
默认场景下，流量采集模块只会对被采集的服务监听的 IP 和端口进行抓包。此外，为了提供出口流量采集（即采集某一服务对其下游依赖发的调用）的能力，流量采集模块还对接了公司的服务发现框架。在需要对出口流量进行采集时，流量采集模块会查询下游依赖服务所有实例的 IP 和端口，对这部分流量也进行采集。（这一方案存在一定问题，后续会详细介绍）
由于流量采集进程和应用进程是部署在同个 Docker 实例或物理机里，业务会对流量采集模块的资源占用比较敏感，我们除了在代码层优化，还会用 cgroups 对资源使用做硬性限制。
此外流量采集平台是多租户设计，对一个服务可能同时存在多个用户的不同规格的采集需求，如用户 A 希望采集 env1 环境 5% 实例流量，用户 B 希望采集 env1 环境 1 个实例的流量及 env2 环境 1 个实例的流量，如果简单地独立处理用户 A 和 B 的请求，会出现 env1 环境部署 5%+1 实例 env2 部署 1 实例这种冗余部署。我们的做法是把用户的请求规格和采集模块的实际部署解耦，用户提交一个规格请求后，会先和已有的规格合并，得到一个最小部署方案，然后更新部署状态。