作者 | 百度APP云原生技术研发组

导读

随着云计算的技术的不断迭代演进，百度内部服务逐渐搬迁到云环境中，部署成本和效率取得明显收益，但一些可观测能力的短板和缺失逐渐显露，传统的方式往往通过植入代码进行修改来实现，但在业务形态和技术栈多样性的背景下，面临业务被侵入、沟通协调、性能、稳定性等方面的诸多问题。本文中我们介绍百度基于eBPF实现的网络框架：DeeTune，包含构建服务拓扑、流量录制、无侵入指标监控等能力，进一步提升了SRE和质量保障的工作效率。

全文3733字，预计阅读时间10分钟。

云计算的进步以及基础设施、架构改进和其他相关技术的不断迭代发展，促进了百度内部服务向云环境的迁移。尽管云服务在成本效益和运营效率方面取得了显著进步，但云环境基本功能的某些局限性和不足也日益明显。因此，某些合理的业务需求，如建立不同微服务之间的拓扑关系和进行测试会话，仍未得到满足。传统的实施方法通常是在业务系统中嵌入代码，以便于功能集成。然而，由于业务结构和技术堆栈种类繁多，这种传统方法在业务入侵、通信、协调、性能、稳定性和其他相关方面面临诸多挑战。本文介绍了基于 eBPF 的百度网络框架 DeeTune。DeeTune 包含许多功能，如服务拓扑构建、流量录制、非侵入式指标监控等。这些功能有助于提高 SRE 的效率和质量保证。

01 问题和挑战

百度的微服务规模庞大且持续增长，服务之间的依赖关系同样非常复杂。服务拓扑能够展示全局服务及服务间的调用关系，也能够携带监控信息展示服务链路间的黄金指标，因此服务链路对于系统可观测性、稳定性保障、基础设施建设都有重要意义。

由于人工梳理成本大，基于SDK和框架的传统方式面临多技术栈、业务侵入等诸多问题，全局服务拓扑能力缺失会导致一些实际业务需求无法得到满足：

稳定性保障：缺少服务及流量拓扑来支持故障期间的快速定位和精确止损。当出现稳定性问题时，希望依据服务拓扑能够快速地定位问题服务及机房，能够高效获悉并通知故障服务的依赖和被依赖方、评估故障影响面分析；

基础设施建设：缺少服务拓扑来指导机房搬迁和重建工作的开展。在以往的机房搬迁过程中，服务的梳理和确认是一项重要但繁杂工作，每次机房搬迁都需要较长的时间梳理服务及其依赖，不仅需要投入人力，还需要预留机器资源，此外还容易引起稳定性风险；

系统重构升级：缺少服务上下游关系以评估系统重构升级对上下游的影响。升级过程中如何精准通知依赖方和被依赖方，重构过程中如何获取扇入、扇出等评估服务复杂程度的数据以判断服务是否需要拆分和合并等。

庞大的服务规模、复杂的业务类型、繁多的技术栈使得质量工程师的工作面临巨大的挑战，如集成测试环境搭建、测试用例编写、测试完备度评估等。流量回放是目前较先进成熟的自动化测试解决方案之一，通过线上流量录制和线下流量回放，实现对代码的快速回归能力。能够极大地提升项目迭代效率、加速代码回归测试进度，保证业务研发质量。

没有统一的流量录制方案和工具，流量回放的能力和效果受到了很大制约，流量录制的难点在于：

[1]业务技术栈复杂，配套的基础库和框架也非常多，无法通过框架或业务改造进行统一的流量录制；

[2]即使是单一技术栈和框架，也会面临业务侵入和有感的问题，稳定性也可能会受到一定影响；

[3]服务之间的访问途径非常多，如通过网关访问、虚拟IP访问、服务间直接连接等，无法通过统一的流量出入口录制流量。

服务间调用的指标（如流量、耗时等）和跟踪是业务上用于稳定性问题和服务性能优化的重要依据，但目前所有可观测性方案都是业务侵入的，需要框架或业务自身改造。另一方面，对于主机和容器的监控，除了操作系统提供的一些静态计数器，还需要能够从不同数据源收集和聚合数据，支持一些更深度的可观测性能力，帮助分析定位系统问题。但这类能力的开发难度和资源消耗都非常大。

02 eBPF介绍

导致上述技术挑战的根本原因在于业务形态和所采用的技术栈具有多样性，横向的跨业务、跨技术栈需求会导致规范性、业务侵入、沟通协调、性能、稳定性等多方面影响。

