?撰稿丨千山

近日來(lái)，網(wǎng)站安全和托管服務(wù)供應(yīng)商Cloudflare可以說(shuō)春風(fēng)得意。

根據(jù)網(wǎng)絡(luò)咨詢(xún)服務(wù)公司Netcraft的調(diào)查報(bào)告，今年1月在前100萬(wàn)個(gè)最繁忙的網(wǎng)站中，Cloudflare以21.64%的市場(chǎng)份額，一舉越過(guò)Apache(21.40%)和Nginx(21.20%)，從第3位躍升至首位，成為最受歡迎的Web服務(wù)器。

之后，在國(guó)際權(quán)威研究機(jī)構(gòu)GigaOm發(fā)布的全球CDN服務(wù)雷達(dá)報(bào)告中， Cloudflare又在15個(gè)供應(yīng)商的解決方案中脫穎而出，被評(píng)為“領(lǐng)導(dǎo)者”和“表現(xiàn)卓越者”。

圖源：GigaOm官網(wǎng)。（注：如圖所示，GigaOm 雷達(dá)報(bào)告在一系列同心圓上評(píng)估，越靠近中心的解決方案整體價(jià)值越高。）

成立于2009年的Cloudflare以向用戶提供網(wǎng)站安全管理、性能優(yōu)化及相關(guān)的技術(shù)支持為主要業(yè)務(wù)。在技術(shù)上，這家公司很長(zhǎng)一段時(shí)間都將Nginx視為核心，用于其提供的所有Web服務(wù)中，但這一狀況在去年發(fā)生了變化。

2022年9月，Cloudflare宣布用自研的以Rust編寫(xiě)的Pingora取代了Nginx，旨在構(gòu)建一個(gè)更快、更高效、更安全的全新HTTP代理。這一決策在當(dāng)時(shí)也引起了一些猜測(cè)，不過(guò)從目前來(lái)看，彼時(shí)果斷地改弦易轍正逐步展露成效。

1、為什么要舍棄Nginx？

Cloudflare之所以會(huì)放棄Nginx，簡(jiǎn)單來(lái)說(shuō)，就是Nginx已經(jīng)無(wú)法滿Cloudflare日益增長(zhǎng)的業(yè)務(wù)需求。

對(duì)此，Cloudflare的官方技術(shù)博客曾專(zhuān)門(mén)發(fā)文進(jìn)行了解釋?zhuān)瑢ginx的種種局限性主要?dú)w因?yàn)槿c(diǎn)：

其一，架構(gòu)限制影響性能。Nginx的worker（進(jìn)程）架構(gòu)對(duì)于Cloudflare的用例而言存在操作缺陷，導(dǎo)致?lián)p害性能和效率。

其二，某些功能類(lèi)型難以添加。圍繞Nginx構(gòu)建所需功能時(shí)要盡量避免與Nginx上游代碼庫(kù)有太多分歧，這無(wú)疑會(huì)增加難度。而且Nginx是純用C語(yǔ)言編寫(xiě)的，在設(shè)計(jì)上不能保障內(nèi)存安全性。使用這樣的第三方代碼庫(kù)非常容易出錯(cuò)。用來(lái)補(bǔ)充C語(yǔ)言的另一種編程語(yǔ)言Lua雖然風(fēng)險(xiǎn)較小，但性能也較差。

其三，社區(qū)活躍度不高。Nginx社區(qū)本身不是很活躍，開(kāi)發(fā)往往是“閉門(mén)造車(chē)”。

當(dāng)然，上述局限性中更致命的還是第一點(diǎn)。就像Cloudflare工程師在文中一針見(jiàn)血地指出：“對(duì)于我們的用例來(lái)說(shuō)，最關(guān)鍵的問(wèn)題是糟糕的連接重用?！?/p>

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

簡(jiǎn)單來(lái)說(shuō)，在Nginx中每個(gè)請(qǐng)求只能由單個(gè)worker處理。這會(huì)導(dǎo)致所有CPU內(nèi)核的負(fù)載不平衡，從而導(dǎo)致處理速度變慢。

