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。
