p2p网站开发维护,网站更新后 为什么不显示,网站 规划,网络设计是什么意思一、概述
Cloudflare 为何弃用 Nginx#xff0c;选择使用 Rust 重新构建新的代理 Pingora 框架。Cloudflare 成立于2010年#xff0c;是一家领先的云服务提供商#xff0c;专注于内容分发网络#xff08;CDN#xff09;和分布式域名解析。它提供一系列安全和性能优化服务…一、概述
Cloudflare 为何弃用 Nginx选择使用 Rust 重新构建新的代理 Pingora 框架。Cloudflare 成立于2010年是一家领先的云服务提供商专注于内容分发网络CDN和分布式域名解析。它提供一系列安全和性能优化服务包括防火墙、DDoS防护、SSL/TLS加密和威胁分析。
二、Pingora 介绍
Pingora 是一个基于 Rust 语言的框架用于构建快速、可靠且可编程的网络系统。日处理请求量超 1万亿次不仅在性能显著提升且仅需原代理基础设施三分之一的 CPU 和内存资源。
三、Nginx 在当今需求下遇到的瓶颈
随着 Cloudflare 规模的扩大已经超越了 Nginx 的处理能力了无法满足当下所需要的性能Nginx 也没有在非常复杂的环境中有所需要的功能。
虽然这些年来Cloudflare 有对 Nginx 的使用遇到了部分限制进行了优化但是仍然有一些限制则更难克服如下
首先在 Nginx 中每个请求只能由单个 worker 处理这样很容易导致所有 CPU 内核之间的负载不平衡从而导致速度变慢。由于这种请求进程锁定效应执行 CPU 繁重或阻止 IO 任务的请求可能会减慢其他请求的速度。
对于这些问题花了很多时间来解决但是对于 Cloudflare 规模的用例来说最关键的问题是糟糕的连接重用。机器与原始服务器建立 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 的 TLSgRPC 和 websocket 代理优雅的重载可定制的负载平衡和故障转移策略支持多种观测工具
七、Pingora 生产环境后的反馈
更高效
在生产环境中与我们的旧服务相比Pingora 在相同流量负载的情况下消耗的 CPU 和内存减少了约 70% 和 67%。以及多线程模型还使得跨请求共享数据更加高效。
更安全
像我们这样的规模下快速安全的发布功能十分困难。很难预测在每秒处理数百万个请求的分布式环境中可能发生的每个边缘情况。Rust 的内存安全特性为我们提供了强大的保护让我们能够信赖服务的稳定运行。更能够专注于服务间的交互加速功能开发无需担忧内存安全问题。
即便出现崩溃Pingora 的稳定性也显著降低诊断难度。自推出以来尽管处理了海量请求但服务代码尚未导致任何崩溃显示出其卓越的可靠性。
所以Pingora 的崩溃极为罕见问题往往与内核或硬件故障无关。即便在极端调试困难的情况下软件也未导致过崩溃。
从中我们可以看到 Rust 逐渐进入生产环境中而且取得了很不错的效果也相信未来 AI 领域Rust 一定会带来很多资源节省、性能的提升及安全等。