代理層節(jié)點(diǎn)機(jī)器與源服務(wù)器建立TCP連接，以代理HTTP請(qǐng)求。連接重用通過(guò)重用之前從連接池建立的連接，跳過(guò)新連接所需的TCP和TLS握手，來(lái)加快請(qǐng)求的TTFB（首字節(jié)時(shí)間）。

但是，Nginx連接池是按worker劃分的。當(dāng)請(qǐng)求到達(dá)某個(gè)worker時(shí)，它只能重用該worker內(nèi)的連接。當(dāng)我們添加更多Nginx worker以進(jìn)行擴(kuò)展時(shí)，連接重用率會(huì)變得更差，因?yàn)檫B接分散在所有進(jìn)程的更多隔離池中，不僅會(huì)導(dǎo)致響應(yīng)時(shí)間變慢，也會(huì)消耗額外的硬件資源。

圖源：Cloudflare官方技術(shù)博客

針對(duì)這一問(wèn)題，Cloudflare技術(shù)團(tuán)隊(duì)雖然嘗試過(guò)種種優(yōu)化方案，但最終發(fā)現(xiàn)只要Nginx Work（進(jìn)程）架構(gòu)不變，還是治標(biāo)不治本。

2、身處三岔口的抉擇

放棄Nginx，選擇自研，也并非一蹴而就。Cloudflare經(jīng)歷了幾年的持續(xù)評(píng)估，當(dāng)時(shí)，他們主要面臨三種選擇。

其一，繼續(xù)投資Nginx，并使用Fork版本來(lái)讓其完全適配業(yè)務(wù)需求。盡管Cloudflare團(tuán)隊(duì)的專(zhuān)業(yè)儲(chǔ)備過(guò)硬，但鑒于上述架構(gòu)限制，必然要付出大量時(shí)間和努力才能實(shí)現(xiàn)重建。

其二，遷移到另一個(gè)第三方代理代碼庫(kù)?？紤]使用別的好項(xiàng)目，比如envoy 。但這條道路意味著在幾年內(nèi)可能會(huì)重復(fù)同樣的循環(huán)——不斷探索試錯(cuò)，才能逐步磨合。

其三，從頭開(kāi)始，建立一個(gè)內(nèi)部平臺(tái)和框架。這一選擇需要在開(kāi)發(fā)方面進(jìn)行大量的前期投資。但優(yōu)點(diǎn)是能從起點(diǎn)就百分之百?lài)@Cloudflare的用例服務(wù)。

站在三叉路口，沒(méi)有人能篤定那條道路就一定是光明坦途。正如Cloudflare的技術(shù)人員在回顧這段時(shí)間時(shí)談到的：“在幾年的時(shí)間里，我們繼續(xù)走阻力最小的道路，繼續(xù)增強(qiáng)Nginx。然而，在某些情況下，建立自有代理的投資回報(bào)率似乎更值得。我們呼吁從頭開(kāi)始建立一個(gè)代理，并開(kāi)始設(shè)計(jì)我們夢(mèng)想中的代理應(yīng)用程序。”

如今，結(jié)果我們也看到了。他們堅(jiān)定地邁向了第三條路——構(gòu)建全新的代理架構(gòu)，這就是用Rust編寫(xiě)的Pingora。

從零開(kāi)始造輪子并非易事，但Pingora的表現(xiàn)卻并不讓人失望。據(jù)介紹，Pingora每天處理超過(guò)1萬(wàn)億條請(qǐng)求，提高系統(tǒng)性能之余，也為Cloudflare客戶帶來(lái)不少新功能。更重要的是，它運(yùn)行所占用的CPU和內(nèi)存資源只相當(dāng)于原有代理基礎(chǔ)設(shè)施的三分之一。

3、用Rust重寫(xiě)Nginx模塊

