作者 | 王曉彬
為解決數據跨網問題，政采雲搭建了一條基於 Dubbo 的「高速公路」，同時採用了 APISIX 作為中心網關，為網絡路由、公共特性提供支持。本文將重點介紹政采雲「高速公路」工程建設中如何採用節流策略來應對挑戰。我們將討論鏈路協議的優化實踐以及對網絡傳輸效率的思考。
政采雲平台是一個政府採購專屬平台，為各級政府部門和國有企業提供支持。從網絡架構的角度來看，政采雲平台是一個集合了公有雲、私有雲和政務雲的混合雲網絡。所以對於業務來說，跨網數據傳輸是一個常見的需求場景。
為了滿足這種需求，政采雲「高速公路」工程於 2022 年底啟動，旨在整合現有的網絡傳輸方案，提供一致、便捷和高速的跨網業務體驗。隨著跨網方案整合的推進，公司的跨網流量越來越多地流向了新型基礎設施——政采雲「高速公路」工程。
挑 戰
「高速公路」方案得到了公司的支持，在 2023 年上半年通過新業務的試點後，下半年開始陸續遷移歷史跨網方案的業務。從監控中，我們感受到了來自流量的壓力。具體表現為：
- 心跳應用告警頻繁發生。
- 監控指標如響應時間（RT）和吞吐量下降。
為了確保業務的穩定性並提高用戶體驗，我們採取了各種優化措施。總體而言，我們主要探索了兩種思路：
綜合考慮這兩種思路，可以在資源充足的同時，通過性能優化來確保系統的穩定性和高可用性。這種綜合策略通常是解決高壓力環境下的系統性能問題的有效方法。
問題與目標
跨網 RPC（「高速公路」）的主要流程
整個流程對性能影響比較大的環節有：Sdk 行為 [1,9]，網絡傳輸 [2,4,6,8] 和網關行為 [3,5,7]。其中，Sdk 行為涉及到 RPC 框架選型，在當前公司已經廣泛使用 Dubbo 的背景下，可以先不考慮。需要重點考慮的，則是網絡傳輸中協議的選擇以及網關對性能的影響。
傳輸協議問題
鑒於現有背景，用戶通常希望使用本地 Dubbo 一樣直接跨網。所以。「高速公路」工程的設計是圍繞 Dubbo 框架的特性進行的。
與業務對接中，經常會被問到，我們使用了 Dubbo 的某個特性，你們能否支持？出於對場景支持的考慮，在設計「高速公路」架構時，我們重點考慮了接近原生體驗的特性。為此，我們設計了隧道機制。現在，基於這一特性，我們可以輕鬆地對業務說：「是的，可以支持！」
隧道機制方案的中間層使用了 HTTP 協議作為隧道協議，它可以穿透層層網絡設備和網關，是比較穩健的一種方式。但是在流量壓力下，整體的性能 / 吞吐量，逐漸成為當前方案的主要矛盾。
首先，在協議層面，我們先要了解下 HTTP/1.1 協議存在的性能問題。
- HTTP 頭部巨大且重複，由於 HTTP 協議是無狀態的，每一個請求都得攜帶 HTTP 頭部，特別是對於有攜帶 Cookie 的頭部，而 Cookie 的大小通常很大；
- 隊頭阻塞問題，同一連接只能在完成一個 HTTP 事務（請求和響應）後，才能處理下一個事務；
為此，我們需要尋找一個更加高效的傳輸層協議來代替 HTTP/1.1。
網關問題
另外一個比較明顯的瓶頸，是本地集群內的 Dubbo 網關。
Dubbo 網關負責接收來自本地客戶端的 Dubbo 協議數據，反序列後通過 HTTP 轉發至公網中心網關。因為市面上沒有 Dubbo 轉 HTTP 的網關，第一個版本我們選擇了自研。在轉發效率上，顯然有天然的不足。主要有以下幾個原因：
1. 對網關本身性能的擔憂。比如下圖中，Spring Cloud Gateway 對比其他網關的性能表現不足。同樣是基於 Netty 的 Java 網關，我們也沒有信心能比 Spring Cloud Gateway 更優秀。
圖片來源見參考資料
2. 額外的參數序列化程序。由於需要轉換協議，網關需要額外的一次序列化和反序列化。同時由於 Dubbo 網關不存在業務參數對象，我們需要一個通用的 JavaBean 描述對象作為過渡，這又增加了一次轉換。
3. HttpClient 串行阻塞式的通信方式，將大大的降低並發效率。
為了解決上述問題，我們需要一個類似於 NGINX 的高性能、非阻塞的網關來實現高效的反向代理，並使用更精簡的通信協議來提高吞吐量。
優化方案
協議方面
協議方面，我們嘗試使用了 Dubbo 協議作為隧道協議。這能帶來哪些收益呢？簡而言之包括兩個方面。
- 減少包的大小，提高網絡吞吐量
Dubbo 協議更加精簡，承載的頭部信息更少。協議設計上很緊湊，能用 1 個 bit 表示的，不會用一個 byte 來表示，比如 boolean 類型的標識。Http 為了更好的兼容性，請求頭部攜帶了很多上下文和元數據。對於內部通信來說，服務端和客戶端相對固定，很多信息是沒有必要的。以下是 Dubbo 官方性能測試，Tps（每秒處理事務量）Dubbo 協議比 Http 高 30%-50% 左右（最常見的高並發小數據量場景）。
另外，Dubbo 使用長連接，可以重複使用已經建立的 TCP 連接，減少了連接建立的開銷。
- 傳輸協議開銷
由於整條鏈路使用了相同協議，可以避免不同協議間的裝包和解包。
網關方面
網關方面，我們使用了 APISIX 代替 Dubbo 網關。
APISIX 是基於高性能的 OpenResty 開發的，從架構和設計角度對性能追求極致，因此可以滿足我們對網關性能的基本要求。同時，它具有出色的擴展性，能夠滿足我們的自定義需求。簡而言之，我們既希望享有類似 NGINX 的高性能，又希望可以根據需要擴展功能。
APISIX 實現了 xRPC 四層協議擴展框架，允許開發人員自定義特定於應用程式的協議。基於 xRPC 框架，APISIX 可以提供幾種主要應用協議的代理實現，用戶還可以基於該框架支持自己私有的基於 TCP 的應用協議，使其具有類似於 HTTP 協議代理的精確粒度和更高級別的 7 層控制。通過使用 APISIX 的 xRPC 擴展，我們成功地增加了對 Dubbo 協議的直接轉發功能，從而實現了全鏈路 Dubbo 協議傳輸。
這一舉措解決了之前提到的兩個問題：顯著提升了網關性能，同時減少了協議轉換的成本。此外，我們也不再需要維護額外的應用網關，實現了中間件層面的收斂。
我們已經通過 PR （https://github.com/apache/apisix/pull/9660）的方式將上述特性提交給 APISIX 社區，因此下一個版本中我們將能夠直接使用開源版本。
註：APISIX 的 Dubbo 插件支持 HTTP 轉 Dubbo，目前沒有 Dubbo 直接轉 Dubbo 的方式。雖然 Dubbo 協議是私有協議，但是 Dubbo 框架的應用非常廣泛，這一特性可能會有很多意想不到的用法。
本輪改造不足
2022 年下半年，我們對各跨島方案，進行了整合升級，也就是現在的「高速公路」方案，保障跨島標準化同時，解決了之前方案實踐過程中面臨的很多業務痛點。通過替換隧道協議，我們希望優化網絡 IO 模型，提高鏈路轉發效率。經初步測試，單次 2k 包請求 RT 可以降低 1/3 左右。
但是，在實踐業務場景中，該架構下一些痛點也開始逐漸顯現。
支持場景不足
對雲島業務結構的公司來說，雲平台屬於公司內部、完全可控的區域網，而島端則是有自己安全網絡策略的獨立內部網絡。我們的跨網 RPC 需要穿透混合雲網絡中的各種設備和網關，到達雲島的另一頭服務。Dubbo 協議作為私有協議，在大部分的跨島場景中並不適用。
目前，這種模式只能在內部的一些網絡使用，比如獨立搭建的 AI 集群和平台業務集群的通信。當然，基於「高速公路」架構的良好擴展性，我們可以做到不同場景自動切換協議，在獲得 Dubbo 協議優勢的前提下，也能退化 HTTP 協議兜底。
對網絡吞吐量的優化不足
接口需要發送大量數據時，這些數據無法被放在一個 RPC 的請求或響應中，需要分批發送。Dubbo 協議下，這種情況只能串行發送。Dubbo 協議在單次請求下性能較好，但是整體吞吐量的提升仍然不夠。
在我們的跨網第一個版本上線前，曾經做過性能壓力測試。測試場景如下：
雲端調島，上行數據，30M 帶寬，發送 2KB 數據，逐步增大並發量。
30M 入口帶寬，發送 2KB 數據，TPS 大於 500/s，入口帶寬將成為瓶頸。當發送數據增加到 80KB，TPS 下降約 16 倍，RT 上升約 1.5 倍。
從監控上看，tps 到達一定量後，帶寬即達到上限。
可以看到，當前「高速公路」的實際業務場景下，吞吐量是「高速公路」第一個版本最大的一個瓶頸。此次網關和協議的升級，顯著降低了 RT 指標，一定程度提升了整體吞吐量。
後續規劃
經過對 APISIX 的協議擴展，我們使用 APISIX 代替了 Dubbo 自研網關，基本實現了對通信效率的預期優化。但是，我們也有支持場景和通信效率兩個明顯的痛點需要解決。為此，我們重點調研了 Dubbo3 主力通信協議——Triple 協議。
Triple 協議是 Dubbo3 設計的基於 HTTP 的 RPC 通信協議規範，它完全兼容 gRPC 協議，支持 Request-Response、Streaming 流式等通信模型，可同時運行在 HTTP/1 和 HTTP/2 之上。對於我們項目來說，Triple 協議的幾個特性剛好是我們欠缺的。
- 完全兼容基於 HTTP/2 的 gRPC 協議
Triple 協議聽起來是個私有協議，實際上則是標準的公有協議，兼容 HTTP/1 和 HTTP/2。這意味著穿透性強，痛點之一的場景支持就不再是問題了。
對比 HTTP/1，二進位分幀帶來的並行效率提升，首部壓縮減少大量包體，在網絡吞吐量上，HTTP/2 在性能上有了極大提升。
- 作為 Dubbo 主力協議，仍然保留著避免協議轉換的優勢，與「高速公路」架構契合
經過 Dubbo2 協議的實踐與總結，我們將著力推動 Triple 協議的升級，完美解決性能問題。
未來，我們將按以下幾步進行：
作者介紹：
王曉彬，Apache Dubbo Commiter、政采雲資深開發工程師，負責基礎服務相關工作。
參考資料：
https://www.jianshu.com/p/7182b8751e75
https://www.infoq.cn/article/qfcz1fj9wvFvGidjpcho
https://zhuanlan.zhihu.com/p/432512918
https://cn.dubbo.apache.org/zh-cn/docsv2.7/user/perf-test/
「這是一件關於雲服務的大事兒！」英特爾 4400 萬美元投資基礎設施初創公司，硬剛公有雲
頭髮絲 1/60 的精度，中國每 10 輛新能源汽車就有 6 輛用這家齒輪
語雀突發 P0 級事故！宕機 8 小時被網友怒噴，運維又背鍋？
智譜 AI「超 25 億融資」的背後