DeeTune：基于 eBPF 的百度网络框架设计与应用
点击蓝字，关注我们
01
百度的微服务规模庞大且持续增长，服务之间的依赖关系同样非常复杂。服务拓扑能够展示全局服务及服务间的调用关系，也能够携带监控信息展示服务链路间的黄金指标，因此服务链路对于系统可观测性、稳定性保障、基础设施建设都有重要意义。
由于人工梳理成本大，基于SDK和框架的传统方式面临多技术栈、业务侵入等诸多问题，全局服务拓扑能力缺失会导致一些实际业务需求无法得到满足：
稳定性保障：缺少服务及流量拓扑来支持故障期间的快速定位和精确止损。当出现稳定性问题时，希望依据服务拓扑能够快速地定位问题服务及机房，能够高效获悉并通知故障服务的依赖和被依赖方、评估故障影响面分析；
基础设施建设：缺少服务拓扑来指导机房搬迁和重建工作的开展。在以往的机房搬迁过程中，服务的梳理和确认是一项重要但繁杂工作，每次机房搬迁都需要较长的时间梳理服务及其依赖，不仅需要投入人力，还需要预留机器资源，此外还容易引起稳定性风险；
系统重构升级：缺少服务上下游关系以评估系统重构升级对上下游的影响。升级过程中如何精准通知依赖方和被依赖方，重构过程中如何获取扇入、扇出等评估服务复杂程度的数据以判断服务是否需要拆分和合并等。
庞大的服务规模、复杂的业务类型、繁多的技术栈使得质量工程师的工作面临巨大的挑战，如集成测试环境搭建、测试用例编写、测试完备度评估等。流量回放是目前较先进成熟的自动化测试解决方案之一，通过线上流量录制和线下流量回放，实现对代码的快速回归能力。能够极大地提升项目迭代效率、加速代码回归测试进度，保证业务研发质量。
没有统一的流量录制方案和工具，流量回放的能力和效果受到了很大制约，流量录制的难点在于：
[1]业务技术栈复杂，配套的基础库和框架也非常多，无法通过框架或业务改造进行统一的流量录制；
[2]即使是单一技术栈和框架，也会面临业务侵入和有感的问题，稳定性也可能会受到一定影响；
[3]服务之间的访问途径非常多，如通过网关访问、虚拟IP访问、服务间直接连接等，无法通过统一的流量出入口录制流量。
服务间调用的指标（如流量、耗时等）和跟踪是业务上用于稳定性问题和服务性能优化的重要依据，但目前所有可观测性方案都是业务侵入的，需要框架或业务自身改造。另一方面，对于主机和容器的监控，除了操作系统提供的一些静态计数器，还需要能够从不同数据源收集和聚合数据，支持一些更深度的可观测性能力，帮助分析定位系统问题。但这类能力的开发难度和资源消耗都非常大。
02
随着eBPF技术近几年的快速发展和应用，能够为我们解决以上问题提供新的解决方案和思路：
[1]eBPF是内核相关技术，它与用户态的技术栈、框架无关；
[2]能够在业务无侵入的方式下拿到更多内核态和用户态信息，可以在很大程度上为我们提供帮助甚至是解决问题。
eBPF全称为：extended Berkeley Packet Filter，是linux内核态引入的一套通用执行引擎，它允许在Linux内核中基于事件触发运行用户自定义的代码逻辑：
[1]eBPF提供了一种软件定义内核的方法，可以使用eBPF实现Linux的动态追踪以及Linux高速的网络数据包处理等逻辑；
[2]eBPF可以在不改变内核源码或加载内核模块情况下在内核中插入指定hook代码，能在内核或应用程序执行到一个特定的 hook点时执行（预定义的 hooks点位包含系统调用、 函数出入口、内核追踪点、网络事件等）。
GEEK TALK
03
eBPF特点
[1]安全、稳定：通过严格限制访问函数集、内存地址、循环次数、代码路径触发，内核内置了稳定的API，保证只有被验证安全的 eBPF 指令才会被内核执行；
[2]高效：eBPF 指令依然运行在内核中，无需向用户态复制数据，并且借助即时编译器（JIT）将字节码转成机器码，运行效率等同于内核运行，执行更高效；
[3]热加载(持续交付)：eBPF程序的加载和卸载无需重启linux系统；
[4]数据互通：maps实现用户和内核态数据互通；
[5]兼容性：eBPF提供了稳定的 API，能在老内核上执行，那它一定也能继续在新内核上执行。
[1]安全：可以从系统调用层、packet层、socket层进行安全检查，如编写防火墙程序、开发DDOS防护系统等；
[2]Tracing&性能分析：内核提供多种类型探针(probe point)，如Kernel probes、perf events、Tracepoints、User-space probes、XDP等，可以编写eBPF程序收集这些探针点的信息，通过这种方式对程序进行跟踪，分析程序性能；
[3]网络：可以开发内核层高性能包处理程序，比如Cilium提供内核层的负载均衡，把service mesh往更深层推进，解决sidecar的性能问题；
[4]观测&监控：对这些探针点的持续观测和监控，可以丰富指标数据的范围和深度，更重要的是，这项工作可以在在不改变既有程序的前提下完成。
GEEK TALK
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 的开源可观察性工具，它可以并将采集到的数据转化为可视化、可操作的指标，帮助快速识别和解决应用程序问题。
GEEK TALK
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可视化方式访问，各角色用户通过适合的方式访问、使用平台的数据和功能。
服务信息是平台的核心基础数据，所有能力（如拓扑、监控、流量录制）都强依赖服务信息，它主要由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平台容易出现的资源使用不合理、容器部署密度高、资源超卖高、网络状况诊断等。
GEEK TALK
06
总结
DeeTune是百度基于eBPF实现的网络框架，提供服务拓扑、流量录制、opentracing、容器资源与业务流量监控、跨机房调用检测等云原生场景基础能力，一些能力已经提供试点使用并取得了初步收益。本文分析真实问题，对eBPF技术优势和应用等方面全面介绍了DeeTune的设计方法和应用。
未来还会在一些方面持续的优化和建设：
多协议支持：目前链路指标和流量录制主要支持HTTP1、Redis、MySQL协议，未来持续对gRPC、bRPC、HTTP2还有内部其他自研协议的支持工作。
多系统联动：与部署平台、监控系统、代码与持续集成系统、质效系统的信息联动，能够帮助业务更高效发现并解决线上问题和代码问题。
END
推荐阅读