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

电商运营 2022-12-20 09:22 10371人围观引流方法

本文选自“字节跳动根本架构理论”系列文章。

“字节跳动根本架构理论”系列文章是由字节跳动根本架构部分各技术团队及专家倾力打造的技术干货内容，和大师分享团队在根本架组成长和演进进程中的理论经历与经验，与列位技术同学一路交换长大。

线上流量引流线下情况是一个通用需求，普遍利用于功用测试、压测等场景。本文先容了引流系统在字节跳动的成长进程和系统设想，希望能给大师带来一点新的思考和收获。

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 的首要上风：

协议无感知，可以通明转发，可以支持基于 TCP 的肆意利用层协议，如 MySQL，Kafka，Redis 等
实时转发，延时较低
可以保存原始请求 IP 端口信息，测试办事器可用于统计

同时，也具有以下不敷：

没法静态增加多个下流办事器
由于通明转发，不做协议剖析，没法发现数据异常，如部分 TCP 包丧失，测试办事器将收到不完整的数据；此外，也没法对利用层数据停止挑选和点窜良行点窜
焦点组件设想时未停止多线程设想，处置才能存在瓶颈
需要点窜 iptables 来抛弃下流办事的回包，用在生产或公共的测试情况存在较大风险

为了满足字节的需求，我们在整体架构上引入了一些其他组件来填补 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 实例这类冗余摆设。我们的做法是把用户的请求规格和收集模块的现实摆设解耦，用户提交一个规格请求后，会先和已有的规格合并，获得一个最小摆设计划，然后更新摆设状态。

3.2 流量剖析

引流源收集上来的原始流量还是第四层协议，为了支持一些更复杂的功用，比如过滤，多路输出，历史流量存储，流量查询及流量可视化等等，我们需要将四层流量剖析到七层。字节跳动内部办事利用得比力多的协议是 Thrift 和 HTTP ，这两个按照协议标准即可很好地完成剖析。

流量剖析有一个难点是判定流量的鸿沟，区分于 HTTP/2 等的 Pipeline 毗连复用传输形式，Thrift 和 HTTP/1.X 在单条毗连上严酷依照请求-响应对来停止传输，是以可以经过请求和响应的切换分隔出完整的请求或响应流量。

3.3 流量利用

对于线上收集的流量，分歧用户会有分歧的营业用处，如压测平台能够希望将流量先持久化到 Kafka，然后操纵 Kafka 的高吞吐发压；有些研发同学只是简单从线上引一份流量转发到自己的开辟情况做新特征测试；有些同学希望转发 QPS 能到达一定水位以实现压测的目标；还有的是特定流量会触发线上 coredump ，他们希望把这段流量录制下来线下 debug 等等。针对分歧的场景，我们实现了多少流量输出形式。

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

下面会侧重先容转发和存储。

3.3.1 转发

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

结构如上图，emitter 会在 zookeeper 上注册本身，scheduler 感知到 emitter 节点信息，将使命按照各个 emitter 节点的标签和统计信息过滤/打分，然后调剂到最合适的节点上。这里有个题目是为什么不间接利用无状态办事，由每个 emitter 实例均等地转发，而采用 sharding 计划，主如果基于下面几点斟酌:

假如每个使命均摊到一切实例上履行，那每个实例需要和全手下流 endpoint 建立毗连，在海量使命下的 goroutine、毗连、内存等资本占用是不成接管的
经过将单个使命的处置收敛到少数实例上，进步了对单个 endpoint 的请求密度，从而避免由于毗连 idle 时候太长被对端 close，复用了毗连。

由于 emitter 对性能比力敏感，我们为此也做了很多优化，比如利用了 fasthttp 的 goroutine 池避免频仍申请 goroutine，对毗连的 reader/writer 工具池化，静态调理每个 endpoint 的工作线程数目以自顺利用户指定 QPS，避免 goroutine 浪费及闲置长毗连退化成短毗连，全程无锁化，经过 channel+select 做线程同步和数据传递等等。

3.3.2 存储

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

存储分为了两层，数据层和索引层，采用双写模子，并有按时使命从数据层纠错索引层保证两者的终极分歧性。存储需要支持回放和查询两种语义，Data Layer 笼统成了一个支持 KV 查询，按 Key 有序，大容量的存储模子，Index Layer 是 Multi-index->Key 映照模子，经过这两层即可满足流量查询+回放的需求。所以 Data Layer 和 Index Layer 底层实现是模块化的，只需合适上述模子并实现模子界说 API。

Data Layer 的理想数据结构是 LSM tree，写入性能出色，对于流量回放场景，需要按 key 有序扫描流量记录，由于 LSM 满足按 key 的部分性和有序性，可以充实操纵 page cache 和磁盘顺序读到达较高回放性能。散布式 LSM Tree 业界比力成熟的开源产物是 HBase，字节跳动内部也有对标产物 Bytable，我们同时实现了基于这两个引擎的 Data Layer，经过一系列性能 benchmark 我们挑选了 Bytable 作为 Data Layer 实现。