随着eBPF技术近几年的快速发展和应用，能够为我们解决以上问题提供新的解决方案和思路：

[1]eBPF是内核相关技术，它与用户态的技术栈、框架无关；

[2]能够在业务无侵入的方式下拿到更多内核态和用户态信息，可以在很大程度上为我们提供帮助甚至是解决问题。

eBPF全称为：extended Berkeley Packet Filter，是linux内核态引入的一套通用执行引擎，它允许在Linux内核中基于事件触发运行用户自定义的代码逻辑：

[1]eBPF提供了一种软件定义内核的方法，可以使用eBPF实现Linux的动态追踪以及Linux高速的网络数据包处理等逻辑；

[2]eBPF可以在不改变内核源码或加载内核模块情况下在内核中插入指定hook代码，能在内核或应用程序执行到一个特定的 hook点时执行（预定义的 hooks点位包含系统调用、函数出入口、内核追踪点、网络事件等）。

03 eBPF特点

[1]安全、稳定：通过严格限制访问函数集、内存地址、循环次数、代码路径触发，内核内置了稳定的API，保证只有被验证安全的 eBPF 指令才会被内核执行；

[2]高效：eBPF 指令依然运行在内核中，无需向用户态复制数据，并且借助即时编译器（JIT）将字节码转成机器码，运行效率等同于内核运行，执行更高效；

[3]热加载(持续交付)：eBPF程序的加载和卸载无需重启linux系统；

[4]数据互通：maps实现用户和内核态数据互通；

[5]兼容性：eBPF提供了稳定的 API，能在老内核上执行，那它一定也能继续在新内核上执行。

使用ebpf技术，可以为安全、tracing&性能分析、网络、观测&监控等方向提供新的思路和解决方案：

[1]安全：可以从系统调用层、packet层、socket层进行安全检查，如编写防火墙程序、开发DDOS防护系统等；
[2]Tracing&性能分析：内核提供多种类型探针(probe point)，如Kernel probes、perf events、Tracepoints、User-space probes、XDP等，可以编写eBPF程序收集这些探针点的信息，通过这种方式对程序进行跟踪，分析程序性能；

[3]网络：可以开发内核层高性能包处理程序，比如Cilium提供内核层的负载均衡，把service mesh往更深层推进，解决sidecar的性能问题；

[4]观测&监控：对这些探针点的持续观测和监控，可以丰富指标数据的范围和深度，更重要的是，这项工作可以在在不改变既有程序的前提下完成。

04 最佳实践

[1]Facebook：Katran 开源负载均衡器， L4LB、DDoS、Tracing

[2]Netflix：BPF 重度用户，例如生产环境 Tracing、profiling

[3]Google：Android、服务器安全、可观测性以及其他很多方面，GKE 默认使用 Cilium 作为网络基础

[4]Apple：使用 Falcon 识别安全风险

[5]AWS：使用 eBPF 作为 RPC 观测工具等

[6]Alibaba：容器网络插件Terway的增强，可观测工具 ilogtail的增强

[7]Bpftrace：提供了一种快速利用eBPF实现动态追踪的方法，可以作为简单的命令行工具或者入门级编程工具来使用；

[8]BCC：BCC 是python封装的 eBPF 外围工具集，用于创建高效内核跟踪和操作程序，可以大大方面 BPF 程序的开发；

[9]Cilium：Cilium 是一种基于eBPF的网络、可观察性和安全性解决方案。能够完全替代 kube-proxy，并提供深度网络和安全可见性和监控；

[10]DeepFlow：是中国公司开源的一款高度自动化的可观测性平台，使用 eBPF、WASM、OpenTelemetry 等新技术，极大的避免了埋点插码；

[11]Coroot：是一种基于 eBPF 的开源可观察性工具，它可以并将采集到的数据转化为可视化、可操作的指标，帮助快速识别和解决应用程序问题。

05 实现方案和应用

5.1 实现方案

虽然eBPF技术能够较好的解决技术栈依赖和业务侵入的痛点，但在百度复杂的环境中仍然需要解决很多难点。通过对各种技术的调研，结合百度业务实际需求，我们设计并实现一套切合百度需求与场景的基于eBPF的网络框架：DeeTune。它有5个子系统组成，如图1 所示：

Agent：以Host Agent方式部署于物理机上，加载并执行eBPF程序，监听内核中进程的创建与销毁、TCP连接的建立和关闭、socket的读写等事件，并在用户态对相应事件处理，得到topology、metrics和trace等数据。

