超大規模分散式儲存的連線拓撲困境
在超大規模分散式系統中，資料庫系統的瓶頸往往不只出現在磁碟讀寫或儲存引擎本身的運算能力，網路連線的維護與拓撲結構同樣會演變成系統穩定性的嚴峻考驗。根據外媒 InfoQ 報導，Meta 近期公開了其針對內部核心分散式鍵值資料庫 ZippyDB 所設計的新型無狀態代理層架構 ZGateway。ZippyDB 在 Meta 內部承載了包含產品元資料、計數器以及全域配置等海量核心負載，其背後支撐著全球數十萬台資料庫主機以及高度分散的資料分片機制。
在過去的直接存取架構下，存取資料的應用端需要自行維護與資料庫節點的連線。當系統擴展到超過一百萬台客戶端主機時，這種直接存取模式便面臨了架構極限。單一客戶端主機在處理多種業務時，可能需要存取分布在數十萬台資料庫伺服器上的數萬個資料分片，這導致整個資料中心網路內部形成密集的「多對多網狀連線架構」。在 Linux 作業系統層級，每一條 TCP 網路連線都會佔用對應的檔案描述子，也就是作業系統用來追蹤開啟網路插座的抽象資源指標，同時每個連線也都需要配置核心緩衝區。當連線數量以幾何級數激增，叢集在面對重啟或網路抖動時便容易引發連線風暴，進而導致檔案描述子耗盡與記憶體溢位等嚴重崩潰事件。
引入無狀態代理層 ZGateway 的轉折機制
為了從根源解決多對多連線所引發的系統風險，Meta 引入了名為 ZGateway 的無狀態代理層，將過去客戶端直連資料庫伺服器的兩層式拓撲，重構成包含託管代理層的三層式架構。在此新架構中，超過百萬台的客戶端主機不再直接建立通往後端儲存節點的連線，而是與其所在區域的 ZGateway 代理主機維持長效且具黏性的網路連線，後端資料庫節點則僅需接收來自數量受控的代理節點集區的連線。
在服務發現與路由方面，ZGateway 深度整合了 Meta 內部的超大規模服務網格技術 ServiceRouter。透過此服務發現中介機制，客戶端能夠自動探測並維持與本地或鄰近區域代理節點的連線，確保請求的網路傳輸延遲被壓制在區域邊界之內。ZGateway 本身採用無狀態設計，底層請求轉發引擎直接沿用 Meta 原本成熟的 C++ ZippyDB 用戶端函式庫，這使得代理層能夠原生具備資料庫協議的解析與分片路由能力。此外，ZGateway 不僅具備純粹的代理轉發功能，還能切換為讀穿透快取層，在代理端直接攔截並回應重複的讀取請求，大幅分擔後端儲存節點的計算與檢索壓力。
流量治理整合與跨進程請求優化
ZGateway 的引入不僅是連線數量的收斂，更象徵著資料庫前端流量治理機制的集中化。在舊有的架構中，身分驗證、權限檢查、分片位置計算與重試邏輯都分散在各個應用端進程的用戶端函式庫中。這不僅導致程式庫升級與安全政策推動困難，也無法進行全域性的資源協調。在 ZGateway 部署後，集中化的代理層能夠統一承擔請求的身分驗證與授權，並針對不同租戶執行精準的准入控制，也就是依據系統當前承載能力動態限制特定客戶端請求流入的速率。
更具突破性的技術優勢在於跨進程的請求合併機制。在傳統客戶端函式庫中，批次處理或合併請求的範圍受限於單一應用程式進程的內部視角，無法觀察到同主機或其他主機上其他進程的類似存取行為。ZGateway 由於居於眾多客戶端流量的匯集點，能夠在轉發前將多個不同客戶端所發出的相同分片讀取或寫入請求進行整併，直接在轉發階段減少送往底層 ZServer 副本節點的實際操作次數。
架構權衡與實務運行成效
在分散式系統設計中，引入額外的代理層通常伴隨著一個架構權衡，即增加額外的網路躍點可能帶來延遲增加的疑慮。然而，業界架構師與 Meta 的實務經驗均指出，這種額外網路跳轉的代價在超大規模場景下是完全值得的。正如外部系統架構師所分析，雖然資料路徑多了一層跳轉，但資料庫底層儲存節點得以從殘酷且昂貴的連線管理、執行緒切換以及中斷處理中徹底解脫，進而讓 CPU 資源能全力專注在儲存引擎的磁碟與記憶體操作上，反而使整體的端到端請求延遲獲得改善。
根據 Meta 的運算模型與運行數據，ZGateway 架構成功將單一資料庫主機的連線負載降低了約百分之九十七至百分之九十八，叢集整體的持久連線總數更是大幅減少了約十九倍。目前，ZGateway 每日穩定承載超過每秒十億次的操作請求，並已消化 ZippyDB 全球整體流量的四成以上。在系統韌性與過載保護的實際壓力驗證中，當代理叢集的整體 CPU 使用率達到超過百分之九十的極限狀態時，系統針對約一千三百五十個租戶儲存貯體啟動自適應保護，最終僅有六個超量使用的租戶被實施局部流量卸載，其餘高達百分之九十九點九以上的租戶請求皆維持正常處理未受影響。
為了確保超大規模遷移過程的安全，Meta 採取了極度謹慎的漸進式切換策略，系統支援依照個別業務服務、資料分片前綴、特定流量百分比或地域區域逐步將請求導入 ZGateway，並具備全域快速切斷開關以便在非預期狀況發生時迅速回退至直連模式。展望未來演進，Meta 計畫逐步將 ZippyDB 的全部流量完全遷移至 ZGateway 上，並持續探索具備代理自主操作的控制層、與 ZServer 儲存節點的選擇性共置部署，以及導入多進程隔離架構，藉此在代理層內部實現更強大的故障隔離邊界，確保超大規模資料架構的長期穩定運作。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。