撰稿丨千山

近日來，網站安全和託管服務供應商Cloudflare可以說春風得意。

根據網絡諮詢服務公司Netcraft的調查報告，今年1月在前100萬個最繁忙的網站中，Cloudflare以21.64%的市場份額，一舉越過Apache(21.40%)和Nginx(21.20%)，從第3位躍升至首位，成為最受歡迎的Web伺服器。

之後，在國際權威研究機構GigaOm發布的全球CDN服務雷達報告中， Cloudflare又在15個供應商的解決方案中脫穎而出，被評為「領導者」和「表現卓越者」。

圖源：GigaOm官網。（註：如圖所示，GigaOm 雷達報告在一系列同心圓上評估，越靠近中心的解決方案整體價值越高。）

成立於2009年的Cloudflare以向用戶提供網站安全管理、性能優化及相關的技術支持為主要業務。在技術上，這家公司很長一段時間都將Nginx視為核心，用於其提供的所有Web服務中，但這一狀況在去年發生了變化。

2022年9月，Cloudflare宣布用自研的以Rust編寫的Pingora取代了Nginx，旨在構建一個更快、更高效、更安全的全新HTTP代理。這一決策在當時也引起了一些猜測，不過從目前來看，彼時果斷地改弦易轍正逐步展露成效。

1、為什麼要捨棄Nginx？

Cloudflare之所以會放棄Nginx，簡單來說，就是Nginx已經無法滿Cloudflare日益增長的業務需求。

對此，Cloudflare的官方技術博客曾專門發文進行了解釋，將Nginx的種種局限性主要歸因為三點：

其一，架構限制影響性能。Nginx的worker（進程）架構對於Cloudflare的用例而言存在操作缺陷，導致損害性能和效率。

其二，某些功能類型難以添加。圍繞Nginx構建所需功能時要儘量避免與Nginx上游代碼庫有太多分歧，這無疑會增加難度。而且Nginx是純用C語言編寫的，在設計上不能保障內存安全性。使用這樣的第三方代碼庫非常容易出錯。用來補充C語言的另一種程式語言Lua雖然風險較小，但性能也較差。

其三，社區活躍度不高。Nginx社區本身不是很活躍，開發往往是「閉門造車」。

當然，上述局限性中更致命的還是第一點。就像Cloudflare工程師在文中一針見血地指出：「對於我們的用例來說，最關鍵的問題是糟糕的連接重用。」

截圖：https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/

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

代理層節點機器與源伺服器建立TCP連接，以代理HTTP請求。連接重用通過重用之前從連接池建立的連接，跳過新連接所需的TCP和TLS握手，來加快請求的TTFB（首字節時間）。

但是，Nginx連接池是按worker劃分的。當請求到達某個worker時，它只能重用該worker內的連接。當我們添加更多Nginx worker以進行擴展時，連接重用率會變得更差，因為連接分散在所有進程的更多隔離池中，不僅會導致響應時間變慢，也會消耗額外的硬體資源。

圖源：Cloudflare官方技術博客

針對這一問題，Cloudflare技術團隊雖然嘗試過種種優化方案，但最終發現只要Nginx Work（進程）架構不變，還是治標不治本。

2、身處三岔口的抉擇

放棄Nginx，選擇自研，也並非一蹴而就。Cloudflare經歷了幾年的持續評估，當時，他們主要面臨三種選擇。

其一，繼續投資Nginx，並使用Fork版本來讓其完全適配業務需求。儘管Cloudflare團隊的專業儲備過硬，但鑑於上述架構限制，必然要付出大量時間和努力才能實現重建。

其二，遷移到另一個第三方代理代碼庫。考慮使用別的好項目，比如envoy 。但這條道路意味著在幾年內可能會重複同樣的循環——不斷探索試錯，才能逐步磨合。

其三，從頭開始，建立一個內部平台和框架。這一選擇需要在開發方面進行大量的前期投資。但優點是能從起點就百分之百圍繞Cloudflare的用例服務。

