作者：樓磊磊
來源：金融級分佈式架構公眾號
本文將介紹 SOFAGW 互通網關，首先切入在跨站點通信時碰到的核心痛點，引入 SOFAGW 互通網關的解決方案，會重點說明如何解決在安全、互通、接入成本、高效等幾方面問題，介紹 SOFAGW 網關的內部實現架構，展示 SOFAGW 網關達成的業務成果。
業務痛點
隨著業務發展越來越多元化，部分業務域相對比較獨立，或因其業務屬性，會建立成獨立的站點（租戶），比如：國際業務和螞蟻保等。這些站點之間網絡是隔離的，但實際業務上會存在一些通信的需求，所以我們碰到的核心問題是：網絡互相隔離的多個站點之間怎麼做高效可信的通信？對此我們有兩種針對站點間互通的解決思路：
思路1：為每個業務創建跨域 VIP
為每個業務創建跨域 VIP，站點的業務通過 VIP 來做通信。這種方式，運維管理員要在兩個網絡間開很多 VIP，加訪問白名單，最終網絡拓撲會變成如下；將面臨網絡口子多、運維成本高、業務接入成本高、安全閾值低等問題。
這個方案有以下幾個問題：
- 很多服務需要開 VIP 口子，服務多了之後，VIP 難以維護；
- VIP 的 ACL 控制很弱，只能基於 IP 端口或 IP 段控制，不能按業務應用或服務來做控制；
- 安全管控能力很弱，對請求不可審計；
- 業務適配改造工作量大，技術棧不統一，存在多種 RPC 框架。
思路2：實現一個高效可信的互通網關，來承接站點之間的通信代理
這就是我們採用的多站點互相通信的解決方案，下面詳細介紹我們的互通方案和重點解決的問題。
解決方案：SOFAGW 互通網關
鑑於上面提到的問題，我們研發了 SOFAGW 互通網關，致力於實現一個簡單高效、安全可信的跨域 RPC/消息 互通網關。
如上面的整體架構圖所示，我們的解決方案是各站點部署一套 SOFAGW 網關，把站點間的通信都收斂到 SOFAGW 上，由 SOFAGW 來保證安全通信，而在研發體驗上，業務方同學按照本地服務做開發，不用為跨域通信做特殊處理，做到無縫接入。
RPC 互通過程：
- 在 SOFAGW 網關上，申請接入需要互通的 RPC 服務。接入後，消費方 SOFAGW 網關會把這個 RPC 服務發佈到本站點註冊中心上，服務方 SOFAGW 網關會從註冊中心訂閱這個 RPC 服務提供方地址。
- 消費方應用通過註冊中心訂閱到目標服務是本站點的 SOFAGW，把請求發送到本站點的 SOFAGW。
- 本站點的 SOFAGW 根據 API 配置信息，把請求轉發到對端站點的 SOFAGW。
- 對端站點的 SOFAGW 根據註冊中心訂閱到的地址，把請求發送給真實的服務提供方。
- 完成跨展達 RPC 通信。
消息互通過程：
消息的互通和 RPC 互通非常類似，差別主要在於需要通過消息中心來收發消息。
- 在 SOFAGW 網關上，申請需要接入互通的消息服務。
- 客戶端把消息投遞到本站點的消息中心，消息中心把消息封裝成 RPC 請求發送到本站點 SOFAGW。
- 本站點的 SOFAGW 根據 API 配置信息，把請求轉發到對端站點的 SOFAGW。
- 對端站點的 SOFAGW 把請求發送到消息中心，消息中心再把消息投遞到真實的消費方。
- 完成跨站點消息投遞。
SOFAGW 互通網關重點解決以下幾個痛點：
1、安全通信
首先我們要解決網絡不可達問題。從圖裡可以看到：每個站點都部署了 SOFAGW 網關，網關之間可以用專線或 VIP 之類的產品打通，這樣站點間把流量就收斂到了 SOFAGW 網關，避免到處開網絡通道口子，便於安全管理。
網絡安全
為了保證 SOFAGW 網關之間的通信安全可信，我們開啟了 mTLS 雙向認證，既能對數據做加密，也能確認對方的身份可信，從而確保通信安全。
數據安全
一個站點（租戶）會給其他多個站點提供服務，這些暴露的服務首先要確保租戶級別的水平權限隔離，也就是說，A 站點暴露給 B 站點的服務，不能被 C 站點的應用調用到。如何做到這點？
- SOFAGW 網關會給不同站點提供不同的訪問域名（這些域名都會解析到 SOFAGW 的 VIP 上）。
- SOFAGW 之間通過 mTLS 雙向認證通過後，可以確認請求的域名（ host ）可信，也就是 C 站點的應用無法用B 站點的域名與 A 站點的 SOFAGW 網關建立 TLS 連接。
- SOFAGW 會通過請求頭裡的 host + path 路由做路由轉發，C 站點的請求無法匹配上提供給 B 站點的域名，也就無法訪問到提供給 B 站點的服務。
除了要確保租戶級別的水平權限控制，SOFAGW 還具備應用級別的 ACL 權限控制，如果一個 API 服務只暴露給某特定應用，那其他的應用是無法訪問這個 API 服務的。
另外，站點間的通信數據不是任意的，目前在業務 API 接入過程中，我們會有嚴格的數據安全審計流程。
2、統一技術棧，跨域 RPC/消息 互通
不同的業務方會使用不同 RPC 框架，如 SOFARPC、HSF、Dubbo，底層用的通信協議和序列化協議也不一樣，很難直接通信，如果做協議轉化適配又會有很大的成本。在性能、擴展性和新特性支持等方面，老的各種協議難以滿足發展需求，也很難在原有協議的基礎上擴展以支持新的功能。為了更好的支持業務發展，對齊各 RPC 框架通用能力，需要設計一種新的通用的協議，從協議層解決以上問題。
所以，阿里巴巴及螞蟻集團共同制定了 Triple 協議，讓內部使用的編程框架都支持 Triple 協議，這樣大家互通時就會很順暢。
Triple 協議是什麼？
Triple 協議本身，是基於 gRPC-over-HTTP2 擴展的 RPC 協議，與現有的其他 RPC 協議比較， 有以下優勢：
- 多種 RPC 模式 ( P2P/ Reactive Streams/ Bidirectional / Pub-Sub )
- 基於 protobuf 提供統一的服務定義以及 API 治理
- 更好的性能 ( Protobuf / Protostuff / Back Pressure )
- 原生跨語言支持 ( C++/ Dart/ Go/ Java/ Python/ Ruby/ C# / OC / JS / PHP )，原生兼容 gRPC 客戶端
- 易於升級和修改協議
- 兼容現有的 RPC 框架，易於協議升級和互通 ( gRPC / SOFA-RPC / HSF / Dubbo ...)
- 對網關型應用友好，原生支持 gRPC-over-HTTP2
- 支持移動設備原生調用
Triple 遵循 gRPC-over-HTTP2 協議規範，使用 CUSTOM-METADATA 擴展元數據。對於已經存在的 grpc- 開頭的 Header 保持不變，保證與原生 gRPC 客戶端/服務端互通，對於協議中不存在需要新擴展的 Header，將以 tri- 開頭。另外，即將發佈的 Dubbo 3.0 也是以 gRPC 為基礎，Triple 能和 Dubbo 3.0 保持良好兼容。
舉例，當前我們約定的 Triple 協議頭：
3、無縫接入
為了讓業務方無縫接入，SOFAGW 網關和註冊中心專門做了聯動，具體原理從上面的整體架構圖可以看到：
- 在調用端，SOFAGW 網關把目標服務發佈到了註冊中心，調用端可以通過註冊中心訂閱到 SOFAGW 網關地址，請求直接打到 SOFAGW 網關上。
- 在服務端，SOFAGW 網關從註冊中心訂閱了服務端地址，SOFAGW 收到請求後，直接把請求路由到目標服務端。
通過這套邏輯，研發同學在研發時就按照本地服務做開發，不用為跨域通信做特殊處理。
在研發框架和協議適配上，我們還做了以下優化：
- 針對雙邊使用了不同的 RPC 框架，大家統一使用 Triple 協議，我們對 SOFARPC、HSF 等框架升級支持了 Triple 協議，用戶升級框架後支持發佈訂閱 Triple 服務，和原先使用 RPC 幾乎一樣，用很低的成本接入使用 RPC 互通服務。
- 同時 SOFAGW 網關也支持 Bolt 協議，對於雙方都使用 SOFARPC 框架場景，業務方不需要改造就可以實現無縫對接，完成跨站點 RPC 通信。
從前面的架構上可以看到，站點間通信需要過兩次網關，整體鏈路變長，對問題定位排查都增加了額外的成本。為此，我們做了全鏈路 tracer 打通、壓測流量識別和打通，藉助服務治理平臺，業務方可以快速定位到問題出現在哪個環節。
4、 高效、高性能
站點間通信經過兩次網關，通信耗時肯定會有所上升，再加上網關自身的開銷和網絡時延等，整體效率是下降的。為了減小這些額外開銷，我們從幾個方面做了優化：
- 支持靈活的路由能力，縮短網絡跳轉距離
- 網關和系統參數調優，提升性能
多種路由能力
對於一個站點（租戶），它可能有多個機房多地部署，而且不同機房的服務不一定對等，我們需要提供靈活的路由配置能力，來降低整個鏈路上的網絡開銷。為此，SOFAGW 網關提供了多種路由能力：
- 指定目標機房路由
- 按地理位置就近路由
- 螞蟻的單元化路由
- 自定義配置路由
這些路由能力除了能提升通信效率，還有其他的作用，比如按百分比引流、灰度引流驗證等，這裡不再詳述。
網關和系統參數調優
從架構看，整體鏈路好像沒什麼問題，實際壓測發現，有很多細節點影響性能，導致併發量上不去。最典型的問題，是發現請求和響應的傳輸耗時高，進一步通過 netstat 命令發現 send-q 一直較高，說明網絡有積壓，對此我們做了幾個針對性的優化：
- 調小單連接的 max_pedding_request，創建更多連接：目的是減小單連接的併發壓力，同時，創建多個連接也可以讓負載更加均衡。
- 修改 tcp_rmem 和 tcp_wmem 內核參數：這兩個是 TCP 讀寫緩衝區 size 參數，會影響 TCP 滑動窗口的大小，一般這兩個參數不需要設置，但我們發現部分機器上設置的參數有問題，默認的 buffer size 太小，導致 TCP 滑動窗口 size 上不去，影響了數據收發速率。
- 修改內核參數 tcp_autocorking：設置為 1 的情況下，操作系統會盡量將較小的包匯聚成一個較大的包再發送。這裡我們將雙方網關的 tcp_autocorking 設置為 0。
- 增加 DNS 異步解析緩存，避免 DNS 解析導致的高耗時。
- 網關連接的 idle 超時時間調整，避免頻繁建連帶來的額外耗時。
SOFAGW 內部架構實現
下圖是 SOFAGW 網關的內部架構，介紹下內部各組件的作用：
控制面：
- configer 和 provider：網關配置管理器，網關的配置完整定義了各組件的行為，比如 API 配置來源、listener 的端口和協議、handler 的插件等。配置來源可以是管控端、Istio、本地文件，根據配置裡的 API 定義，會從註冊中心訂閱服務端地址構建起 upstream 的集群信息。
數據面：
- listener：網關的監聽器，也是網關接收請求的入口，根據定義的端口、協議、連接參數等信息處理對應的請求。
- handler：網關的核心處理器，這裡可以自定義很多插件，來選擇是否啟用一些能力，比如限流、路由等。
- dialer：網關的轉發處理器，這一層比較簡單，就是把請求轉發給後端服務器。
總結和價值
SOFAFW網關和常見API網關差異
目前常見的 API 網關有 Spring Cloud Gateway，Zuul2，OpenResty，Kong 等，它們的核心能力是把內部的 API 服務代理給外部業務調用，並且提供統一攔截所有請求，實現安全、限流、審計等能力。
從前文可以看到，SOAFGW 互通網關和這些網關的主要差別在定位場景上，我們的核心目標是實現安全可靠的 RPC/消息 互通服務，主要特點有：
- 實現跨域 RPC/消息 互通
- 安全可信
- 業務無縫接入
- 高性能和高穩定性
SOFAGW 網關和Service Mesh的聯繫
Service Mesh 也就是服務網格，通過 Sidecar 做服務之間的通信代理，從這個定位上能看出，SOFAGW 網關在數據面上做的是同樣的事情，都是服務通信代理，是Service Mesh的自然延伸。
事實上，SOFAGW 網關就是基於螞蟻開源的 Service Mesh 框架 MOSN 實現，所以 SOFAGW 網關可以複用 MOSN 的很多能力和插件，比如最新發布“Service Mesh 雙十一後的探索和思考(上)”中提到的鏈路加密、自適應限流、精細化引流等能力。
最終我們呈現給用戶的是業務方可以無感實現跨域 RPC/消息 互通，並保證通信鏈路的安全可靠穩定。原先業務方通過其他方式實現站點間通信需要 2-7 天，接入 SOFAGW 網關後，平均接入時間降到半天內，大大提升了研發效能。
上線不到一年，SOFAGW 網關已承載幾百個服務，日常峰值流量在幾十萬 QPS，轉發成功率為 99.99992%，服務了不少核心業務，成功支撐了 2020 年的雙 11 和雙 12 大促。