测试是产品发布上线的一个重要环节，但随着业务规模和复杂度不断提高，每次上线需要回归的功能越来越多，给测试工作带来了巨大的压力。在这样的大背景下，越来越多的团队开始使用流量回放对服务进行回归测试。
在建设流量回放能力之前，我们必须将线上服务的流量录制下来。通常要结合对流量特征的要求、实现成本、对业务的侵入性等方面综合考虑，选择不同的实现方式。
对于 Java 和 PHP 语言，目前业界已经有比较成熟的解决方案 jvm-sandbox-repeater、rdebug，基本可以做到低成本、无侵入式的流量录制；但 Go 语言由于缺少像 jvm 或 libc 等可利用的中间层，现有的方案 sharingan 需要修改官方 Go 源码并且侵入业务代码，稳定性风险较大；并且随着官方 Go 版本升级，需要持续维护迭代，使用和维护成本较高。
鉴于滴滴多语言的技术栈，我们经过调研发现可以通过 eBPF 实现一种跨语言、无侵入的流量录制方案，大幅降低流量录制的使用和维护成本。
流量录制原理
录制内容
流量回放时需要对下游依赖服务进行 mock，因此录制的一条完整流量中不仅需要包含入口调用的请求/响应，还需要包含处理这次请求时所调用依赖服务的请求/响应。
实现思路
在介绍流量录制方案之前，我们先来看一个请求的处理过程（简化后）：
观察上述流程我们发现目标服务处理一个请求的大致流程如下：
首先，调用 accept 获得一个调用方的连接；
第二步，在这个连接上通过调用 recv 读取请求数据，解析请求；
第三步，目标服务开始执行业务逻辑，过程中可能需要调用一个或多个依赖服务，对于每一次依赖服务调用，目标服务需要通过 connect 与依赖服务建立连接，然后在这个连接上通过 send 发送请求数据，通过 recv 接收依赖服务响应；
最后，目标服务通过 send 给调用方返回响应数据。
为了实现流量录制，我们需要把图中所有的请求和响应数据保存下来。传统的流量录制方法需要跟踪服务框架、RPC框架、依赖服务sdk等所有涉及发送/接收数据的方法，将数据收集并保存下来。由于框架和sdk多种多样，需要大量的代码改造和开发工作，成本难以控制。
这里我们考虑更通用的方式：跟踪 socket 相关操作，例如 accept、connect、send、recv 等。通过这种方式我们可以不用关心业务中使用的应用层协议、框架、sdk等，实现更通用的流量录制方法。
但是，由于实现录制的位置更底层，能够获取的上下文信息更少，只有每个 socket 发送和接收的数据是不够的。我们需要借助其他信息对原始数据进行串联，从而组装完整的一条流量。
区分不同的请求
线上服务处理的请求大多是并发的，同时会有多个请求交织在一起，我们录制到原始数据是分散的，如何把同一个请求的数据合并，把不同请求的数据区分开呢？通过分析实际的请求处理过程，我们不难发现：
1、通常情况下，每个请求是在单独的线程中进行处理的。
2、为了提高处理速度，可能创建子线程并发调用依赖服务。
实际上，子线程也可能再创建子线程，形成下图所示的线程关系：
对于这种涉及子线程的场景，我们只要把子线程的数据合并到请求处理线程即可。每个请求都会对应一个请求处理线程和一系列的子线程，最终我们可以根据线程 ID 来区分出不同请求。
区分数据类型
在每一条流量中包含了两类数据：入口调用的请求和响应，下游依赖调用的请求和响应。我们需要在流量录制时进行区分。通过观察请求处理流程，我们不难发现其中的规律：
1、入口调用的请求和响应是在 accept 获得的 socket 上接收和发送的，recv 的数据是 request，send 的数据是 response。
2、下游依赖调用的请求和响应是在 connect 获得的 socket 上接收和发送的，send 的数据是 request，recv 的数据是 response；不同的 socket 对应不同的下游调用。
因此，我们可以根据 socket 类型和标识区分出不同的数据类型和不同的下游依赖调用。
流量录制实现
考虑到目前大部分服务已经上云，因此方案需要支持容器化部署。eBPF 程序运行在内核中，而同一宿主机上的所有容器共享同一个内核，因此 eBPF 程序只需要加载一次即可录制到所有进程的数据。整体方案如下：
录制agent：与目标进程部署在相同容器中，根据进程名找到要录制的目标进程 pid，(1) 控制录制 server 开启/关闭录制；(7) 从录制 server 接收原始数据，解析成完整流量，(8) 保存到日志文件中。
录制server：部署在宿主机上，负责 (2, 3) 加载/挂载 eBPF程序、(6) 从 eBPF Map 中读取原始数据。
eBPF 程序：负责在目标进程 (4) 发送和接收数据时，(5) 从挂载的函数中读取原始数据并写入 eBPF Map 中。
选择插桩点
根据前面的讨论，我们需要跟踪的 socket 操作包括：
accept 和 connect 用于区分 socket 类型。
send 和 recv 用于捕获发送和接收的数据。
close 用于识别调用的结束。
对于 Go 语言，还需要获取执行上述 socket 操作的 goroutine id 和跟踪 goroutine 的父子关系。
在开发 eBPF 程序之前，需要选择合适的 eBPF 程序挂载位置，不同的 eBPF 程序类型，能够获取到的上下文不同，可调用的 bpf-helper 函数也不同。我们需要录制的数据只有 TCP 和 UDP 两种协议，因此可以通过 kprobe 挂载到内核的以下函数：
inet_accept
inet_stream_connect
inet_sendmsg
inet_recvmsg
inet_release
为了跟踪 goroutine 之间的关系，我们可以通过 uprobe 挂载到 Go 运行时的 runtime.newproc1 函数，从 callergp 和 newg 中获取对应的 goroutine 信息。
开发eBPF程序
流量录制虽然涉及了多个内核函数，但流程基本是一样的，下面以录制 socket 发送数据为例进行详细介绍。
函数签名：
int inet_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)参数说明：
sock socket 指针
msg 要发送的数据
size 要发送数据的长度
返回值：
成功时返回发送的数据长度，失败时返回错误码。
由于实际发送的数据长度是在函数返回时才能获取到的，因此我们需要开发两个程序，分别完成以下工作：
在函数入口处记录函数参数和上下文
在函数返回时记录实际发送的数据内容
函数入口 eBPF 程序：
SEC("kprobe/inet_sendmsg")
int BPF_KPROBE(inet_sendmsg_entry, struct socket *sock, struct msghdr *msg)
{
struct probe_ctx pctx = {
.bpf_ctx = ctx,
.version = EVENT_VERSION,
.source = EVENT_SOURCE_SOCKET,
.type = EVENT_SOCK_SENDMSG,
.sr.sock = sock,
};
int err;
// 过滤掉不需要录制的进程
if (pid_filter(&pctx)) {
return 0;
}
// 读取 socket 类型信息
err = read_socket_info(&pctx, &pctx.sr.sockinfo, sock);
if (err) {
tm_err2(&pctx, ERROR_READ_SOCKET_INFO, __LINE__, err);
return 0;
}
// 记录 msg 中的数据信息
err = bpf_probe_read(&pctx.sr.iter, sizeof(pctx.sr.iter), &msg->msg_iter);
if (err) {
tm_err2(&pctx, ERROR_BPF_PROBE_READ, __LINE__, err);
return 0;
}
// 将相关上下文信息保存到 map 中
pctx.id = bpf_ktime_get_ns();
err = save_context(pctx.pid, &pctx);
if (err) {
tm_err2(&pctx, ERROR_SAVE_CONTEXT, __LINE__, err);
}
return 0;
}函数返回 eBPF 程序：
SEC("kretprobe/inet_sendmsg")
int BPF_KRETPROBE(inet_sendmsg_exit, int retval)
{
struct probe_ctx pctx = {
.bpf_ctx = ctx,
.version = EVENT_VERSION,
.source = EVENT_SOURCE_SOCKET,
.type = EVENT_SOCK_SENDMSG,
};
struct sock_send_recv_event event = {};
int err;
// 过滤掉不需要录制的进程
if (pid_filter(&pctx)) {
return 0;
}
// 如果发送失败, 跳过录制数据
if (retval <= 0) {
goto out;
}
// 从 map 中读取提前保存的上下文信息
err = read_context(pctx.pid, &pctx);
if (err) {
tm_err2(&pctx, ERROR_READ_CONTEXT, __LINE__, err);
goto out;
}
// 构造 sendmsg 报文
event.version = pctx.version;
event.source = pctx.source;
event.type = pctx.type;
event.tgid = pctx.tgid;
event.pid = pctx.pid;
event.id = pctx.id;
event.sock = (u64)pctx.sr.s;
event.sock_family = pctx.sr.sockinfo.sock_family;
event.sock_type = pctx.sr.sockinfo.sock_type;
// 从 msg 中读取数据填充到 event 报文, 并通过 map 传递到用户空间
sock_data_output(&pctx, &event, &pctx.sr.iter);
out:
// 清理上下文信息
err = delete_context(pctx.pid);
if (err) {
tm_err2(&pctx, ERROR_DELETE_CONTEXT, __LINE__, err);
}
return 0;
}获取goid
对于 Go 语言，我们需要根据发送和接收数据时 goroutine id 进行数据串联，如何在 eBPF 程序中获取呢？通过分析 go 源码，我们发现 goroutine id 是保存在 struct g 中的，并且可以通过 getg() 来获取当前 g 的指针。
getg 函数：
// getg returns the pointer to the current g.
// The compiler rewrites calls to this function into instructions
// that fetch the g directly (from TLS or from the dedicated register).
func getg() *g根据函数注释，当前 g 的指针是放在线程本地存储（TLS）中的，调用 getg() 的代码由编译器进行重写。为了找到 getg() 的实现方式，我们看到 runtime.newg 函数中调用了 getg，对它进行反汇编，发现 g 的指针保存在 fs 寄存器 -8 的内存地址上：
接下来，我们找到 struct g 中的 goid 字段（位于 runtime/runtime2.go）：
type g struct {
.... 此处省略大量字段
goid int64
.... 此处省略大量字段
}拿到 g 的指针后，只要加上 goid 字段的偏移量即可获取到 goid。同时，考虑到不同的 go 版本之间，goid 偏移量可能不同，最终在 eBPF 程序中我们可以这样获取当前 goid：
static __always_inline
u64 get_goid()
{
struct task_struct *task = (struct task_struct *)bpf_get_current_task();
unsigned long fsbase = 0;
void *g = NULL;
u64 goid = 0;
bpf_probe_read(&fsbase, sizeof(fsbase), &task->thread.fsbase);
bpf_probe_read(&g, sizeof(g), (void*)fsbase-8);
bpf_probe_read(&goid, sizeof(goid), (void*)g+GOID_OFFSET);
return goid;
}遇到的问题
eBPF 程序虽然可以使用 C 语言开发，但是与普通 C 语言开发过程有较大的差别，增加了很多限制。
以下为开发时遇到的比较关键的问题和解决思路：
不允许使用全局变量、常量字符串或数组，可以保存到 map 中。
不支持函数调用，可以通过 inline 内联解决。
栈空间不能超过512字节，必要时可通过 array 类型的 map 做缓冲区。
不能直接访问用户态和内核态内存，要通过 bpf-helper 的相关函数。
单个程序指令条数不能超过 1000000，尽量保持 eBPF 程序逻辑简单，复杂的处理放在用户态程序完成。
循环必须有明确的次数上限，不能只靠运行时判断。
结构体成员要内存对齐，否则可能导致部分内存未初始化，引发 verifier 报错。
代码经过编译器优化后 verifier 可能误报内存访问越界问题，可以在代码中增加 if 判断帮助 verifer 识别，必要时可通过内联汇编的方式解决。
....
随着 clang 和内核对 ebpf 支持的逐渐完善，很多问题也在逐步得到解决，后续的开发体验也会变得更顺畅。
安全机制
为了保障流量数据的安全性，降低数据脱敏对线上机器的性能影响，我们选择在流量采集阶段进行加密：
总结
本文介绍了 eBPF 在流量录制方向的应用，希望可以帮助大家降低流量录制的实现和接入成本，快速建设流量回放能力。由于篇幅原因，流量录制的很多细节不能展开分享，后续计划将该方案开源，欢迎大家持续关注滴滴开源项目。更多关于 eBPF 的应用场景，感兴趣的同学也可以进一步阅读《eBPF内核技术在滴滴云原生的落地实践》进行了解。
限于作者技术水平，文中难免有所错漏，大家可以在评论区留言指正，期待后续更多的交流和讨论。
END
作者及部门介绍
本篇文章作者王超锋，来自滴滴网约车出行技术团队，出行技术作为网约车业务研发团队，通过建设终端用户体验平台、C端用户产品生态、B端运力供给生态、出行安全生态、服务治理生态、核心保障体系，打造安全可靠、高效便捷、用户可信赖的出行平台。
招聘信息
团队后端、测试需求招聘中，欢迎有兴趣的小伙伴加入，可以扫描下方二维码简历直投，期待你的加入！
研发工程师
岗位描述：
1. 负责相关业务系统后台研发工作，包括业务的架构设计、开发，控制复杂度，提升系统性能和研发效率；
2. 有业务 sense，通过不断的技术研究和创新，与产品、运营一起快速迭代提升业务的核心数据。
测试开发工程师
岗位描述：
1. 构建适用于网约车业务的质量保障体系，制定并推进相关质量技术方案落地，持续保障业务质量；
2. 深入了解业务，与业务中各角色建立沟通，总结业务问题与痛点，全方位为业务创造价值，工作不设固定边界；
3. 通过应用相关质量基础设施，提升业务代码质量和交付效率；
4. 沉淀高效测试解决方案，并能提供通用化方案，支持在其他业务线落地应用；
5. 解决业务质量保障中的难点问题、复杂技术难题；
6. 质量技术领域前瞻性探索。