站在三叉路口，沒有人能篤定那條道路就一定是光明坦途。正如Cloudflare的技術人員在回顧這段時間時談到的：「在幾年的時間裡，我們繼續走阻力最小的道路，繼續增強Nginx。然而，在某些情況下，建立自有代理的投資回報率似乎更值得。我們呼籲從頭開始建立一個代理，並開始設計我們夢想中的代理應用程式。」

如今，結果我們也看到了。他們堅定地邁向了第三條路——構建全新的代理架構，這就是用Rust編寫的Pingora。

從零開始造輪子並非易事，但Pingora的表現卻並不讓人失望。據介紹，Pingora每天處理超過1萬億條請求，提高系統性能之餘，也為Cloudflare客戶帶來不少新功能。更重要的是，它運行所占用的CPU和內存資源只相當於原有代理基礎設施的三分之一。

3、用Rust重寫Nginx模塊

自去年9月的發布以來，Cloudflare團隊在「去Nginx化」的道路上一直在低調前行。日前，Cloudflare在其官博上介紹了如何使用Rust重寫Nginx模塊。

「我們的工程師們用Rust為Cloudflare基礎設施中最古老和最不為人所知的部分 ——cf-html，編寫了替代品，通過完成這項工作為我們完全擺脫Nginx鋪平了道路」

cf-html是一個Nginx模塊，位於Cloudflare的核心反向Web代理內部，亦稱為FL (Front Line)。FL運行著Cloudflare應用程式服務的大部分邏輯，因此這次替換如果能順利完成，無疑會更具標誌性。

圖源：推特@Cloudflare

Cloudflare方面表示，未來他們會繼續逐步更換用於運行Nginx/OpenResty代理的組件，或者無需對自研平台投入大量開發資源就可以完成的組件，從而構建一個沒有Nginx的未來 。

最後Cloudflare還提到了Rust帶來的優勢：「很難想像如果沒有像Rust這樣的語言，我們會處於怎樣的境地，因為Rust在提供速度的同時又提供了高度的安全性，還有像Bindgen和Serde這樣的高質量庫。」

「更寬泛地說，FL團隊正在努力將平台的其他方面遷移到Rust中，雖然cf-html和圍繞其構建的功能是我們基礎架構中需要改進的關鍵部分，但還有許多其他方面需要改進。」

「多數人認為程式語言的安全性主要是用於預防錯誤，但對於一家公司來說，我們發現程式語言的安全優勢還可以用來完成一些被認為非常困難、或不可能安全實現的功能需求。」

4、結語：「去Nginx化」成趨勢了嗎

就Cloudflare這個案例來說，Pingora比Nginx的表現更高效更安全，並不意味著Rust比C語言好，也並不表示Pingora在任何場景下都優於Nginx，而是Pingora更適合Cloudflare的用例。

CDN的規模導致了其對微小抖動的敏感性，同時底層基礎設施的技術改進也是Cloudflare這樣的公司點燃其革新火種的助力之一。Cloudflare選擇了對他們的業務模型表現更佳的解決方案。

但是我們注意到，近年來一些大廠在「去 Nginx」上動作頻頻。比如：

（1）Dropbox從Nginx遷移到了Envoy；

（2）百度開源採用GO語言的BFE；

（3）阿里巴巴雲原生網關Higress基於Envoy，支持Nginx Ingress零成本快速遷移 。

不可否認，Nginx在反向代理、負載均衡方面表現出色，但「C+Lua」的組合也的確很難在性能和安全上實現兩全。作為時代的產物，Nginx或許不能被輕易進行比較，但「去Nginx化」似乎正在成為一種趨勢。

參考連結：

https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/

https://news.netcraft.com/archives/2023/01/27/january-2023-web-server-survey.html

https://twitter.com/Cloudflare/status/1629119206770847744?s=05

來源： 51CTO技術棧