Subscribe to receive notifications of new posts:

Subscription confirmed. Thank you for subscribing!

如何構建 Pingora 以將 Cloudflare 連線至網際網路代理

Loading...

How we built Pingora, the proxy that connects Cloudflare to the Internet

介紹

今天,我們滿懷欣喜之情來談論 Pingora,這是我們使用 Rust 在內部構建的全新 HTTP 代理程式 ,其每天可處理超過 1 萬億個請求,能提高我們的效能,並為 Cloudflare 客戶實現眾多新功能,同時只需之前代理基礎結構三分之一的 CPU 和記憶體資源。

隨著 Cloudflare 的擴展,我們已經因發展而不再需要 NGINX。多年來,NGINX 一直備受追捧,但隨著時間的推移,其在規模上存在局限性,這意味著需要構建新的代理來實現。我們無法再獲得所需的效能,NGINX 也不具備極其複雜的環境所需的各項功能。

許多 Cloudflare 客戶和使用者將 Cloudflare 全球網路用作 HTTP 用戶端(如 Web 瀏覽器、應用程式、IoT 裝置等)與伺服器之間的代理。過去,關於瀏覽器和其他使用者代理程式如何連線至我們的網路,我們已經討論了很多,並且已經開發了許多技術並實施了新的通訊協定(請參閱 QUICHTTP2 最佳化),以使該連線網段更具效率。

如今,我們專注於同等事項的另一部分:代理傳送我們的網路與網際網路伺服器間流量的服務。此代理服務為我們的 CDN、Workers 擷取、Tunnel、Stream、R2,以及許多其他功能和產品提供支援。

我們來深入瞭解我們為什麼選擇取代舊式服務,以及如何開發 Pingora,這是我們針對 Cloudflare 的客戶使用案例和規模設計的全新系統。

為什麼要構建另一個代理

多年來,NGINX 的使用面臨局限性。對於某些局限性,我們已最佳化或解決。但其他一些則更難以克服。

架構局限性會損害效能

NGINX 工作者(處理序)架構在我們的使用案例中具有操作上的不足,這會損害效能和效率。

首先,在 NGINX 中,每個請求只能由單一工作者提供服務。這會導致所有 CPU 內核間的負載不平衡,進而減慢速度

由於這種請求-處理序固定效應,執行 CPU 密集型封鎖 IO 任務的請求可能會減慢其他請求的速度。正如這些部落格文章所證實的那樣,我們花費了大量時間來解決這些問題。

對於我們的使用案例而言,最關鍵的問題是連線重複使用表現較差。機器與原始伺服器建立 TCP 連線,以代理傳送 HTTP 請求。連線重複使用可透過重複使用連線集區中之前建立的連線,跳過新連線所需的 TCP 和 TLS 握手,來加速請求的 TTFB(第一個位元組接收時間)。

然而, NGINX 連線集區會針對每個工作者。當請求登陸某個工作者時,它只能重複使用該工作者中的連線。若新增更多 NGINX 工作者進行擴展,則連線重複使用率會變得更糟,因為連線分散在所有處理序更孤立的集區中。這會導致 TTFB 速度變慢,需要維護的連線也會更多,進而消耗我們和我們客戶的資源(和資金)。

正如如過去的部落格文章中所述,我們提供了其中一些問題的因應措施。但如果能解決根本問題:工作者/處理序模型,這些問題將迎刃而解。

新增某些類型的功能困難重重

NGINX 是非常好的 Web 伺服器、負載平衡器或簡單的閘道。但 Cloudflare 所做的遠不止於此。我們曾在 NGINX 的基礎上構建需要的所有功能,這並非易事,同時盡量不與 NGINX 上游程式碼庫產生太大差異。

例如,在請求重試/容錯移轉時,我們有時希望將請求傳送至具有不同請求標頭集的不同原始伺服器。但 NGINX 不允許這樣操作。在這種情況下,我們要花費時間和精力來解決 NGINX 因應條件約束。

與此同時,我們必須使用的程式設計語言並沒有幫助緩解困難。NGINX 純粹採用 C 語言,這在設計上並非記憶體安全。使用此類第三方程式碼庫非常容易出錯。即使對於經驗豐富的工程師來說,也很容易遇到記憶體安全問題,而我們希望盡可能避免這些問題。

我們使用另一種語言 Lua 來作為 C 語言的補充。其風險更小,但效能也更低。此外, 在處理複雜的 Lua 程式碼和業務邏輯時,我們經常發現自己缺少靜態類型

而且,NGINX 社群不太活躍,開發往往「閉門造車」。

