2024 年 2 月Cloudflare 宣布将 Pingora 以 Apache 2.0 协议开源。Pingora 不是一个新项目。在此之前它已经在 Cloudflare 的全球网络上悄悄运行了相当长时间处理了将近一千万亿次互联网请求。Cloudflare 用它替换了 NGINX它是 CDN、WAF、Workers 等核心产品背后的代理引擎。这次开源是 Cloudflare 第一次把这个内部核心框架完整地交给社区。原文链接https://blog.cloudflare.com/pingora-open-source/开源仓库https://github.com/cloudflare/pingora文档https://github.com/cloudflare/pingora/tree/main/docs为什么在这个时间节点开源在技术层面Pingora 的定位很清楚——一个用 Rust 编写的异步多线程 HTTP 代理框架。但开源的动机不只是分享一个好用的库这么简单。2024 年初前后内存安全的话题在行业里密度明显上升。美国白宫发布技术报告明确点名内存不安全语言带来的系统性安全风险呼吁向内存安全语言迁移。微软、谷歌等公司陆续公开内部数据表明大量安全漏洞的根源是 C/C 代码里的内存管理错误。在这个背景下Cloudflare 开源 Pingora 的意图超出了一次普通的技术分享他们希望为那些仍在用 C/C 构建网络基础设施的团队提供一条可验证的迁移路径。为了推动这件事落地Cloudflare 还专门与ISRG互联网安全研究组也就是 Let’s Encrypt 的母组织下的 Prossimo 项目展开合作目标是把 Pingora 推向互联网最关键的基础设施层。Pingora 到底能做什么Pingora 的定位是一个框架而不是一个开箱即用的产品。它提供的是构建网络服务所需的底层积木使用者在上面实现自己的业务逻辑。协议支持方面Pingora 覆盖了主流场景HTTP/1 和 HTTP/2 的端到端代理gRPC 和 WebSocket 代理TLS、TCP 和 Unix Domain SocketHTTP/3 列在路线图上尚未发布负载均衡方面框架内置了轮询、哈希等常用策略也支持完全自定义的服务器选择逻辑。安全方面同时支持 OpenSSL 和 BoringSSLBoringSSL 的版本支持 FIPS 合规和后量子密钥协商。运维方面支持零停机优雅重启——升级服务时不丢弃任何进行中的连接。可观测性方面Syslog、Prometheus、Sentry、OpenTelemetry 等工具都可以直接集成。什么样的团队适合用 PingoraCloudflare 在博客里列了三类场景值得对号入座安全优先的场景如果你的服务目前是 C/C 写的且面临过内存安全相关的漏洞或审计压力Pingora 是一个经过生产验证的替代方案。Cloudflare 自己的经验是迁移到 Rust 之后内存类 bug 在代码评审和上线后几乎不再出现这让工程师有更多精力做功能迭代。性能敏感的场景相比 NGINX 的多进程模型Pingora 的多线程架构让所有线程共享同一个连接池连接复用率显著更高。Cloudflare 内部数据显示迁移后 CPU 节省约 70%内存节省约 67%。需要深度定制的场景Pingora 提供了一套类似 OpenResty*_by_lua风格的回调体系可以在请求处理的不同阶段注入自定义逻辑——修改请求头、重写路由、自定义认证、记录日志。如果你需要构建一个高度定制的网关或负载均衡器Pingora 的 API 设计方向和你的需求天然匹配。动手50 行 Rust 写一个负载均衡器博客里给出了一个完整的示例展示 Pingora 的编程模型。以下把这个例子拆开讲清楚。第一步定义代理结构体Pingora 里任何实现了ProxyHttptrait 的结构体就是一个 HTTP 代理。这个 trait 唯一必须实现的方法是upstream_peer()每个请求进来都会调用它返回值决定请求被转发到哪台服务器pubstructLB(ArcLoadBalancerRoundRobin);#[async_trait]implProxyHttpforLB{asyncfnupstream_peer(self,_session:mutSession,_ctx:mutSelf::CTX,)-ResultBoxHttpPeer{letupstreamself.0.select(b,256)// 轮询模式下哈希值无关紧要.unwrap();// 设置 SNI指向目标域名letpeerBox::new(HttpPeer::new(upstream,true,one.one.one.one.to_string()));Ok(peer)}}这里的LoadBalancerRoundRobin是框架内置的直接用就行。如果需要更复杂的选择逻辑——比如根据请求参数做哈希或者接入服务发现——在这个函数里自己实现即可。第二步启动服务把服务器 IP 硬编码进去绑定一个本地端口服务就起来了fnmain(){letupstreamsLoadBalancer::try_from_iter([1.1.1.1:443,1.0.0.1:443]).unwrap();letmutlbpingora_proxy::http_proxy_service(my_server.configuration,LB(Arc::new(upstreams)));lb.add_tcp(127.0.0.1:6188);letmutmy_serverServer::new(None).unwrap();my_server.add_service(lb);my_server.run_forever();}实际工程里上游服务器列表可以来自服务发现系统在upstream_peer()被调用时动态查询或者在后台线程里定期刷新。第三步用过滤器修改请求头把上面的代码跑起来用 curl 测试会发现服务器返回 403。原因是代理直接把客户端发来的Host: 127.0.0.1:6188转发给了上游上游不认识这个 Host直接拒绝了。修复方式是加一个upstream_request_filter在请求发出去之前把 Host 头改掉asyncfnupstream_request_filter(self,_session:mutSession,upstream_request:mutRequestHeader,_ctx:mutSelf::CTX,)-Result(){upstream_request.insert_header(Host,one.one.one.one).unwrap();Ok(())}加上这个过滤器之后请求正常返回 200。这个例子展示的是 Pingora 编程模型的核心思路框架处理连接池、TLS 握手、读写缓冲、协议解析这些通用逻辑你只需要实现关心的那几个回调。目前 Pingora 提供了覆盖请求生命周期各阶段的过滤器包括请求到达、上游连接建立、请求转发、响应接收、响应转发等。需要了解的现实局限Pingora 是一个引擎而不是一辆完整的车——这是博客里 Cloudflare 自己打的比方。它目前是一个库和工具集不是一个像 Nginx 那样配置几行就能跑起来的独立程序。如果你的目标是零代码配置一个反向代理Pingora 不是正确的起点。Cloudflare 正在和 ISRG 合作在 Pingora 之上构建一个更完整、更开箱即用的产品但那是另一个项目。另外两个重要的注意事项API 稳定性Pingora 目前处于 1.0 之前的阶段API 随时可能变动过滤器的签名和行为都可能在后续版本里调整。如果要在生产环境引入需要做好适配升级的心理准备。操作系统支持目前只支持 Unix 系的系统Linux、macOS。Windows 暂时不在路线图上。开源之后在规模上Pingora 是少数几个经过真正大规模验证的 Rust 网络框架之一。它不是实验性的而是在 Cloudflare 每天承载数百亿次请求的生产环境里跑了多年。对于正在考虑以下任何一件事的团队它值得认真评估把现有的 C/C 代理服务迁移到内存安全的实现构建一个需要深度定制的 API 网关或流量控制层在高性能要求下用 Rust 构建网络服务它也是目前 Rust 网络服务生态里罕见的同时满足经过大规模生产验证和提供完整可编程 API两个条件的框架。