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

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

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

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

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

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

為什麼要構建另一個代理

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

架構局限性會損害效能

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

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

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

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

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

完整閱讀全文https://blog.cloudflare.com/zh-tw/how-we-built-pingora-the-proxy-that-co...