作者 | 百度 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 平台容易出现的资源使用不合理、容器部署密度高、资源超卖高、网络状况诊断等。

06 总结

DeeTune 是百度基于 eBPF 实现的网络框架，提供服务拓扑、流量录制、opentracing、容器资源与业务流量监控、跨机房调用检测等云原生场景基础能力，一些能力已经提供试点使用并取得了初步收益。本文分析真实问题，对 eBPF 技术优势和应用等方面全面介绍了 DeeTune 的设计方法和应用。

未来还会在一些方面持续的优化和建设：

多协议支持：目前链路指标和流量录制主要支持 HTTP1、Redis、MySQL 协议，未来持续对 gRPC、bRPC、HTTP2 还有内部其他自研协议的支持工作。

多系统联动：与部署平台、监控系统、代码与持续集成系统、质效系统的信息联动，能够帮助业务更高效发现并解决线上问题和代码问题。

——END——

推荐阅读

百度自研高性能ANN检索引擎，开源了

存储方案作为产品——Midgard探索

百度垂类离线计算系统发展历程

度加剪辑App的MMKV应用优化实践

百度工程师浅析解码策略