大家好，我是渔夫。
时间匆匆，咱们又来到3月份了。
今天分享主题，Cloudflare 为何弃用 Nginx，选择使用 Rust 重新构建新的代理 Pingora 框架。
Cloudflare 是什么？
Cloudflare 成立于2010年，是一家领先的云服务提供商，专注于内容分发网络（CDN）和分布式域名解析。它提供一系列安全和性能优化服务，包括防火墙、DDoS防护、SSL/TLS加密和威胁分析。
Pingora 介绍
Pingora 是一个基于 Rust 语言的框架，用于构建快速、可靠且可编程的网络系统。日处理请求量超 1万亿次，不仅在性能显著提升，且仅需原代理基础设施三分之一的 CPU 和内存资源。
为什么弃用 Nginx，重新再建一个代理
随着 Cloudflare 规模的扩大，已经超越了 Nginx 的处理能力了，无法满足当下所需要的性能，Nginx 也没有在非常复杂的环境中所需要的功能。
虽然这些年来，Cloudflare 有对 Nginx 的使用遇到了部分限制，进行了优化，但是仍然另一些限制则更难克服，如下：
首先，在 Nginx 中，每个请求只能由单个 worker 处理，这样很容易导致所有 CPU 内核之间的负载不平衡，从而导致速度变慢。由于这种请求进程锁定效应，执行 CPU 繁重或阻止 IO 任务的请求可能会减慢其他请求的速度。
对于这些问题，花了很多时间来解决，但是对于我们的用例来说，最关键的问题是糟糕的连接重用。我们的机器与原始服务器建立 TCP 连接，以代理 HTTP 请求。连接重用通过重用之前从连接池建立的连接，跳过新连接所需的 TCP 和 TLS 握手，来加快请求的 TTFB。
但是，Nginx 连接池与单个 worker 相对应，当请求到达某个 worker 时，它只能重用该 worker 内的连接。当我们添加更多 Nginx worker 以进行扩展时，我们的连接重用率会变得更差，因为连接分散在所有进程的更多孤立的池中。这导致更慢的 TTFB 以及需要维护更多连接，进而消耗我们和客户的资源。
Nginx 在当今需求下遇到的瓶颈
Nginx 是一个非常好的 Web 服务器、负载均衡器或简单的网关。但对于 Cloudflare 的作用远不止于此。我们过去常常围绕 Nginx 构建我们需要的所有功能，但要尽量避免与 Nginx 上游代码库有太多分歧，不是一件很容易事情。
例如，当重试请求/请求失败时，将请求重定向到具有不同请求头的目标服务器，但 Nginx 并不支持这种操作，这要求我们投入额外的努力来克服其限制，这种情况下，还需要我们额外花费时间和精力来解决 Nginx 的限制。
其次，Nginx 是用C语言编写的，其内存管理并非安全，增加了出错的风险，而且使用第三方代码库非常容易出错。即使对于经验丰富的工程师来说，也很容易陷入内存安全问题，我们希望尽可能避免这些问题。
为了补充C语言，我们使用了 Lua，它相对安全但性能较低。在处理复杂的 Lua 代码时，我们经常怀念静态类型的便利，而且 Nginx 社区的活跃度不高，开发过程往往较为封闭。
Pingora 项目设计决定
为了打造一个每秒提供数百万次请求且快速、高效和安全的代理，我们必须首先做出一些重要的设计决定。设计核心如下：
-
选择 Rust 语言：因为它可以在不影响性能的情况下以内存安全的方式完成 C 语言可以做的事情。
-
自建 HTTP 库：选择自建的 HTTP 库而非现成的第三方库，以提高处理HTTP流量的灵活性和自主创新的能力。
-
支持多样化、不符合 RFC 的HTTP流量：由于Cloudflare需要支持各种不符合RFC标准的HTTP流量，Pingora设计为一个稳健、宽容、可定制的HTTP库，以适应互联网各种风险环境和不规范的用例。
-
处理非标准的HTTP状态码：为了应对服务器支持使用599到999之间的状态代码，Pingora实现了一个稳健的HTTP状态码处理系统，以适应不同HTTP生态系统中的多样性。
-
多线程工作负载调度：Pingora选择了多线程而不是多进程，以便轻松共享资源，特别是连接池。采用Tokio异步运行时来避免性能问题，并实施了工作窃取以提高效率。
-
基于请求生命周期的可编程接口：实施了类似于NGINX/OpenResty的基于“请求生命周期”事件的可编程接口。这使得开发人员能够通过编写代码在请求的不同阶段进行干预，例如在请求标头接收时修改或拒绝请求，从而清晰地分离业务逻辑和通用代理逻辑。
很完美，Pingora 在生产中更快
Pingora 处理几乎所有需要与源服务器交互的 HTTP 请求（例如缓存未命中），我们在此过程中收集了很多性能数据。
首先，让我们看看 Pingora 如何加快我们客户的流量。Pingora 上的总体流量显示，TTFB 中位数减少了 5 毫秒，第 95 个百分位数减少了 80 毫秒。这不是因为我们运行代码更快。甚至我们的旧服务也可以处理亚毫秒范围内的请求。
时间节省来自我们的新架构，它可以跨所有线程共享连接，这意味着更好的连接重用率，在 TCP 和 TLS 握手上花费的时间更少。
在所有客户中，与旧服务相比，Pingora 每秒的新连接数只有三分之一。对于一个主要客户，它将连接重用率从 87.1% 提高到 99.92%，这将新连接减少了 160 倍。更直观地说，通过切换到 Pingora，我们每天为客户和用户节省了 434 年的握手时间。
Pingora 功能亮点
-
异步 Rust 快速且可靠
-
HTTP 1/2 端到端代理
-
基于 OpenSSL 或 BoringSSL 的 TLS
-
gRPC 和 websocket 代理
-
优雅的重载
-
可定制的负载平衡和故障转移策略
-
支持多种观测工具
Pingora 生产环境后的反馈
1、更高效：在生产环境中，与我们的旧服务相比，Pingora 在相同流量负载的情况下，消耗的 CPU 和内存减少了约 70% 和 67%。以及多线程模型还使得跨请求共享数据更加高效。
2、更安全：像我们这样的规模下，快速安全地发布功能十分困难。很难预测在每秒处理数百万个请求的分布式环境中可能发生的每个边缘情况。Rust 的内存安全特性为我们提供了强大的保护，让我们能够信赖服务的稳定运行。这让我们能够专注于服务间的交互，加速功能开发，无需担忧内存安全问题。
即便出现崩溃，Pingora 的稳定性也显著降低诊断难度。自推出以来，尽管处理了海量请求，但服务代码尚未导致任何崩溃，显示出其卓越的可靠性。
所以，Pingora 的崩溃极为罕见，问题往往与内核或硬件故障无关。即便在极端调试困难的情况下，我们的软件也未导致过崩溃。
参考资料：
我是渔夫，现在在国内某某云程序员，业余独立开发者，探索副业，生活、技术、非科班转码经验等相关文章，欢迎关注，和渔夫一起成长。
