正文
我们选择 Rust 作为项目的语言，因为它可以在不影响性能的情况下以内存安全的方式完成 C 语言可以做的事情。
尽管有一些很棒的现成第 3 方 HTTP 库，例如 hyper，我们选择构建自己的库是因为我们希望最大限度地提高处理 HTTP 流量的灵活性，并确保我们可以按照自己的节奏进行创新。
在 Cloudflare，我们处理整个互联网的流量。我们必须支持许多奇怪且不符合 RFC 的 HTTP 流量案例。这是 HTTP 社区和 Web 中的一个常见困境，在严格遵循 HTTP 规范，和适应潜在遗留客户端或服务器的广泛生态系统的细微差别之间存在矛盾和冲突，需要在其中作出艰难抉择。
HTTP 状态码在 RFC 9110 中定义为一个三位整数，通常预期在 100 到 599 的范围内。Hyper 就是这样一种实现。但是，许多服务器支持使用 599 到 999 之间的状态代码。我们为此功能创建了一个问题，探讨了争论的各个方面。虽然 hyper 团队最终确实接受了这一更改，但他们有充分的理由拒绝这样的要求，而这只是我们需要支持的众多不合规行为案例之一。
为了满足 Cloudflare 在 HTTP 生态系统中的地位要求，我们需要一个稳健、宽容、可定制的 HTTP 库，该库可以在互联网的各种风险环境中生存，并支持各种不合规的用例。保证这一点的最佳方法就是实施我们自己的架构。
下一个设计决策关于我们的工作负载调度系统。我们选择多线程而不是多处理，以便轻松共享资源，尤其是连接池。我们认为还需要实施工作窃取来避免上面提到的某些类别的性能问题。Tokio 异步运行时结果非常适合我们的需求。
最后，我们希望我们的项目直观且对开发人员友好。我们构建的不是最终产品，而是应该可以作为一个平台进行扩展，因为在它之上构建了更多的功能。我们决定实施一个类似于 NGINX/OpenResty 的基于“请求生命周期”事件的可编程接口。例如，“请求过滤器”阶段允许开发人员在收到请求标头时运行代码来修改或拒绝请求。通过这种设计，我们可以清晰地分离我们的业务逻辑和通用代理逻辑。之前从事 NGINX 工作的开发人员可以轻松切换到 Pingora 并迅速提高工作效率。
Pingora 在生产中更快
让我们快进到现在。Pingora 处理几乎所有需要与源服务器交互的 HTTP 请求（例如缓存未命中），我们在此过程中收集了很多性能数据。
首先，让我们看看 Pingora 如何加快我们客户的流量。Pingora 上的总体流量显示，TTFB 中位数减少了 5 毫秒，第 95 个百分位数减少了 80 毫秒。这不是因为我们运行代码更快。甚至我们的旧服务也可以处理亚毫秒范围内的请求。
时间节省来自我们的新架构，它可以跨所有线程共享连接。这意味着更好的连接重用率，在 TCP 和 TLS 握手上花费的时间更少。
在所有客户中，与旧服务相比，Pingora 每秒的新连接数只有三分之一。对于一个主要客户，它将连接重用率从 87.1% 提高到 99.92%，这将新连接减少了 160 倍。更直观地说，通过切换到 Pingora，我们每天为客户和用户节省了 434 年的握手时间。
更多功能
拥有工程师熟悉的开发人员友好界面，同时消除以前的限制，让我们能够更快地开发更多功能。像新协议这样的核心功能充当我们为客户提供更多产品的基石。
例如，我们能够在没有重大障碍的情况下向 Pingora 添加 HTTP/2 上游支持。这使我们能够在不久之后向我们的客户提供 gRPC。将相同的功能添加到 NGINX 将需要更多的工程工作，并且可能无法实现。
最近，我们宣布推出了 Cache Reserve，其中 Pingora 使用 R2 存储作为缓存层。随着我们向 Pingora 添加更多功能，我们能够提供以前不可行的新产品。
更高效
在生产环境中，与我们的旧服务相比，Pingora 在相同流量负载的情况下，消耗的 CPU 和内存减少了约 70% 和 67%。节省来自几个因素。
与旧的 Lua 代码相比，我们的 Rust 代码运行效率更高。最重要的是，它们的架构也存在效率差异。例如，在 NGINX/OpenResty 中，当 Lua 代码想要访问 HTTP 头时，它必须从 NGINX C 结构中读取它，分配一个 Lua 字符串，然后将其复制到 Lua 字符串中。之后，Lua 还对其新字符串进行垃圾回收。在 Pingora 中，它只是一个直接的字符串访问。
多线程模型还使得跨请求共享数据更加高效。NGINX 也有共享内存，但由于实施限制，每次共享内存访问都必须使用互斥锁，并且只能将字符串和数字放入共享内存。在 Pingora 中，大多数共享项目可以通过原子引用计数器后面的共享引用直接访问。
如上所述，CPU 节省的另一个重要部分是减少了新的连接。与仅通过已建立的连接发送和接收数据相比，TLS 握手成本显然更为高昂。
更安全
在我们这样的规模下，快速安全地发布功能十分困难。很难预测在每秒处理数百万个请求的分布式环境中可能发生的每个边缘情况。模糊测试和静态分析只能缓解这么多。Rust 的内存安全语义保护我们免受未定义行为的影响，并让我们相信我们的服务将正确运行。
有了这些保证，我们可以更多地关注我们的服务更改将如何与其他服务或客户来源进行交互。我们能够以更高的节奏开发功能，而不用背负内存安全和难以诊断崩溃的问题。
当崩溃确实发生时，工程师需要花时间来诊断它是如何发生的以及是什么原因造成的。自 Pingora 创立以来，我们已经处理了数百万亿个请求，至今尚未因为我们的服务代码而崩溃。
事实上，Pingora 崩溃是如此罕见，当我们遇到一个问题时，我们通常会发现不相关的问题。最近，我们的服务开始崩溃后不久，我们发现了一个内核错误。我们还在一些机器上发现了硬件问题，过去排除了由我们的软件引起的罕见内存错误，即使在几乎不可能进行重大调试之后也是如此。
总结
