关于云原生:DeeTune基于-eBPF-的百度网络框架设计与应用

2次阅读

共计 5816 个字符,预计需要花费 15 分钟才能阅读完成。

作者 | 百度 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 利用优化实际

百度工程师浅析解码策略

正文完
 0