流量录制方案梳理

1.kdev流量录制回放平台建设历程

2.各方案架构概要

包括我司在内，业内主流的流量录制实现方式主要是以下三种

1. 中间件SDK硬编码（我司）
2. sandbox repeater (阿里)
3. 类tcp copy方案（字节）

2.1 中间件sdk硬编码方案

录制动作硬编码在client sdk中， 与业务服务共享同一进程。

2.2 采用sandbox repeater 方案

2.3 类tcp copy方案

字节bytecopy

3.录制方案之间优劣势对比

能力方面	中间件SDK 硬编码（我司当前使用）	sandbox repeater(阿里doom)	自研类tcp copy的网络层捕获方案****（字节bytecopy）	备注
基本原理	基于统一的中间件sdk	基于字节码增强	旁路复制网络包
性能影响–开启录制	优：取决于被录制服务流量多少以及采样率	优：取决于被录制服务流量多少以及采样率	差： 会出现额外性能开销，原因在于：tcp copy在网络第四层进行录制，难以识别流量属于哪个接口以及哪种协议，这样会导致该进程下的所有tcp流量都会被录制需要有小流量环境	关于传出层流量的解析：如果想要实现针对协议、接口进行录制，我们需要将流量解析到应用层，解析复杂度随着协议种类增加而增加，例如http2.0的多路复用， 就难以区分req和resp针对api进行录制同样存在解析难度进而采样也不容易实现
性能影响–不开启录制	优：****有极小影响（仅一个配置判断）	优：无影响	优：无影响
稳定性影响（非性能类）	良：****有影响， 具体如下：sdk的正常流程会执行录制代码开发过程中，流量录制逻辑与sdk本身逻辑互相耦合	良：****有影响，具体如下：在开启录制的情况下，录制代码编译成字节码后会增强到sdk代码中，会在同一线程中被执行。因sdk与录制代码完全解耦，开发过程中可能存在不同步的情况。例如sdk增加了某个功能，录制代码却没有增加，导致插桩不符合预期。需要有标准小流量环境	优：无影响	sandbox与sdk硬编码对于被录服务的稳定性影响各有优劣，总体看来两者差异不大，而旁路录制则优势明显
代码可控性	**优:**sdk维护人与录制代码维护人为相同团队，更熟悉代码逻辑	良：sdk维护人与录制代码维护人为不同团队，开发风险相对稍高例如关于kconf 、kswitch的录制需要了解其使用场景。	优：在性能符合预期的情况下，不存在代码代码可控性问题
录制数据完整性	良：只能支持固定协议	优：能支持所有协议且能只会任意方法	差：对于没有网络请求的动作，不支持录制，例如kconf
录制语言支持	优支持我司主流语言java和c++	差：只支持java	优支持所有语言
业务方接入成本	优：基于root pom升级，仅重新编译部署即可	优：但需要解决以下前提当前公司的基础设施没有在生产环境批量部署sandbox agent的能力生产环境是否允许使用sandbox agent需要确认，之前是不允许（如果2允许，1可以推动建设）	优：需要解决以下前提公司基础设施支持在生产环境指定机器范围批量部署tcpcopy-agent,	tcpcopy和sandbox需要的基础设施建设成本比较高， 可能会需要单独设计一套小流量环境， 并在公司范围内推广使用规范。
功能迭代速度（例如支持一种新的协议）	差：牵涉团队过多，且各团队OKR不一致，沟通推动成本极高	优：	优：	tcpcopy与sandbox在基础设置完善的情况下，

（滴滴的sharingan是基于语言标准库拦截，且不支持java和c++，因此不在考虑范围之内)

4.升级成本

1. 全部录制逻辑需要重写，包括所有中间件的录制协议
2. 基础需要设施升级，无论采用sandbox repeater 还是 tcp copy都需升级基础设施， 在当前的环境下，推动升级难度较大
3. 业务方存在迁移成本，难以做到无缝迁移，例如至少业务方需要在使用流量录制回放的机器上增加环境变量，或修改流水线。