一文看懂 Pingora 比 Nginx 強在哪

Cloudflare 公司去年宣佈棄用 nginx，轉用自研的新一代方向代理服務 Pingora，並號稱比 nginx 更快、更高效、更安全，下面通過 Cloudfare 官方網站的一篇文章來了解下 Pingora 比 Nginx 強在哪裏。

簡介

今天，我們很高興有機會在此介紹 Pingora，這是我們使用 Rust 在內部構建的新 HTTP 代理，它每天處理超過 1 萬億個請求，提高了我們的性能，併爲 Cloudflare 客戶帶來了許多新功能，同時只需要我們以前代理基礎架構的三分之一的 CPU 和內存資源。

隨着 Cloudflare 規模的擴大，我們已經超越了 NGINX 的處理能力。多年來它一直運作良好，但隨着時間的推移，它在我們規模上的侷限性意味着我們有必要構建一些新的東西。我們無法再獲得我們所需要的性能，NGINX 也沒有我們在非常複雜的環境中所需要的功能。

許多 Cloudflare 客戶和用戶使用 Cloudflare 全球網絡作爲 HTTP 客戶端（例如 Web 瀏覽器、應用程序、物聯網設備等）和服務器之間的代理。過去，對於瀏覽器和其他用戶代理如何連接到我們的網絡，我們已進行過許多討論，我們開發了很多技術並實施了新協議（參見 QUIC 和 http2 優化）來使這段連接更高效。

今天，我們將關注這個等式的另一部分：代理我們的網絡和互聯網上服務器之間的流量的服務。這個代理服務爲我們的 CDN、Workers fetch、Tunnel、Stream、R2 以及許多其他功能和產品提供了動力。

讓我們研究爲什麼我們選擇取代我們的舊版服務以及 Pingora 的開發過程，這是我們專門爲 Cloudflare 的客戶用例和規模而設計的新系統。

爲什麼要再建一個代理

這些年來，我們對 NGINX 的使用遇到了限制。對於部分限制，我們進行了優化或選擇繞過它們。但另一些限制則更難克服。

架構的限制損害了性能

NGINX worker（進程）架構對於我們的用例而言存在操作缺陷，這會損害我們的性能和效率。

首先，在 NGINX 中，每個請求只能由單個 worker 處理。這會導致所有 CPU 內核之間的負載不平衡，從而導致速度變慢。

由於這種請求進程鎖定效應，執行 CPU 繁重或阻止 IO 任務的請求可能會減慢其他請求的速度。正如這些博客文章所表明的那樣，我們已經花了很多時間來解決這些問題。

對於我們的用例來說，最關鍵的問題是糟糕的連接重用。我們的機器與原始服務器建立 TCP 連接，以代理 HTTP 請求。連接重用通過重用之前從連接池建立的連接，跳過新連接所需的 TCP 和 TLS 握手，來加快請求的 TTFB（首字節時間）。

但是，NGINX 連接池與單個 worker 相對應。當請求到達某個 worker 時，它只能重用該 worker 內的連接。當我們添加更多 NGINX worker 以進行擴展時，我們的連接重用率會變得更差，因爲連接分散在所有進程的更多孤立的池中。這導致更慢的 TTFB 以及需要維護更多連接，進而消耗我們和客戶的資源（和金錢）。

正如在過去的博客文章中所提到的，我們爲其中一些問題提供瞭解決方法。但如果我們能夠解決根本問題：worker / 進程模型，我們將自然而然地解決所有這些問題。

有些類型的功能難以添加

NGINX 是一個非常好的 Web 服務器、負載均衡器或簡單的網關。但 Cloudflare 的作用遠不止於此。我們過去常常圍繞 NGINX 構建我們需要的所有功能，但要儘量避免與 NGINX 上游代碼庫有太多分歧，這並不容易。

例如，當重試請求 / 請求失敗時，有時我們希望將請求發送到具有不同請求標頭集的不同源服務器。但 NGINX 並不允許執行此操作。在這種情況下，我們需要花費時間和精力來解決 NGINX 的限制。

同時，我們被迫使用的編程語言並沒有幫助緩解這些困難。NGINX 純粹是用 C 語言編寫的，這在設計上不是內存安全的。使用這樣的第 3 方代碼庫非常容易出錯。即使對於經驗豐富的工程師來說，也很容易陷入內存安全問題，我們希望儘可能避免這些問題。

我們用來補充 C 語言的另一種語言是 Lua。它的風險較小，但性能也較差。此外，在處理複雜的 Lua 代碼和業務邏輯時，我們經常發現自己缺少靜態類型。

而且 NGINX 社區也不是很活躍，開發往往是 “閉門造車”。

選擇建立我們自己的

在過去的幾年裏，隨着我們的客戶羣和功能集的持續增長，我們持續評估了三種選擇：

1. 繼續投資 NGINX，向其付款進行定製，使其 100% 滿足我們的需求。我們擁有所需的專業知識，但鑑於上述架構限制，需要付出大量努力才能以完全支持我們需求的方式重建它。

2. 遷移到另一個第三方代理代碼庫。肯定有好的項目，比如 envoy 和其他一些。但這條道路意味着在幾年內可能會重複同樣的循環。

3. 從頭開始建立一個內部平臺和框架。這一選擇需要在工程方面進行最大的前期投資。

在過去的幾年中，我們每個季度都會對這些選項進行評估。沒有明顯的公式來判斷哪種選擇是最好的。在幾年的時間裏，我們繼續走阻力最小的道路，繼續增強 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 崩潰是如此罕見，當我們遇到一個問題時，我們通常會發現不相關的問題。最近，我們的服務開始崩潰後不久，我們發現了一個內核錯誤。我們還在一些機器上發現了硬件問題，過去排除了由我們的軟件引起的罕見內存錯誤，即使在幾乎不可能進行重大調試之後也是如此。

總結

總而言之，我們已經建立了一個更快、更高效、更通用的內部代理，作爲我們當前和未來產品的平臺。

我們之後將介紹有關我們面臨的問題和應用優化的更多技術細節，以及我們從構建 Pingora 並將其推出以支持互聯網的重要部分的經驗教訓。同時還將介紹我們的開源計劃。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/oNpcRGkgdf7JGkIo4m-kDw