?撰稿丨千山
近日來,網(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)核的負載不平衡,從而導(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ù)人認為編程語言的安全性主要是用于預(yù)防錯誤,但對于一家公司來說,我們發(fā)現(xiàn)編程語言的安全優(yōu)勢還可以用來完成一些被認為非常困難、或不可能安全實現(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零成本快速遷移 。
不可否認,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