Pingora 深度解析：Cloudflare 下一代 Rust 高性能代理

Pingora 深度解析：Cloudflare 下一代 Rust 高性能代理

一、引言

在互联网基础设施领域，Nginx 长期以来一直是反向代理和负载均衡的事实标准。然而，随着互联网流量的爆炸式增长和对性能、安全性要求的不断提高，传统的代理服务器架构也面临着新的挑战。

2022 年，Cloudflare 宣布了一个重磅消息：他们已经用自研的新一代代理系统Pingora替换了核心基础设施中的 Nginx。这个用 Rust 语言从零构建的代理框架，在处理同等流量的情况下，只需要原来三分之一的 CPU 和内存资源，同时还带来了显著的性能提升。

2024 年 2 月，Cloudflare 正式开源了 Pingora，让全世界的开发者都有机会使用这个经过万亿级流量验证的高性能代理框架。

二、什么是 Pingora

Pingora 是 Cloudflare 用 Rust 语言开发的一个异步、多线程的 HTTP 代理框架。它的名字来源于 Wind River Range 中的 Pingora Peak——就像攀登这座山峰一样，构建一个高性能、高可靠的代理系统也是一项极具挑战性的工程任务。

核心定位：Pingora 不仅仅是一个代理服务器，更是一个可编程的网络服务框架。它提供了丰富的 API，让开发者可以轻松构建自己的代理、负载均衡器和其他网络服务。

2.1 为什么 Cloudflare 要造轮子

Cloudflare 每天处理超过一万亿次 HTTP 请求，他们的大量核心产品（CDN、Workers、Tunnel、Stream、R2 等）都依赖代理层正常工作。在使用 Nginx 多年后，他们遇到了几个难以解决的问题：

• 多进程架构的限制：Nginx 的多进程模型导致每个 worker 进程都有独立的连接池，连接无法跨进程复用，造成了资源浪费。

• Lua 与 C 的转换开销：Cloudflare 大量使用 OpenResty（Nginx + Lua）来实现业务逻辑，但 C 和 Lua 之间的数据转换会消耗大量 CPU 和内存。

• 内存安全问题：Nginx 用 C 语言编写，存在内存安全隐患，可能导致崩溃或安全漏洞。

• 扩展性受限：Nginx 的模块开发复杂，难以快速迭代新功能。

正是这些痛点，促使 Cloudflare 决定从零开始构建一个全新的代理系统——Pingora。

三、Pingora 的技术架构

Pingora 的设计充分吸取了 Nginx 的经验教训，并结合了现代编程语言和异步编程的最佳实践。

3.1 整体架构

Pingora 采用了多线程异步架构，基于 Tokio 运行时实现，所有线程共享同一个连接池。这是它与 Nginx 最本质的区别之一。

3.2 核心组件

Pingora 的架构可以分为以下几个层次：

3.3 关键设计决策

多线程而非多进程

与 Nginx 的多进程模型不同，Pingora 选择了多线程架构。这样做的最大好处是：所有线程可以共享同一个连接池。这意味着一个线程建立的上游连接，可以被其他任何线程复用，大大提高了连接复用率，减少了 TCP 和 TLS 握手的开销。

基于 Tokio 的异步运行时

Pingora 使用 Tokio 作为异步运行时，并实现了工作窃取（work-stealing）调度算法。这使得负载可以在多个线程之间动态平衡，避免了某些线程过载而其他线程空闲的情况。

自研 HTTP 库

尽管 Rust 生态中已经有 hyper 等优秀的 HTTP 库，Cloudflare 还是选择了自研 HTTP 库。主要原因是：

• 需要处理大量不符合 RFC 标准的真实互联网流量

• 需要最大限度地控制性能优化点

• 需要支持各种非标准的 HTTP 状态码（如 599-999）

四、Pingora 的核心特性

4.1 协议支持

Pingora 覆盖了主流的代理场景：

• HTTP/1 和 HTTP/2 的端到端代理

• gRPC 和 WebSocket 代理

• TLS、TCP 和 Unix Domain Socket

• HTTP/3 已在路线图上，尚未正式发布

4.2 负载均衡

Pingora 框架内置了常用的负载均衡策略：

• 轮询（Round Robin）

• 哈希（Hashing）

• 支持完全自定义的服务器选择逻辑

4.3 安全特性

• 同时支持 OpenSSL 和 BoringSSL

• BoringSSL 版本支持 FIPS 模式

• Rust 语言本身的内存安全特性，从根源上避免了大量安全漏洞

4.4 可编程的请求生命周期

Pingora 提供了类似于 Nginx/OpenResty 的请求生命周期 API，开发者可以注册各种回调函数，在请求处理的不同阶段插入自定义逻辑：

• 请求头接收时

• 请求体接收时

• 上游连接建立前

• 上游响应头接收时

• 响应发送给客户端前

4.5 优雅重启

Pingora 提供了优雅的重启机制，使得服务在升级或维护时能够无缝切换，不影响用户体验。

4.6 可观测性

