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