Server：独立部署的Otel Collector服务，接收Agent上报的可观测性数据，解析和处理后，存入相应存储，后续查询分析使用。

Storage：用于存储拓扑、录制流量、Trace系统的数据，为不同类型数据提供不同类型存储，保障存储和查询分析效率。

CProm：百度内部的Prometheus和Grafana集成服务，通过标准接口提供服务提供大数据量查询功能。

API和Web UI：提供OpenAPI和Web可视化方式访问，各角色用户通过适合的方式访问、使用平台的数据和功能。

百度微服务部署的环境使用了多个PaaS平台、多容器类型、多内核版本和多CPU架构，是eBPF Agent的落地过程中不得不考虑的问题。同时，如何高效的实现内核态中众多的tracepoint及用户态中的支持逻辑，进一步加大了系统的实现复杂度和难度，如图2所示：

在这里插入图片描述

服务信息是平台的核心基础数据，所有能力（如拓扑、监控、流量录制）都强依赖服务信息，它主要由Agent获取和解析，包括服务名、业务线、IDC、BNS(Baidu Naming Service)等。

百度内部的复杂基础设施环境，使得服务信息的获取变得复杂和困难：

[1]多PaaS平台：百度内部有着复杂的业务场景，需要不同的PaaS平台能够适配各业务场景的最佳上线和部署方式。不同的PaaS平台对服务信息的定义、在Naming Service中的注册内容和格式都不尽相同，所以平台的Agent需要做很多的兼容工作来获取当前服务和被调用服务的服务信息；

[2]多容器类型：百度内部主要由三种容器类型：分别是Matrix(百度自研容器类型)、Container、Docker。PaaS部署服务实例时，会将一些服务信息写入如Containerd、Dockerd等容器守护进程中，且不同PaaS平台可能会使用不止一种容器，因此加大了Agent获取服务信息的难度。

上述问题的解决，主要还是依赖Agent对各场景的兼容和处理，并在可能的条件下与各PaaS沟通协作，以统一规范的方式注入服务信息。

百度内部的CPU除了X86架构，还有ARM A64架构，因此我们需要分析上面每一个tracepoint是否都能在两种CPU架构上执行，如在ARM CPU上需要对tracepoint sys_enter_open/sys_exit_open做兼容处理。

Agent的运行需要一定的主机资源，因此过多的资源占用会对系统造成影响：

Agent系统内部一部分是CPU密集型的计算逻辑，用于处理内核事件，并最终产出Topology、Metrics、Trace等数据。
另一部分是存储密集型的逻辑，用于保存计算的中间数据和运行时数据，为计算逻辑提供数据支撑。

生产环境中，每秒钟内核中可能会产生几K~几百K的事件数，因此Agent需要有高效的事件处理能力和高效的数据存取结构，减少锁的的使用和冲突等。DeeTune Agent经过几次性能优化，目前在生产环境中可以将CPU/MEM控制在 1.3Core/1G。

另一方面，由于eBPF tracepoint的存在，机器上所有网络请求都会经过内核eBPF程序的处理，因此eBPF也会对服务间调用的网络延迟产生影响。经过真实环境测试，在tracepoint的事件触发、eBPF Map的增删改查、bpf辅助函数调用和对7层协议的解包的判断大约会消耗30µs，这个时间对于绝大部分服务的影响可以忽略。

5.2 应用场景

服务拓扑

基于eBPF的服务拓扑能力，能够提供高准确度和高完备度的服务拓扑数据，能够支持高效的故障定位与分析、服务的强弱依赖、故障演练、服务影响面分析、跨机房调用等。服务拓扑能力除了可视化的拓扑图，还提供了OpenAPI供需求方二次开发定制自己的能力。

流量录制

流量录制是非常态化需求，Agent需要能够根据配置，动态的按照录制策略完成录制任务。流量录制可以在平台上创建任务，可以根据拓扑信息，指定有连接关系的任意两个服务间的流量录制。同时可以指定录制策略，如录制时间、条数，要录制的接口等。QA通过任务注册时的回调或者OpenAPI获取任务及录制的流量。如图：

指标监控

DeeTune默认采集汇聚了关于主机和容器的如CPU、MEM等资源指标。除了最基础的资源指标，理论上借助eBPF技术，我们几乎可以采集系统内任何指标，如：活跃&失败连接数、网络重传、流量统计、进程&容器数、内核关键指标等。通过对系统和容器进行更深度的观测，能够帮助运维工程师更高效的定位资源相关问题：如PaaS平台容易出现的资源使用不合理、容器部署密度高、资源超卖高、网络状况诊断等。