Pingora 支持与 OpenTelemetry 等主流可观测性工具集成，方便监控和调试。

五、Pingora vs Nginx 深度对比

5.1 性能对比

根据 Cloudflare 官方公布的数据，Pingora 在生产环境中的表现相当惊人：

用一个更直观的说法：每天，Pingora 为 Cloudflare 的客户节省了相当于434 年的握手等待时间。

5.2 架构对比

Nginx 架构

• 多进程模型，每个 worker 独立

• 每个进程有独立的连接池

• 进程间通信开销大

• 连接复用率低

• C 语言编写，内存安全风险

Pingora 架构

• 多线程模型，共享地址空间

• 全局共享连接池

• 线程间资源共享高效

• 连接复用率高，减少握手

• Rust 语言编写，内存安全

5.3 开发体验对比

Nginx/OpenResty

• 配置文件驱动，简单场景上手快

• 复杂逻辑需要用 Lua 编写

• C 和 Lua 之间有数据转换开销

• 模块开发门槛高，需要深入理解 Nginx 内部

• 生态成熟，第三方模块丰富

Pingora

• 完全用 Rust 代码编写配置和逻辑

• 类型安全，编译期就能发现很多错误

• 统一的编程语言，没有跨语言开销

• API 设计清晰，扩展相对容易

• 生态较新，还在快速发展中

5.4 适用场景对比

六、快速上手示例

让我们来看一个最简单的 Pingora 负载均衡示例：

use pingora::prelude::*; use std::sync::Arc; pub struct LB(Arc<LoadBalancer<RoundRobin>>); #[async_trait] impl ProxyHttp for LB { async fn upstream_peer(&self, _session: &mut Session, _ctx: &mut () ) -> Result<Box<HttpPeer>> { let upstream = self.0.select(b"", 256).unwrap(); Ok(Box::new(HttpPeer::new(upstream, false, "".to_string()))) } } fn main() { let mut my_server = Server::new(None).unwrap(); my_server.bootstrap(); let mut upstreams = LoadBalancer::try_from_iter([ "127.0.0.1:8080", "127.0.0.1:8081", ]).unwrap(); let mut lb = http_proxy_service(&my_server.configuration, LB(Arc::new(upstreams))); lb.add_tcp("0.0.0.0:6188"); my_server.add_service(lb); my_server.run_forever(); }

这段代码实现了一个简单的反向代理，它会将请求轮询转发到两个后端服务（8080 和 8081 端口）。可以看到，Pingora 的 API 设计非常简洁，只需要实现ProxyHttptrait 中的upstream_peer方法，就能自定义负载均衡逻辑。

七、Pingora 的应用场景

7.1 云服务商和 CDN

这是 Pingora 最擅长的场景。对于需要处理海量流量的云服务商和 CDN 厂商来说，Pingora 能够显著降低基础设施成本，同时提升用户体验。

7.2 微服务网关

在微服务架构中，API 网关是核心组件。Pingora 的高性能和可编程特性，使其非常适合构建下一代微服务网关。

7.3 企业级负载均衡器

对于有大规模内部服务的企业，Pingora 可以作为高性能的内部负载均衡器，替代传统的硬件负载均衡或 Nginx 集群。

7.4 定制化代理服务

如果你需要构建具有特殊逻辑的代理服务（如 WAF、缓存层、协议转换等），Pingora 提供的可编程框架会比 Nginx 模块开发更加灵活和高效。

八、总结与展望

8.1 Pingora 的优势

• 极致性能：经过万亿级流量验证，CPU 和内存消耗仅为 Nginx 的约三分之一

• 内存安全：Rust 语言从根源上避免了内存安全漏洞

• 高效连接管理：全局共享连接池，大幅提高连接复用率

• 可编程性强：清晰的 Rust API，易于扩展和定制

• 生产验证：已经在 Cloudflare 的核心基础设施中稳定运行

8.2 当前的局限

• 生态尚新：相比 Nginx 几十年积累的生态，Pingora 还很年轻，第三方模块和工具较少

• 学习曲线：需要 Rust 语言基础，不像 Nginx 配置文件那样简单

• 功能完整性：某些高级功能还在开发中（如 HTTP/3）

• 静态文件服务：不是 Pingora 的主要设计目标

8.3 未来展望

Pingora 作为一个开源项目，正在快速发展中。随着 Rust 生态的不断成熟和社区贡献的增加，我们可以期待：

• 更多的协议支持（HTTP/3、QUIC 等）

• 更丰富的第三方库和插件生态

• 更好的开发工具和调试体验

• 更多企业在生产环境中采用

Pingora 不会完全取代 Nginx——就像 Nginx 没有完全取代 Apache 一样。但在高性能、高安全要求的场景下，Pingora 无疑提供了一个极具吸引力的新选择。对于追求极致性能和安全性的团队来说，Pingora 值得认真关注和评估。

参考资料：

• Cloudflare 官方博客：How we built Pingora

• Cloudflare 官方博客：Open sourcing Pingora

• Pingora GitHub 仓库：cloudflare/pingora