Pingora 深度解析Cloudflare 下一代 Rust 高性能代理一、引言在互联网基础设施领域Nginx 长期以来一直是反向代理和负载均衡的事实标准。然而随着互联网流量的爆炸式增长和对性能、安全性要求的不断提高传统的代理服务器架构也面临着新的挑战。2022 年Cloudflare 宣布了一个重磅消息他们已经用自研的新一代代理系统Pingora替换了核心基础设施中的 Nginx。这个用 Rust 语言从零构建的代理框架在处理同等流量的情况下只需要原来三分之一的 CPU 和内存资源同时还带来了显著的性能提升。2024 年 2 月Cloudflare 正式开源了 Pingora让全世界的开发者都有机会使用这个经过万亿级流量验证的高性能代理框架。二、什么是 PingoraPingora 是 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 大量使用 OpenRestyNginx Lua来实现业务逻辑但 C 和 Lua 之间的数据转换会消耗大量 CPU 和内存。内存安全问题Nginx 用 C 语言编写存在内存安全隐患可能导致崩溃或安全漏洞。扩展性受限Nginx 的模块开发复杂难以快速迭代新功能。正是这些痛点促使 Cloudflare 决定从零开始构建一个全新的代理系统——Pingora。三、Pingora 的技术架构Pingora 的设计充分吸取了 Nginx 的经验教训并结合了现代编程语言和异步编程的最佳实践。3.1 整体架构Pingora 采用了多线程异步架构基于 Tokio 运行时实现所有线程共享同一个连接池。这是它与 Nginx 最本质的区别之一。3.2 核心组件Pingora 的架构可以分为以下几个层次层次说明核心层pingora-core服务编排、协议、I/O、pingora-httpHTTP 类型定义协议层HTTP/1.x、HTTP/2、TLS 后端、连接池支持层错误处理、超时管理、运行时管理、工具函数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 SocketHTTP/3 已在路线图上尚未正式发布4.2 负载均衡Pingora 框架内置了常用的负载均衡策略轮询Round Robin哈希Hashing支持完全自定义的服务器选择逻辑4.3 安全特性同时支持 OpenSSL 和 BoringSSLBoringSSL 版本支持 FIPS 模式Rust 语言本身的内存安全特性从根源上避免了大量安全漏洞4.4 可编程的请求生命周期Pingora 提供了类似于 Nginx/OpenResty 的请求生命周期 API开发者可以注册各种回调函数在请求处理的不同阶段插入自定义逻辑请求头接收时请求体接收时上游连接建立前上游响应头接收时响应发送给客户端前4.5 优雅重启Pingora 提供了优雅的重启机制使得服务在升级或维护时能够无缝切换不影响用户体验。4.6 可观测性Pingora 支持与 OpenTelemetry 等主流可观测性工具集成方便监控和调试。五、Pingora vs Nginx 深度对比5.1 性能对比根据 Cloudflare 官方公布的数据Pingora 在生产环境中的表现相当惊人指标Nginx (旧系统)PingoraCPU 使用率基准 (100%)↓ 约 70%内存使用基准 (100%)↓ 约 67%TTFB 中位数基准↓ 约 5msTTFB 95 分位基准↓ 约 80ms用一个更直观的说法每天Pingora 为 Cloudflare 的客户节省了相当于434 年的握手等待时间。5.2 架构对比Nginx 架构多进程模型每个 worker 独立每个进程有独立的连接池进程间通信开销大连接复用率低C 语言编写内存安全风险Pingora 架构多线程模型共享地址空间全局共享连接池线程间资源共享高效连接复用率高减少握手Rust 语言编写内存安全5.3 开发体验对比Nginx/OpenResty配置文件驱动简单场景上手快复杂逻辑需要用 Lua 编写C 和 Lua 之间有数据转换开销模块开发门槛高需要深入理解 Nginx 内部生态成熟第三方模块丰富Pingora完全用 Rust 代码编写配置和逻辑类型安全编译期就能发现很多错误统一的编程语言没有跨语言开销API 设计清晰扩展相对容易生态较新还在快速发展中5.4 适用场景对比场景NginxPingora静态文件服务✅ 成熟稳定⚠️ 非主要场景反向代理✅ 经典选择✅ 性能更优负载均衡✅ 功能完善✅ 更高效大规模流量⚠️ 资源消耗大✅ 更省资源定制化代理逻辑⚠️ Lua 开发✅ Rust 原生开发快速部署简单场景✅ 配置简单⚠️ 需要写代码六、快速上手示例让我们来看一个最简单的 Pingora 负载均衡示例use pingora::prelude::*; use std::sync::Arc; pub struct LB(ArcLoadBalancerRoundRobin); #[async_trait] impl ProxyHttp for LB { async fn upstream_peer(self, _session: mut Session, _ctx: mut () ) - ResultBoxHttpPeer { 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 PingoraCloudflare 官方博客Open sourcing PingoraPingora GitHub 仓库cloudflare/pingora
Pingora 深度解析：Cloudflare 下一代 Rust 高性能代理
Pingora 深度解析Cloudflare 下一代 Rust 高性能代理一、引言在互联网基础设施领域Nginx 长期以来一直是反向代理和负载均衡的事实标准。然而随着互联网流量的爆炸式增长和对性能、安全性要求的不断提高传统的代理服务器架构也面临着新的挑战。2022 年Cloudflare 宣布了一个重磅消息他们已经用自研的新一代代理系统Pingora替换了核心基础设施中的 Nginx。这个用 Rust 语言从零构建的代理框架在处理同等流量的情况下只需要原来三分之一的 CPU 和内存资源同时还带来了显著的性能提升。2024 年 2 月Cloudflare 正式开源了 Pingora让全世界的开发者都有机会使用这个经过万亿级流量验证的高性能代理框架。二、什么是 PingoraPingora 是 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 大量使用 OpenRestyNginx Lua来实现业务逻辑但 C 和 Lua 之间的数据转换会消耗大量 CPU 和内存。内存安全问题Nginx 用 C 语言编写存在内存安全隐患可能导致崩溃或安全漏洞。扩展性受限Nginx 的模块开发复杂难以快速迭代新功能。正是这些痛点促使 Cloudflare 决定从零开始构建一个全新的代理系统——Pingora。三、Pingora 的技术架构Pingora 的设计充分吸取了 Nginx 的经验教训并结合了现代编程语言和异步编程的最佳实践。3.1 整体架构Pingora 采用了多线程异步架构基于 Tokio 运行时实现所有线程共享同一个连接池。这是它与 Nginx 最本质的区别之一。3.2 核心组件Pingora 的架构可以分为以下几个层次层次说明核心层pingora-core服务编排、协议、I/O、pingora-httpHTTP 类型定义协议层HTTP/1.x、HTTP/2、TLS 后端、连接池支持层错误处理、超时管理、运行时管理、工具函数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 SocketHTTP/3 已在路线图上尚未正式发布4.2 负载均衡Pingora 框架内置了常用的负载均衡策略轮询Round Robin哈希Hashing支持完全自定义的服务器选择逻辑4.3 安全特性同时支持 OpenSSL 和 BoringSSLBoringSSL 版本支持 FIPS 模式Rust 语言本身的内存安全特性从根源上避免了大量安全漏洞4.4 可编程的请求生命周期Pingora 提供了类似于 Nginx/OpenResty 的请求生命周期 API开发者可以注册各种回调函数在请求处理的不同阶段插入自定义逻辑请求头接收时请求体接收时上游连接建立前上游响应头接收时响应发送给客户端前4.5 优雅重启Pingora 提供了优雅的重启机制使得服务在升级或维护时能够无缝切换不影响用户体验。4.6 可观测性Pingora 支持与 OpenTelemetry 等主流可观测性工具集成方便监控和调试。五、Pingora vs Nginx 深度对比5.1 性能对比根据 Cloudflare 官方公布的数据Pingora 在生产环境中的表现相当惊人指标Nginx (旧系统)PingoraCPU 使用率基准 (100%)↓ 约 70%内存使用基准 (100%)↓ 约 67%TTFB 中位数基准↓ 约 5msTTFB 95 分位基准↓ 约 80ms用一个更直观的说法每天Pingora 为 Cloudflare 的客户节省了相当于434 年的握手等待时间。5.2 架构对比Nginx 架构多进程模型每个 worker 独立每个进程有独立的连接池进程间通信开销大连接复用率低C 语言编写内存安全风险Pingora 架构多线程模型共享地址空间全局共享连接池线程间资源共享高效连接复用率高减少握手Rust 语言编写内存安全5.3 开发体验对比Nginx/OpenResty配置文件驱动简单场景上手快复杂逻辑需要用 Lua 编写C 和 Lua 之间有数据转换开销模块开发门槛高需要深入理解 Nginx 内部生态成熟第三方模块丰富Pingora完全用 Rust 代码编写配置和逻辑类型安全编译期就能发现很多错误统一的编程语言没有跨语言开销API 设计清晰扩展相对容易生态较新还在快速发展中5.4 适用场景对比场景NginxPingora静态文件服务✅ 成熟稳定⚠️ 非主要场景反向代理✅ 经典选择✅ 性能更优负载均衡✅ 功能完善✅ 更高效大规模流量⚠️ 资源消耗大✅ 更省资源定制化代理逻辑⚠️ Lua 开发✅ Rust 原生开发快速部署简单场景✅ 配置简单⚠️ 需要写代码六、快速上手示例让我们来看一个最简单的 Pingora 负载均衡示例use pingora::prelude::*; use std::sync::Arc; pub struct LB(ArcLoadBalancerRoundRobin); #[async_trait] impl ProxyHttp for LB { async fn upstream_peer(self, _session: mut Session, _ctx: mut () ) - ResultBoxHttpPeer { 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 PingoraCloudflare 官方博客Open sourcing PingoraPingora GitHub 仓库cloudflare/pingora
（支持资料、图片参考_相关定制）_可以扫码)