決定自己開闢道路

在過去幾年中,隨著我們不斷擴大客戶群和功能集,我們對三種選擇持續進行評估:

  1. 繼續投入 NGINX 並可能建立分支,使其 100% 符合我們的需求。我們擁有所需的專業知識,但考慮到上述架構局限性,這需要付出巨大的努力,才能以完全支援我們需求的方式重建。
  2. 遷移至另一個第三方代理程式碼庫。肯定有很好的專案,例如 envoy其他方案。但這條路徑意味著可能會在幾年內重複同樣的迴圈。
  3. 從頭開始構建內部平台和架構。這種選擇需要在工程工作方面進行最大的前期投資。

在過去幾年中,我們每個季度都會評估每一種選擇。沒有顯而易見的公式來判斷哪種選擇最好。幾年來,我們不斷走阻力最小的路徑,繼續增強 NGINX。然而,在某些時候,構建專屬代理的投資報酬率似乎很值得。我們呼籲從頭開始構建代理,並開始設計我們夢想中的代理應用程式。

Pingora 專案

設計決策

為了讓代理能夠針對每秒數百萬個請求,快速、高效、安全地提供服務,我們首先必須做出一些重要的設計決策。

我們選擇 Rust 作為該專案的語言,因為它能夠以記憶體安全的方式,來執行 C 語言可執行的操作,而不會影響效能。

雖然有一些絕佳的現成第三方 HTTP 程式庫,如 hyper,但我們選擇構建自己的專屬程式庫,因為我們希望最大限度地提高處理 HTTP 流量的靈活性,並確保可以按照自己的節奏來進行創新。

在 Cloudflare,我們需要處理整個網際網路上的流量。還需要支援種種稀奇古怪、不符合 RFC 的 HTTP 流量。這是 HTTP 社群和 Web 中常見的困境,即如何在嚴格遵循 HTTP 規範的同時,適應潛在舊式用戶端或伺服器廣泛生態系統的細微差別,這兩者之間存在矛盾。選擇哪一方面都可能十分棘手。

在 RFC 9110 中,HTTP 狀態代碼被定義為一個三位整數,通常應在 100 至 599 的區間。Hyper 就是這樣一種實作。不過,許多伺服器也支援使用介於 599 和 999 之間的狀態代碼。https://github.com/hyperium/http/issues/144這種衝突曾引發過激烈的爭論。雖然 hyper 團隊最終接受了這一變更,但他們也有充分的理由拒絕此類要求,而這只是我們需要支援的眾多不合規行為的冰山一角。

為了滿足 Cloudflare 在 HTTP 生態系統中佔主導地位的要求,我們需要一個強大、寬鬆、可定製的 HTTP 程式庫,以適應網際網路上的狂野法則,並支援種種不合規的使用案例。保證這一點的最佳方法是實作內部代理。

下一項設計決策圍繞工作負載排程系統。我們選擇了多執行緒,而非多處理序,以便輕鬆共用資源,尤其是連線集區。我們還決定,需要用竊取機制來避免上述某些類別的效能問題。事實證明,Tokio 非同步執行時間非常符合我們的需求。

最後,我們希望該專案直觀且對開發人員友好。我們構建的並非最終產品,而應當是可擴展的平台,允許在其上構建更多功能。我們決定實作一個類似於 NGINX/OpenResty、基於「請求生命週期」事件的可程式設計介面。例如,「請求篩選條件」階段允許開發人員在收到請求標頭時執行程式碼,進而修改或拒絕請求。透過這種設計,我們就能清晰地將業務邏輯和一般代理邏輯分開。之前使用 NGINX 的開發人員也能輕鬆轉向 Pingora 並迅速提高工作效率。

Pingora 在生產中速度更快

我們快進到現在。Pingora 在處理幾乎所有需要與原始伺服器互動的 HTTP 請求(例如,快取未命中的情況),並且我們在此期間收集了大量效能資料。

首先,我們來看看 Pingora 如何加速客戶流量。Pingora 上的總體流量顯示,TTFB 中位數減少了 5 毫秒,第 95 百分位減少了 80 毫秒。這並不是因為我們執行程式碼的速度更快。畢竟舊式服務也能處理亞毫秒級的請求。

成本節省源自我們的新架構,它可以跨所有執行緒間共用連線。這意味著連線重複使用率提升,進而在 TCP 和 TLS 握手上所花費的時間相應地縮短。