Index Layer 利用了 ES 的才能，因此可以支持用户的复合条件查询，我们会预先内置一些查询索引，如源办事，方针办事，方式名，traceid 等等，流量查询今朝的利用处景一个是作为办事 mock 的数据源，可以屏障掉功用测试大概 diff 中不需要的内部依靠，还有一个功用是流量可视化，用户经过请求时候，traceid 等等，检察特定请求的内容。其他场景功用还有待进一步挖掘。

3.4 营业场景支持

3.4.1 支持通用的 diff 才能

Diff 考证是互联网公司在快速迭代下连结产物资量的一个利器，类似 Twtiter 的 Diffy 项目，都是经过线上流量的录制回放来实现。可是它的适用处景也很有限，由因而间接在生产情况上经过 AB 情况做回放，没法支持写的流量。虽然阿里巴巴的 doom 平台可以处理写场景的回放隔离题目，可是它是在利用法式中经过 AOP 来实现的，强绑定 java 生态。

经过 ByteCopy 的无侵入引流和流量存储回放才能，连系我们自研的 ByteMock 组件，我们供给了面向营业的无侵入 diff 处理计划，并处理了写隔离的题目。

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

在一个生产情况下的 (A,B,C) 链路中，经过 ByteCopy 实现了针对每一跳 (request, response) 的收集，在做 A 的 diff 考证的时辰，经过 ByteCopy 实现对于 A 办事请求的回放，同时，基于 ByteMock 来实现对于办事 B 的 mock，并支持针对一个 trace 的 response 回放 (依靠 ByteCopy 中流量存储，实现精准的回放)。由于 B 是 mock 的，即使是一个写的请求，也可以做到对于线上没有任何影响。

4. 未来展望

4.1 更精准的流量收集

前面提到，在停止出口流量的收集时，会对下流依靠办事的一切实例的 IP:端口停止抓包。而现实的生产情况中，同一台办事器上，能够会摆设具有不异下流依靠的多个办事，只依靠四层数据，没法判定抓到的数据到底来自哪一个办事，会形成抓包、处置和转发流程中城市存在资本浪费的题目。今朝来看基于网卡抓包的计划应当没法很好地处理这个题目，我们也在尝试摸索一些其他的流量收集的计划，比如摸索用 ebpf 停止进程级此外流量收集。

4.2 引流回放系统的重新界说

现阶段我们的引流回放系统只会按照用户的设置被动停止流量收集，而为了实时拿到流量停止测试，用户一般城市挑选实时引流停止测试。而现实上并不是一切的场景都一定需要实时的流量停止测试，我们在计划慢慢将引流回放系统从一个依照用户要求停止流量转发回放的工具，改变成一个线上复制流量的取用的平台。

在流量存储才能的根本上，对于有测试需求的办事，平台自动错峰、按时倡议流量录制使命，从而保护一个不竭更新的流量池，用户需要流量时间接从流量池中取用，这样一来，既可以只管避免引流操纵对和线上营业抢占计较资本，也可以使得流量的可用性更高。

4.3 特定场景下的流量存储优化

随着基于流量录制回放的上层利用的完善，为了更多的营业方便接入试用，我们正在斟酌朝着常态化的引流去演进。这个势必对我们的流量存储带来新的应战，不管是的数据范围，存储形状以及查询性能。我们希望可以基于现有架构的存储系统，构建流量存储的处理计划，支持海量数据吞吐的同时，可以支持点查(基于 TraceId )，和 time-range scan 等多种复杂的高性能查询方式。别的我们也在积极战争安团队合作，确保相关焦点流量数据在存储时辰可以实现脱敏，同时不竭强化对于流量存储利用的平安审计。

5. 总结

到明天为止，ByteCopy 系统已经支持了字节绝大部分营业线在分歧场景下的各类引流需求，我们一向在尽力丰富 ByteCopy 的功用场景，不竭提升系统稳定性和吞吐容量，此外我们也在积极构建 ByteMock 等自研的研发组件，经过和 ByteCopy 构成组合拳，解锁生产流量在研发活动中更多的利用处景，帮助营业团队更好地去构建各类风趣的产物。

字节跳动根本架构团队

字节跳动根本架构团队是支持字节跳动旗下包括抖音、本日头条、西瓜视频、火山小视频在内的多款亿级范围用户产物平稳运转的重要团队，为字节跳动及旗下营业的快速稳定成长供给了保证和鞭策力。

公司内，根本架构团队首要负责字节跳动私有云扶植，治理数以万计办事器范围的集群，负责数万台计较/存储夹杂摆设和在线/离线夹杂摆设，支持多少 EB 海量数据的稳定存储。

文化上，团队积极拥抱开源和创新的软硬件架构。我们持久招聘根本架构偏向的同学，具体可拜见 job.bytedance.com （文末“阅读原文”），感爱好可以联系邮箱 guoxinyu.0372@bytedance.com 。

接待关注字节跳动技术团队