?撰稿丨千山
近日來，網(wǎng)站安全和托管服務供應商Cloudflare可以說春風得意。
根據(jù)網(wǎng)絡咨詢服務公司Netcraft的調查報告，今年1月在前100萬個最繁忙的網(wǎng)站中，Cloudflare以21.64%的市場份額，一舉越過Apache(21.40%)和Nginx(21.20%)，從第3位躍升至首位，成為最受歡迎的Web服務器。
之后，在國際權威研究機構GigaOm發(fā)布的全球CDN服務雷達報告中， Cloudflare又在15個供應商的解決方案中脫穎而出，被評為“領導者”和“表現(xiàn)卓越者”。
圖源：GigaOm官網(wǎng)。（注：如圖所示，GigaOm 雷達報告在一系列同心圓上評估，越靠近中心的解決方案整體價值越高。）
成立于2009年的Cloudflare以向用戶提供網(wǎng)站安全管理、性能優(yōu)化及相關的技術支持為主要業(yè)務。在技術上，這家公司很長一段時間都將Nginx視為核心，用于其提供的所有Web服務中，但這一狀況在去年發(fā)生了變化。
2022年9月，Cloudflare宣布用自研的以Rust編寫的Pingora取代了Nginx，旨在構建一個更快、更高效、更安全的全新HTTP代理。這一決策在當時也引起了一些猜測，不過從目前來看，彼時果斷地改弦易轍正逐步展露成效。
1、為什么要舍棄Nginx？
Cloudflare之所以會放棄Nginx，簡單來說，就是Nginx已經(jīng)無法滿Cloudflare日益增長的業(yè)務需求。
對此，Cloudflare的官方技術博客曾專門發(fā)文進行了解釋，將Nginx的種種局限性主要歸因為三點：
其一，架構限制影響性能。Nginx的worker（進程）架構對于Cloudflare的用例而言存在操作缺陷，導致?lián)p害性能和效率。
其二，某些功能類型難以添加。圍繞Nginx構建所需功能時要盡量避免與Nginx上游代碼庫有太多分歧，這無疑會增加難度。而且Nginx是純用C語言編寫的，在設計上不能保障內存安全性。使用這樣的第三方代碼庫非常容易出錯。用來補充C語言的另一種編程語言Lua雖然風險較小，但性能也較差。
其三，社區(qū)活躍度不高。Nginx社區(qū)本身不是很活躍，開發(fā)往往是“閉門造車”。
當然，上述局限性中更致命的還是第一點。就像Cloudflare工程師在文中一針見血地指出：“對于我們的用例來說，最關鍵的問題是糟糕的連接重用。”
截圖：https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/
簡單來說，在Nginx中每個請求只能由單個worker處理。這會導致所有CPU內核的負載不平衡，從而導致處理速度變慢。
代理層節(jié)點機器與源服務器建立TCP連接，以代理HTTP請求。連接重用通過重用之前從連接池建立的連接，跳過新連接所需的TCP和TLS握手，來加快請求的TTFB（首字節(jié)時間）。
但是，Nginx連接池是按worker劃分的。當請求到達某個worker時，它只能重用該worker內的連接。當我們添加更多Nginx worker以進行擴展時，連接重用率會變得更差，因為連接分散在所有進程的更多隔離池中，不僅會導致響應時間變慢，也會消耗額外的硬件資源。
圖源：Cloudflare官方技術博客
針對這一問題，Cloudflare技術團隊雖然嘗試過種種優(yōu)化方案，但最終發(fā)現(xiàn)只要Nginx Work（進程）架構不變，還是治標不治本。
2、身處三岔口的抉擇
放棄Nginx，選擇自研，也并非一蹴而就。Cloudflare經(jīng)歷了幾年的持續(xù)評估，當時，他們主要面臨三種選擇。
其一，繼續(xù)投資Nginx，并使用Fork版本來讓其完全適配業(yè)務需求。盡管Cloudflare團隊的專業(yè)儲備過硬，但鑒于上述架構限制，必然要付出大量時間和努力才能實現(xiàn)重建。
其二，遷移到另一個第三方代理代碼庫?？紤]使用別的好項目，比如envoy 。但這條道路意味著在幾年內可能會重復同樣的循環(huán)——不斷探索試錯，才能逐步磨合。
其三，從頭開始，建立一個內部平臺和框架。這一選擇需要在開發(fā)方面進行大量的前期投資。但優(yōu)點是能從起點就百分之百圍繞Cloudflare的用例服務。
站在三叉路口，沒有人能篤定那條道路就一定是光明坦途。正如Cloudflare的技術人員在回顧這段時間時談到的：“在幾年的時間里，我們繼續(xù)走阻力最小的道路，繼續(xù)增強Nginx。然而，在某些情況下，建立自有代理的投資回報率似乎更值得。我們呼吁從頭開始建立一個代理，并開始設計我們夢想中的代理應用程序?！?/p>
如今，結果我們也看到了。他們堅定地邁向了第三條路——構建全新的代理架構，這就是用Rust編寫的Pingora。
從零開始造輪子并非易事，但Pingora的表現(xiàn)卻并不讓人失望。據(jù)介紹，Pingora每天處理超過1萬億條請求，提高系統(tǒng)性能之余，也為Cloudflare客戶帶來不少新功能。更重要的是，它運行所占用的CPU和內存資源只相當于原有代理基礎設施的三分之一。
3、用Rust重寫Nginx模塊
自去年9月的發(fā)布以來，Cloudflare團隊在“去Nginx化”的道路上一直在低調前行。日前，Cloudflare在其官博上介紹了如何使用Rust重寫Nginx模塊。
“我們的工程師們用Rust為Cloudflare基礎設施中最古老和最不為人所知的部分 ——cf-html，編寫了替代品，通過完成這項工作為我們完全擺脫Nginx鋪平了道路”
cf-html是一個Nginx模塊，位于Cloudflare的核心反向Web代理內部，亦稱為FL (Front Line)。FL運行著Cloudflare應用程序服務的大部分邏輯，因此這次替換如果能順利完成，無疑會更具標志性。
圖源：推特@Cloudflare
Cloudflare方面表示，未來他們會繼續(xù)逐步更換用于運行Nginx/OpenResty代理的組件，或者無需對自研平臺投入大量開發(fā)資源就可以完成的組件，從而構建一個沒有Nginx的未來 。
最后Cloudflare還提到了Rust帶來的優(yōu)勢：“很難想象如果沒有像Rust這樣的語言，我們會處于怎樣的境地，因為Rust在提供速度的同時又提供了高度的安全性，還有像Bindgen和Serde這樣的高質量庫。”
“更寬泛地說，F(xiàn)L團隊正在努力將平臺的其他方面遷移到Rust中，雖然cf-html和圍繞其構建的功能是我們基礎架構中需要改進的關鍵部分，但還有許多其他方面需要改進。”
“多數(shù)人認為編程語言的安全性主要是用于預防錯誤，但對于一家公司來說，我們發(fā)現(xiàn)編程語言的安全優(yōu)勢還可以用來完成一些被認為非常困難、或不可能安全實現(xiàn)的功能需求?！?/p>
4、結語：“去Nginx化”成趨勢了嗎
就Cloudflare這個案例來說，Pingora比Nginx的表現(xiàn)更高效更安全，并不意味著Rust比C語言好，也并不表示Pingora在任何場景下都優(yōu)于Nginx，而是Pingora更適合Cloudflare的用例。
CDN的規(guī)模導致了其對微小抖動的敏感性，同時底層基礎設施的技術改進也是Cloudflare這樣的公司點燃其革新火種的助力之一。Cloudflare選擇了對他們的業(yè)務模型表現(xiàn)更佳的解決方案。
但是我們注意到，近年來一些大廠在“去 Nginx”上動作頻頻。比如：
（1）Dropbox從Nginx遷移到了Envoy；
（2）百度開源采用GO語言的BFE；
（3）阿里巴巴云原生網(wǎng)關Higress基于Envoy，支持Nginx Ingress零成本快速遷移 。
不可否認，Nginx在反向代理、負載均衡方面表現(xiàn)出色，但“C+Lua”的組合也的確很難在性能和安全上實現(xiàn)兩全。作為時代的產(chǎn)物，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