相較於舊服務,Pingora 將所有客戶的每秒新連線用量降低至三分之一。針對其中一個主要客戶,其連線重複使用率從 87.1% 提高至 99.92%,從而將與其原本的新連線數減少了 160倍。以下數據可直觀地呈現這種變化︰轉向 Pingora 之後,我們每天能夠為客戶和使用者節省 434 年的握手時間。

更多功能

有了工程師熟悉的開發人員友好型介面,又消除了之前的條件約束,這讓我們能夠更快地開發出更多功能。憑藉新通訊協定等核心功能,我們可以為客戶提供更多產品構建區塊。

例如,我們能夠在無重大障礙的情況下,向 Pingora 新增 HTTP/2 上游支援。這讓我們很快就能為客戶提供 gRPC。要將這項功能新增至 NGINX,不僅涉及的工程量更大,並且可能無法實現

最近,我們發佈了 Cache Reserve,Pingora 在其中使用 R2 儲存作為快取層。隨著我們向 Pingora 新增更多功能,我們能夠提供各種開創性的新產品。

更有效率

在生產環境中,面對同等流量的負載,相較於舊服務,Pingora 的 CPU 消耗量減少了約 70%,記憶體消耗量減少了 67%。成本節省源自以下幾大因素。

相較於舊的 Lua 程式碼,我們的 Rust 程式碼執行效率更高。最重要的是,二者在架構上也存在效率差異。例如,在 NGINX/OpenResty 中,當 Lua 程式碼想要存取 HTTP 標頭時,必須從 NGINX C 結構中讀取、分配一個 Lua 字串,然後將其複製到 Lua 字串。之後,Lua 還必須對新字串進行垃圾回收。而 Pingora 能直接執行字串存取。

多執行緒模型也讓跨請求共用資料變得更加高效。NGINX 雖然也提供記憶體共用,但由於實作局限性,每次共用記憶體存取都必須使用互斥鎖,而且只能將字串和數字放入共用記憶體中。在 Pingora 中,大多數共用項都能透過原子引用計數器後的共用引用直接存取。

如上所述,實現 CPU 節省的另一個重要因素是建立更少的新連線。Pingora 可透過已建立的連線來傳送和接收資料,不會造成高昂 TLS 握手成本。

更安全

快速、安全地發佈功能絕非易事,在我們這樣龐大的規模下更是困難重重。在分散式環境中每秒要處理數百萬個請求,很難預測可能會發生的每種極端情況。模糊測試和分析的緩解作用也有限。Rust 的記憶體安全語義保護挺身而出,在保護我們免受未定義行為影響的同時,也讓我們堅信自己的服務將會正常運作。

有了這些保證,我們可以更多地關注服務變更將如何與其他服務或客戶來源互動。我們還能以更快的節奏開發功能,而不會因記憶體安全和難以診斷的崩潰而受到拖累。

當崩潰確實發生時,工程師需要花時間診斷崩潰如何發生,以及導致崩潰的原因。自 Pingora 運作以來,我們已處理數百萬億個請求,但還沒有遇到過源於服務代碼的崩潰問題。

實際上,Pingora 崩潰非常罕見,每次出現的問題都跟 Pingora 自身沒什麼關係。最近,我們在服務崩潰後不久發現了一個內核錯誤。我們還在幾部機器上發現了硬體問題,而在過去,要排除由軟體引起的罕見記憶體錯誤,即使進行重大偵錯也無法實現。

結論

總而言之,我們已構建了一個更快、更高效和更通用的內部代理,並將其作為我們目前和未來產品的平台。

我們將重新將視線更多地集中到技術細節,包括我們面臨的問題、我們運用的最佳化、我們從構建 Pingora 中學到的經驗教訓,以及將其推廣到網際網路的重要部分。我們還將帶著開放原始碼方案再次回歸。

Pingora 是我們重寫系統的最新嘗試,但絕不會是最後一次。它也只是我們系統重新架構的其中一個構建區塊。有興趣加入我們協助打造更完善的網際網路嗎? 我們的工程團隊正在招賢納士

我們會保護 整個企業網路 協助客戶打造 有效率的網際網路規模應用程式, 加快任何 網站或網際網路應用程式, 阻擋 DDoS 攻擊, 讓 駭客無機可乘, 還能夠協助您 順利展開 Zero Trust 之旅

透過任何裝置造訪 1.1.1.1, 即可開始使用我們的免費應用程式,讓您的網際網路更快速且更安全。

若要深入瞭解我們協助構建更美好網際網路的使命,請從 這裡 開始。您正在尋找新的職業方向,請查看 我們的開放職缺

Rust (TW) NGINX (TW) 效能 繁體中文

Follow on Twitter

Cloudflare |Cloudflare

Related Posts