2. 为什么要重新构建代理？
Nginx 的限制
性能瓶颈：Nginx 使用的 worker 模型存在着资源调度不均的问题。具体来说，它通过多进程来处理请求，但是不同的 CPU 核心负载不均，导致了性能的浪费。尤其是在多核 CPU 上，Nginx 无法完全发挥硬件的性能优势。😕 修改难度大：Nginx 本身非常稳定，但它并不那么灵活。如果你需要根据自己的需求做复杂的定制，比如请求重试、复杂的错误处理等，你就得动手改它的源代码。问题来了，修改源码这种事儿不好做——修改起来很复杂，而且很容易出错，甚至有可能影响到系统的稳定性。 内存安全问题：Nginx 是用 C 语言写的，C 语言直接操作内存，虽然高效，但这也带来了内存安全问题。小心驶得万年船，代码一不小心就可能出现内存泄漏或崩溃，这对于一个高并发的 Web 服务来说是个大问题。
所以，Cloudflare 决定彻底换掉这个“老朋友”，用更现代的解决方案来迎接未来的挑战。
3. Pingora 的设计决策
为什么选择 Rust？
自建 HTTP 库
多线程 vs 多进程
可编程接口
4. Pingora 性能提升
响应时间提升：Pingora 在处理请求时，TTFB (第一个字节时间) 中位数减少了 5 毫秒，第 95 百分位数减少了整整 80 毫秒！这意味着用户请求的响应速度更快，体验更流畅。 连接重用率大幅提升：Pingora 在连接重用方面表现得非常出色。它将连接重用率从原来的 87.1% 提高到 99.92%！这直接导致了新连接数大幅减少，减少了 TCP 握手的开销，节省了大量的资源。想象一下，原本每次请求都需要重新建立连接，现在能重复使用已经建立的连接，不仅节省时间，还能减轻系统负担。 节省 CPU 和内存：Pingora 在 CPU 和内存上的消耗分别减少了 70% 和 **67%**！也就是说，在处理同样规模的请求时，Pingora 用更少的资源完成了更多的工作。效率简直让人拍案叫绝。
5. Pingora 功能扩展
支持新协议：Pingora 支持 HTTP/2 和 gRPC 上游协议，这对大规模分布式系统非常有用，尤其是在处理 API 请求时，gRPC 的低延迟优势更是能有效提升系统整体的响应速度。 Cache Reserve 功能：为了进一步提升性能，Pingora 集成了 Cloudflare 自家的 R2 存储作为缓存层，这可以大大加快静态资源的加载速度，减少了对后端服务器的压力。
6. Pingora 安全性提升
内存安全：Rust 本身就是为了避免内存问题而设计的。通过 Rust 的所有权机制，Pingora 不仅提高了性能，还减少了未定义行为的风险。相比 C 语言的裸指针操作，Rust 的内存管理更加安全，系统崩溃的概率也大大降低。 稳定性：Pingora 已经处理了数百万亿个请求，而服务崩溃的事件极为罕见。这种高稳定性让它在面对云端的高并发、高流量时，依然能够保持良好的性能。
7. 结语
对编程、职场感兴趣的同学，可以链接我，微信：coder301 拉你进入“程序员交流群”。
