Cloudflare公司去年宣布棄用Nginx，轉(zhuǎn)用自研的新一代反向代理服務(wù)Pingora，并號(hào)稱比nginx更快、更高效、更安全，下面通過Cloudfare官方網(wǎng)站的一篇文章來了解下Pingora比Nginx強(qiáng)在哪里。
簡(jiǎn)介
今天，我們很高興有機(jī)會(huì)在此介紹 Pingora，這是我們使用 Rust 在內(nèi)部構(gòu)建的新 HTTP 代理，它每天處理超過 1 萬億個(gè)請(qǐng)求，提高了我們的性能，并為 Cloudflare 客戶帶來了許多新功能，同時(shí)只需要我們以前代理基礎(chǔ)架構(gòu)的三分之一的 CPU 和內(nèi)存資源。
隨著 Cloudflare 規(guī)模的擴(kuò)大，我們已經(jīng)超越了 NGINX 的處理能力。多年來它一直運(yùn)作良好，但隨著時(shí)間的推移，它在我們規(guī)模上的局限性意味著我們有必要構(gòu)建一些新的東西。我們無法再獲得我們所需要的性能，NGINX 也沒有我們?cè)诜浅?fù)雜的環(huán)境中所需要的功能。
許多 Cloudflare 客戶和用戶使用 Cloudflare 全球網(wǎng)絡(luò)作為 HTTP 客戶端（例如 Web 瀏覽器、應(yīng)用程序、物聯(lián)網(wǎng)設(shè)備等）和服務(wù)器之間的代理。過去，對(duì)于瀏覽器和其他用戶代理如何連接到我們的網(wǎng)絡(luò)，我們已進(jìn)行過許多討論，我們開發(fā)了很多技術(shù)并實(shí)施了新協(xié)議（參見 QUIC 和 http2 優(yōu)化）來使這段連接更高效。
今天，我們將關(guān)注這個(gè)等式的另一部分：代理我們的網(wǎng)絡(luò)和互聯(lián)網(wǎng)上服務(wù)器之間的流量的服務(wù)。這個(gè)代理服務(wù)為我們的 CDN、Workers fetch、Tunnel、Stream、R2 以及許多其他功能和產(chǎn)品提供了動(dòng)力。
讓我們研究為什么我們選擇取代我們的舊版服務(wù)以及 Pingora 的開發(fā)過程，這是我們專門為 Cloudflare 的客戶用例和規(guī)模而設(shè)計(jì)的新系統(tǒng)。
為什么要再建一個(gè)代理
這些年來，我們對(duì) NGINX 的使用遇到了限制。對(duì)于部分限制，我們進(jìn)行了優(yōu)化或選擇繞過它們。但另一些限制則更難克服。
架構(gòu)的限制損害了性能
NGINX worker（進(jìn)程）架構(gòu)對(duì)于我們的用例而言存在操作缺陷，這會(huì)損害我們的性能和效率。
首先，在 NGINX 中，每個(gè)請(qǐng)求只能由單個(gè) worker 處理。這會(huì)導(dǎo)致所有 CPU 內(nèi)核之間的負(fù)載不平衡，從而導(dǎo)致速度變慢。
由于這種請(qǐng)求進(jìn)程鎖定效應(yīng)，執(zhí)行 CPU 繁重或阻止 IO 任務(wù)的請(qǐng)求可能會(huì)減慢其他請(qǐng)求的速度。正如這些博客文章所表明的那樣，我們已經(jīng)花了很多時(shí)間來解決這些問題。
對(duì)于我們的用例來說，最關(guān)鍵的問題是糟糕的連接重用。我們的機(jī)器與原始服務(wù)器建立 TCP 連接，以代理 HTTP 請(qǐng)求。連接重用通過重用之前從連接池建立的連接，跳過新連接所需的 TCP 和 TLS 握手，來加快請(qǐng)求的 TTFB（首字節(jié)時(shí)間）。
但是，NGINX 連接池與單個(gè) worker 相對(duì)應(yīng)。當(dāng)請(qǐng)求到達(dá)某個(gè) worker 時(shí)，它只能重用該 worker 內(nèi)的連接。當(dāng)我們添加更多 NGINX worker 以進(jìn)行擴(kuò)展時(shí)，我們的連接重用率會(huì)變得更差，因?yàn)檫B接分散在所有進(jìn)程的更多孤立的池中。這導(dǎo)致更慢的 TTFB 以及需要維護(hù)更多連接，進(jìn)而消耗我們和客戶的資源（和金錢）。
正如在過去的博客文章中所提到的，我們?yōu)槠渲幸恍﹩栴}提供了解決方法。但如果我們能夠解決根本問題：worker/進(jìn)程模型，我們將自然而然地解決所有這些問題。
有些類型的功能難以添加
NGINX 是一個(gè)非常好的 Web 服務(wù)器、負(fù)載均衡器或簡(jiǎn)單的網(wǎng)關(guān)。但 Cloudflare 的作用遠(yuǎn)不止于此。我們過去常常圍繞 NGINX 構(gòu)建我們需要的所有功能，但要盡量避免與 NGINX 上游代碼庫有太多分歧，這并不容易。
例如，當(dāng)重試請(qǐng)求/請(qǐng)求失敗時(shí)，有時(shí)我們希望將請(qǐng)求發(fā)送到具有不同請(qǐng)求標(biāo)頭集的不同源服務(wù)器。但 NGINX 并不允許執(zhí)行此操作。在這種情況下，我們需要花費(fèi)時(shí)間和精力來解決 NGINX 的限制。
同時(shí)，我們被迫使用的編程語言并沒有幫助緩解這些困難。NGINX 純粹是用 C 語言編寫的，這在設(shè)計(jì)上不是內(nèi)存安全的。使用這樣的第 3 方代碼庫非常容易出錯(cuò)。即使對(duì)于經(jīng)驗(yàn)豐富的工程師來說，也很容易陷入內(nèi)存安全問題，我們希望盡可能避免這些問題。
我們用來補(bǔ)充 C 語言的另一種語言是 Lua。它的風(fēng)險(xiǎn)較小，但性能也較差。此外，在處理復(fù)雜的 Lua 代碼和業(yè)務(wù)邏輯時(shí)，我們經(jīng)常發(fā)現(xiàn)自己缺少靜態(tài)類型。
而且 NGINX 社區(qū)也不是很活躍，開發(fā)往往是“閉門造車”。
選擇建立我們自己的
在過去的幾年里，隨著我們的客戶群和功能集的持續(xù)增長(zhǎng)，我們持續(xù)評(píng)估了三種選擇：
繼續(xù)投資 NGINX，向其付款進(jìn)行定制，使其 100% 滿足我們的需求。我們擁有所需的專業(yè)知識(shí)，但鑒于上述架構(gòu)限制，需要付出大量努力才能以完全支持我們需求的方式重建它。
遷移到另一個(gè)第三方代理代碼庫。肯定有好的項(xiàng)目，比如 envoy 和其他一些。但這條道路意味著在幾年內(nèi)可能會(huì)重復(fù)同樣的循環(huán)。
從頭開始建立一個(gè)內(nèi)部平臺(tái)和框架。這一選擇需要在工程方面進(jìn)行最大的前期投資。
在過去的幾年中，我們每個(gè)季度都會(huì)對(duì)這些選項(xiàng)進(jìn)行評(píng)估。沒有明顯的公式來判斷哪種選擇是最好的。在幾年的時(shí)間里，我們繼續(xù)走阻力最小的道路，繼續(xù)增強(qiáng) NGINX。然而，在某些情況下，建立自有代理的投資回報(bào)率似乎更值得。我們呼吁從頭開始建立一個(gè)代理，并開始設(shè)計(jì)我們夢(mèng)想中的代理應(yīng)用程序。
Pingora 項(xiàng)目
設(shè)計(jì)決定
為了打造一個(gè)每秒提供數(shù)百萬次請(qǐng)求且快速、高效和安全的代理，我們必須首先做出一些重要的設(shè)計(jì)決定。
我們選擇 Rust 作為項(xiàng)目的語言，因?yàn)樗梢栽诓挥绊懶阅艿那闆r下以內(nèi)存安全的方式完成 C 語言可以做的事情。
盡管有一些很棒的現(xiàn)成第 3 方 HTTP 庫，例如 hyper，我們選擇構(gòu)建自己的庫是因?yàn)槲覀兿Ｍ畲笙薅鹊靥岣咛幚?HTTP 流量的靈活性，并確保我們可以按照自己的節(jié)奏進(jìn)行創(chuàng)新。
在 Cloudflare，我們處理整個(gè)互聯(lián)網(wǎng)的流量。我們必須支持許多奇怪且不符合 RFC 的 HTTP 流量案例。這是 HTTP 社區(qū)和 Web 中的一個(gè)常見困境，在嚴(yán)格遵循 HTTP 規(guī)范，和適應(yīng)潛在遺留客戶端或服務(wù)器的廣泛生態(tài)系統(tǒng)的細(xì)微差別之間存在矛盾和沖突，需要在其中作出艱難抉擇。
HTTP 狀態(tài)碼在 RFC 9110 中定義為一個(gè)三位整數(shù)，通常預(yù)期在 100 到 599 的范圍內(nèi)。Hyper 就是這樣一種實(shí)現(xiàn)。但是，許多服務(wù)器支持使用 599 到 999 之間的狀態(tài)代碼。我們?yōu)榇斯δ軇?chuàng)建了一個(gè)問題，探討了爭(zhēng)論的各個(gè)方面。雖然 hyper 團(tuán)隊(duì)最終確實(shí)接受了這一更改，但他們有充分的理由拒絕這樣的要求，而這只是我們需要支持的眾多不合規(guī)行為案例之一。
為了滿足 Cloudflare 在 HTTP 生態(tài)系統(tǒng)中的地位要求，我們需要一個(gè)穩(wěn)健、寬容、可定制的 HTTP 庫，該庫可以在互聯(lián)網(wǎng)的各種風(fēng)險(xiǎn)環(huán)境中生存，并支持各種不合規(guī)的用例。保證這一點(diǎn)的最佳方法就是實(shí)施我們自己的架構(gòu)。
下一個(gè)設(shè)計(jì)決策關(guān)于我們的工作負(fù)載調(diào)度系統(tǒng)。我們選擇多線程而不是多處理，以便輕松共享資源，尤其是連接池。我們認(rèn)為還需要實(shí)施工作竊取來避免上面提到的某些類別的性能問題。Tokio 異步運(yùn)行時(shí)結(jié)果非常適合我們的需求。
最后，我們希望我們的項(xiàng)目直觀且對(duì)開發(fā)人員友好。我們構(gòu)建的不是最終產(chǎn)品，而是應(yīng)該可以作為一個(gè)平臺(tái)進(jìn)行擴(kuò)展，因?yàn)樵谒蠘?gòu)建了更多的功能。
我們決定實(shí)施一個(gè)類似于 NGINX/OpenResty 的基于“請(qǐng)求生命周期”事件的可編程接口。例如，“請(qǐng)求過濾器”階段允許開發(fā)人員在收到請(qǐng)求標(biāo)頭時(shí)運(yùn)行代碼來修改或拒絕請(qǐng)求。通過這種設(shè)計(jì)，我們可以清晰地分離我們的業(yè)務(wù)邏輯和通用代理邏輯。之前從事 NGINX 工作的開發(fā)人員可以輕松切換到 Pingora 并迅速提高工作效率。
Pingora 在生產(chǎn)中更快
讓我們快進(jìn)到現(xiàn)在。Pingora 處理幾乎所有需要與源服務(wù)器交互的 HTTP 請(qǐng)求（例如緩存未命中），我們?cè)诖诉^程中收集了很多性能數(shù)據(jù)。
首先，讓我們看看 Pingora 如何加快我們客戶的流量。Pingora 上的總體流量顯示，TTFB 中位數(shù)減少了 5 毫秒，第 95 個(gè)百分位數(shù)減少了 80 毫秒。這不是因?yàn)槲覀冞\(yùn)行代碼更快。甚至我們的舊服務(wù)也可以處理亞毫秒范圍內(nèi)的請(qǐng)求。
時(shí)間節(jié)省來自我們的新架構(gòu)，它可以跨所有線程共享連接。這意味著更好的連接重用率，在 TCP 和 TLS 握手上花費(fèi)的時(shí)間更少。
在所有客戶中，與舊服務(wù)相比，Pingora 每秒的新連接數(shù)只有三分之一。對(duì)于一個(gè)主要客戶，它將連接重用率從 87.1% 提高到 99.92%，這將新連接減少了 160 倍。更直觀地說，通過切換到 Pingora，我們每天為客戶和用戶節(jié)省了 434 年的握手時(shí)間。ChatGPT中文網(wǎng)站：https://AI.cxyquan.com/
更多功能 擁有工程師熟悉的開發(fā)人員友好界面，同時(shí)消除以前的限制，讓我們能夠更快地開發(fā)更多功能。像新協(xié)議這樣的核心功能充當(dāng)我們?yōu)榭蛻籼峁└喈a(chǎn)品的基石。
例如，我們能夠在沒有重大障礙的情況下向 Pingora 添加 HTTP/2 上游支持。這使我們能夠在不久之后向我們的客戶提供 gRPC。將相同的功能添加到 NGINX 將需要更多的工程工作，并且可能無法實(shí)現(xiàn)。
最近，我們宣布推出了 Cache Reserve，其中 Pingora 使用 R2 存儲(chǔ)作為緩存層。隨著我們向 Pingora 添加更多功能，我們能夠提供以前不可行的新產(chǎn)品。
更高效
在生產(chǎn)環(huán)境中，與我們的舊服務(wù)相比，Pingora 在相同流量負(fù)載的情況下，消耗的 CPU 和內(nèi)存減少了約 70% 和 67%。節(jié)省來自幾個(gè)因素。
與舊的 Lua 代碼相比，我們的 Rust 代碼運(yùn)行效率更高。最重要的是，它們的架構(gòu)也存在效率差異。例如，在 NGINX/OpenResty 中，當(dāng) Lua 代碼想要訪問 HTTP 頭時(shí)，它必須從 NGINX C 結(jié)構(gòu)中讀取它，分配一個(gè) Lua 字符串，然后將其復(fù)制到 Lua 字符串中。之后，Lua 還對(duì)其新字符串進(jìn)行垃圾回收。在 Pingora 中，它只是一個(gè)直接的字符串訪問。
多線程模型還使得跨請(qǐng)求共享數(shù)據(jù)更加高效。NGINX 也有共享內(nèi)存，但由于實(shí)施限制，每次共享內(nèi)存訪問都必須使用互斥鎖，并且只能將字符串和數(shù)字放入共享內(nèi)存。在 Pingora 中，大多數(shù)共享項(xiàng)目可以通過原子引用計(jì)數(shù)器后面的共享引用直接訪問。
如上所述，CPU 節(jié)省的另一個(gè)重要部分是減少了新的連接。與僅通過已建立的連接發(fā)送和接收數(shù)據(jù)相比，TLS 握手成本顯然更為高昂。
更安全
在我們這樣的規(guī)模下，快速安全地發(fā)布功能十分困難。很難預(yù)測(cè)在每秒處理數(shù)百萬個(gè)請(qǐng)求的分布式環(huán)境中可能發(fā)生的每個(gè)邊緣情況。模糊測(cè)試和靜態(tài)分析只能緩解這么多。Rust 的內(nèi)存安全語義保護(hù)我們免受未定義行為的影響，并讓我們相信我們的服務(wù)將正確運(yùn)行。
有了這些保證，我們可以更多地關(guān)注我們的服務(wù)更改將如何與其他服務(wù)或客戶來源進(jìn)行交互。我們能夠以更高的節(jié)奏開發(fā)功能，而不用背負(fù)內(nèi)存安全和難以診斷崩潰的問題。
當(dāng)崩潰確實(shí)發(fā)生時(shí)，工程師需要花時(shí)間來診斷它是如何發(fā)生的以及是什么原因造成的。自 Pingora 創(chuàng)立以來，我們已經(jīng)處理了數(shù)百萬億個(gè)請(qǐng)求，至今尚未因?yàn)槲覀兊姆?wù)代碼而崩潰。
事實(shí)上，Pingora 崩潰是如此罕見，當(dāng)我們遇到一個(gè)問題時(shí)，我們通常會(huì)發(fā)現(xiàn)不相關(guān)的問題。最近，我們的服務(wù)開始崩潰后不久，我們發(fā)現(xiàn)了一個(gè)內(nèi)核錯(cuò)誤。我們還在一些機(jī)器上發(fā)現(xiàn)了硬件問題，過去排除了由我們的軟件引起的罕見內(nèi)存錯(cuò)誤，即使在幾乎不可能進(jìn)行重大調(diào)試之后也是如此。
總結(jié)
總而言之，我們已經(jīng)建立了一個(gè)更快、更高效、更通用的內(nèi)部代理，作為我們當(dāng)前和未來產(chǎn)品的平臺(tái)。
我們之后將介紹有關(guān)我們面臨的問題和應(yīng)用優(yōu)化的更多技術(shù)細(xì)節(jié)，以及我們從構(gòu)建 Pingora 并將其推出以支持互聯(lián)網(wǎng)的重要部分的經(jīng)驗(yàn)教訓(xùn)。同時(shí)還將介紹我們的開源計(jì)劃。
