测试是产品发布上线的一个重要环节,但随着业务规模和复杂度不断提高,每次上线需要回归的功能越来越多,给测试工作带来了巨大的压力。在这样的大背景下,越来越多的团队开始使用流量回放对服务进行回归测试。
在建设流量回放能力之前,我们必须将线上服务的流量录制下来。通常要结合对流量特征的要求、实现成本、对业务的侵入性等方面综合考虑,选择不同的实现方式。
对于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 函数:
根据函数注释,当前 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在流量录制方向的应用,希望可以帮助大家降低流量录制的实现和接入成本,快速建设流量回放能力。
最后:下方这份完整的软件测试视频教程已经整理上传完成,需要的朋友们可以自行领取【保100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。