Cloudflare 公司去年宣布弃用 nginx，转用自研的新一代方向代理服务 Pingora，并号称比nginx更快、更高效、更安全，下面通过 Cloudfare 官方网站的一篇文章来了解下 Pingora 比 Nginx 强在哪里？

简介

今天，我们很高兴有机会在此介绍 Pingora，这是我们使用 Rust 在内部构建的新 HTTP 代理，它每天处理超过 1 万亿个请求，提高了我们的性能，并为 Cloudflare 客户带来了许多新功能，同时只需要我们以前代理基础架构的三分之一的 CPU 和内存资源。

随着 Cloudflare 规模的扩大，我们已经超越了 NGINX 的处理能力。多年来它一直运作良好，但随着时间的推移，它在我们规模上的局限性意味着我们有必要构建一些新的东西。我们无法再获得我们所需要的性能，NGINX 也没有我们在非常复杂的环境中所需要的功能。

为什么要再建一个代理

作为世界上最大的免费 CDN 服务商，Cloudflare 的代理端层运行这世界上最大Web请求，每天的客户端请求超万亿。之前 Cloudflare 的代理端层架构一度使用的基于内部定制化的 Nginx 服务器，但是无论在性能上，规模上以及功能层面都面临日益困窘的局面。

架构的限制损害了性能

NGINX worker（进程）架构对于我们的用例而言存在操作缺陷，这会损害我们的性能和效率。

首先，在 NGINX 中，每个请求只能由单个 worker 处理。这会导致所有 CPU 内核之间的负载不平衡，从而导致速度变慢。

由于这种请求进程锁定效应，执行重CPU 或阻塞IO 任务的请求可能会减慢其他请求的速度。举实际用例来说，最大问题问题是连接重用性问题。代理层节点机器与源服务器建立TCP 连接以代理HTTP 请求。连接重用通过重用连接池中先前建立的连接、跳过新连接所需的 TCP 和TLS 握手来加速请求的TTFB（第一个字节时间）。

但是，NGINX 连接池基于Work的。当请求到达某个Work时，它只能重用该Work内的连接。当添加更多NGINX Work进行扩展时，由于连接分散在所有进程的更多隔离池中其重用性就会变得很差，这样就需要耗费额外的硬件资源，并且使响应时间变慢。

虽然在这方面通过各种方法做过优化，但是其根源在于Nginx Work/进程模型，在要还是该架构就不能从根本上解决该问题 。

有些类型的功能难以添加

NGINX是一个非常好的Web 服务器、负载均衡器或网关。但Cloudflare 的业务需求远不止于此。围绕NGINX 构建我们需要的所有功能，但要尽量避免与 NGINX 上游代码库有太多分歧，这并不容易。

例如，当重试/失败请求时，业务场景最佳需求是将请求发送到具有不同请求标头集的不同源服务器。但这不是NGINX 允许应用层可做的事情。为此会花费时间和精力来解决 修改NGINX源码来突破限制。

另外NGINX 纯粹是用C语言编写的，其设计上不是内存安全的。使用这样的第三方代码库非常容易出错。也很容易出现内存安全问题 ，如何尽可能避免这些问题是个问题。

虽然Nginx的应用逻辑可以通过Lua语言来实现。可以导致的安全风险较小，但性能也较差。此外，Lua在处理复杂的代码和业务逻辑时缺乏有效的静态类型检查。务逻辑时，我们经常发现自己缺少静态类型。

而且 NGINX 社区也不是很活跃，开发往往是“闭门造车”。

选择建立我们自己的

在过去的几年里，随着我们的客户群和功能集的持续增长，我们持续评估了三种选择：

继续投资 NGINX，向其付款进行定制，使其 100% 满足我们的需求。我们拥有所需的专业知识，但鉴于上述架构限制，需要付出大量努力才能以完全支持我们需求的方式重建它。

迁移到另一个第三方代理代码库。肯定有好的项目，比如 envoy 和其他一些。但这条道路意味着在几年内可能会重复同样的循环。

从头开始建立一个内部平台和框架。这一选择需要在工程方面进行最大的前期投资。

在过去的几年中，我们每个季度都会对这些选项进行评估。没有明显的公式来判断哪种选择是最好的。在几年的时间里，我们继续走阻力最小的道路，继续增强 NGINX。然而，在某些情况下，建立自有代理的投资回报率似乎更值得。我们呼吁从头开始建立一个代理，并开始设计我们梦想中的代理应用程序。

Pingora 项目

设计决定

为了打造一个每秒提供数百万次请求且快速、高效和安全的代理，我们必须首先做出一些重要的设计决定。

我们选择 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 崩溃是如此罕见，当我们遇到一个问题时，我们通常会发现不相关的问题。最近，我们的服务开始崩溃后不久，我们发现了一个内核错误。我们还在一些机器上发现了硬件问题，过去排除了由我们的软件引起的罕见内存错误，即使在几乎不可能进行重大调试之后也是如此。

总结

总而言之，Cloudflare 在内部已经启用一个一个更快、更高效、更通用的内部代理Pingora，作为起当前和未来产品的代理层架构平台。Cloudflare后续会在适当的累积和总结后开源Pingora。