本文地址：https://www.ebpf.top/post/cloudflare-replatforming-1

原文：https://ebpf.io/blog/cloudflare-replatforming-1/
作者：Cloudflare Engineering
发布时间：2026-08-27
翻译：狄卫华

本系列记述 Cloudflare 与 eBPF 长达八年的旅程：从专用的 DDoS 工具，演进为其全球网络的可编程骨干。内容涵盖向 Linux 内核贡献代码与技术挑战，到商业 ROI，再到给其他采用 eBPF 的公司的建议与运维策略。

Cloudflare 于 2016 年末开始探索 eBPF/XDP，2017 年中启动负载均衡原型。首次生产部署是在 2018 年 11 月：我们上线了基于 XDP 的包过滤（l4drop），用于 L3/L4 DDoS 缓解。它取代了此前绑定特定网卡（NIC）厂商的内核旁路（kernel bypass）方案。

Cloudflare 对 eBPF 的投入，源于硬件约束、性能要求与消除累积技术债这几股力量的汇合。下文说明我们如何走到重平台（replatforming）的决策、为何以 eBPF 为中心，以及我们今天在何处使用这项技术。

1. 催化剂：摆脱硬件锁定

促使我们审视 eBPF 的直接诱因，是此前的 DDoS 缓解方案：它依赖专有 RDMA 协议栈做内核旁路包处理，造成了单一厂商依赖。当我们开始部署基于 ARM 的服务器、以及面向 25G 网络升级的新型网卡时，碰了壁。这些平台与专有协议栈不兼容。

我们需要与厂商无关的方案。eBPF，尤其是 XDP（eXpress Data Path），正好满足这一点。它适用于任何在驱动中支持 XDP 的网卡，使我们能在不重写包处理逻辑的前提下，多样化硬件供应商。

2. XDP：性能不必妥协

我们需要在 DDoS 攻击期间以超过每秒 1000 万包的速率丢包，同时尽量压低 CPU 开销。完整内核旁路方案（如 DPDK）存在，但它们要求把整块网卡专用于单一应用；还会破坏 ssh、tcpdump 等标准 Linux 工具，并妨碍在同一台服务器上运行多个应用。

XDP 给了我们「部分内核旁路」。eBPF 程序在网络栈尽可能早的位置运行——直接在网卡驱动中——以接近线速（line-rate）完成包处理，CPU 开销极低（大规模攻击时约 10%），同时仍保留完整的 Linux 生态工具链。

3. 替换技术债

随着 Cloudflare 成长，我们多年积累了大量权宜之计，并在寻找降低技术债的途径，其中包括：

  • BIND_TO_PREFIX：我们自行维护、且未被上游接受的自定义内核补丁
  • TPROXY：配置与维护复杂，并与网络栈存在微妙交互
  • 数以万计的 IP 绑定：在我们的 DNS 解析器中，仅为 DDoS 防护就带来巨大的 socket 开销

eBPF 使我们能用更干净、更易维护的方案全部替换上述机制。

4. 为何采用基于 eBPF 的平台路径？

决定在整个栈中使用 eBPF、而非仅作点状方案，最终落到架构现实与运维效率。

互斥性（Mutual Exclusivity）：XDP 与内核旁路互不兼容，无法同时运行。当我们为 L4 负载均衡器（Unimog）选择 XDP 时，也被迫把 DDoS 缓解迁到 XDP。这并非劣势，而是统一的机会。

服务复用（Service Multiplexing）：每台边缘服务器上我们运行数十种服务：nginx、DNS 解析器、Spectrum、WARP 等等。传统 BSD socket 模型的「一端口一 socket」在我们的规模下根本行不通。我们需要不同应用共享 80 或 53 端口；对 Spectrum 而言，还需要访问全部端口号。BPF socket 分发（经由我们向上游贡献的 sk_lookup 钩子）在无需重启服务的情况下实现这种动态路由。

可组合性（Composability）：eBPF 程序可用尾调用串联。单个 XDP 钩子可以先后运行 DDoS 缓解、负载均衡、连接跟踪，全部作为模块化、可独立部署的程序。把 eBPF 当作平台来押注，使我们每需要一项新能力，都能额外再获取一层价值。

统一运维（Unified Operations）：一个平台意味着一种部署机制、一致的配置分发、统一的 Prometheus 指标，以及共用的调试工具。点状方案会把运维碎片化到不同系统上，各自有不同的部署、监控与调试方式。

5. 我们今天在何处使用 eBPF

Cloudflare 在六个不同层次使用 eBPF：

  • DDoS 缓解（XDP）：L4Drop 取代此前的内核旁路方案，在驱动层丢弃大流量（容量型）攻击
  • 负载均衡（XDP）：Unimog 负责 ECMP 路由与细粒度服务器负载均衡
  • Socket 分发（sk_lookup）：Tubular 把流量动态导向共享 IP 与端口的服务
  • 防火墙：Magic Firewall 在静态 nftables 规则不够用时，用 eBPF 做深度包检测
  • 可观测性（Observability）：ebpf_exporter 以低开销生成内核级直方图
  • 可靠性：udpgrm 使 QUIC 等 UDP 协议能够优雅重启

6. 押注 eBPF 生态，作为 Cloudflare 的平台

相对 eBPF 平台的另一条路，是维护多套互不兼容的点状方案，各自带着硬件依赖、运维怪癖与集成难题。随着硬件多样化、性能要求上升、边缘服务倍增，那条路已难以为继。

eBPF 给了我们统一、与厂商无关、高性能的底座，让我们能够对操作系统本身编程，以应对我们的规模。内核验证器（verifier）确保安全性，使我们能在运行中部署复杂逻辑变更，而不致冒系统崩溃之险。当每台边缘服务器都运行完整软件栈、且必须随流量瞬时变化而调整时，这种灵活性至关重要。

在本系列后续部分，我们将梳理把 eBPF 作为平台来押注如何在技术与商业收益两端得到回报，以及一路上遇到的挑战。

延伸阅读

若还想顺着读，可看这几篇：

  1. Cloudflare: 深入剖析 BPF LPM Trie 性能与优化
  2. Cloudflare 基于 BPF LSM 热修高危提权 Copy Fail
  3. 基于 veth 场景 XDP 加速：出向流量转发性能提升约 10 倍