自去年9月的發(fā)布以來(lái)，Cloudflare團(tuán)隊(duì)在“去Nginx化”的道路上一直在低調(diào)前行。日前，Cloudflare在其官博上介紹了如何使用Rust重寫(xiě)Nginx模塊。

“我們的工程師們用Rust為Cloudflare基礎(chǔ)設(shè)施中最古老和最不為人所知的部分 ——cf-html，編寫(xiě)了替代品，通過(guò)完成這項(xiàng)工作為我們完全擺脫Nginx鋪平了道路”

cf-html是一個(gè)Nginx模塊，位于Cloudflare的核心反向Web代理內(nèi)部，亦稱(chēng)為FL (Front Line)。FL運(yùn)行著Cloudflare應(yīng)用程序服務(wù)的大部分邏輯，因此這次替換如果能順利完成，無(wú)疑會(huì)更具標(biāo)志性。

圖源：推特@Cloudflare

Cloudflare方面表示，未來(lái)他們會(huì)繼續(xù)逐步更換用于運(yùn)行Nginx/OpenResty代理的組件，或者無(wú)需對(duì)自研平臺(tái)投入大量開(kāi)發(fā)資源就可以完成的組件，從而構(gòu)建一個(gè)沒(méi)有Nginx的未來(lái) 。

最后Cloudflare還提到了Rust帶來(lái)的優(yōu)勢(shì)：“很難想象如果沒(méi)有像Rust這樣的語(yǔ)言，我們會(huì)處于怎樣的境地，因?yàn)镽ust在提供速度的同時(shí)又提供了高度的安全性，還有像Bindgen和Serde這樣的高質(zhì)量庫(kù)?！?/p>

“更寬泛地說(shuō)，F(xiàn)L團(tuán)隊(duì)正在努力將平臺(tái)的其他方面遷移到Rust中，雖然cf-html和圍繞其構(gòu)建的功能是我們基礎(chǔ)架構(gòu)中需要改進(jìn)的關(guān)鍵部分，但還有許多其他方面需要改進(jìn)?！?/p>

“多數(shù)人認(rèn)為編程語(yǔ)言的安全性主要是用于預(yù)防錯(cuò)誤，但對(duì)于一家公司來(lái)說(shuō)，我們發(fā)現(xiàn)編程語(yǔ)言的安全優(yōu)勢(shì)還可以用來(lái)完成一些被認(rèn)為非常困難、或不可能安全實(shí)現(xiàn)的功能需求?！?/p>

4、結(jié)語(yǔ)：“去Nginx化”成趨勢(shì)了嗎

就Cloudflare這個(gè)案例來(lái)說(shuō)，Pingora比Nginx的表現(xiàn)更高效更安全，并不意味著Rust比C語(yǔ)言好，也并不表示Pingora在任何場(chǎng)景下都優(yōu)于Nginx，而是Pingora更適合Cloudflare的用例。

CDN的規(guī)模導(dǎo)致了其對(duì)微小抖動(dòng)的敏感性，同時(shí)底層基礎(chǔ)設(shè)施的技術(shù)改進(jìn)也是Cloudflare這樣的公司點(diǎn)燃其革新火種的助力之一。Cloudflare選擇了對(duì)他們的業(yè)務(wù)模型表現(xiàn)更佳的解決方案。

但是我們注意到，近年來(lái)一些大廠在“去 Nginx”上動(dòng)作頻頻。比如：

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

（2）百度開(kāi)源采用GO語(yǔ)言的BFE；

（3）阿里巴巴云原生網(wǎng)關(guān)Higress基于Envoy，支持Nginx Ingress零成本快速遷移 。

不可否認(rèn)，Nginx在反向代理、負(fù)載均衡方面表現(xiàn)出色，但“C+Lua”的組合也的確很難在性能和安全上實(shí)現(xiàn)兩全。作為時(shí)代的產(chǎn)物，Nginx或許不能被輕易進(jìn)行比較，但“去Nginx化”似乎正在成為一種趨勢(shì)。

參考鏈接：

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