SOFAGW 網關：安全可信的跨域 RPC/消息 互通解決方案

作者：樓磊磊

來源：金融級分布式架構公衆号

本文将介紹 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 把請求發送到消息中心，消息中心再把消息投遞到真實的消費方。
• 完成跨站點消息投遞。

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 一直較高，說明網絡有積壓，對此我們做了幾個針對性的優化：

1. 調小單連接配接的 max_pedding_request，建立更多連接配接：目的是減小單連接配接的并發壓力，同時，建立多個連接配接也可以讓負載更加均衡。
2. 修改 tcp_rmem 和 tcp_wmem 核心參數：這兩個是 TCP 讀寫緩沖區 size 參數，會影響 TCP 滑動視窗的大小，一般這兩個參數不需要設定，但我們發現部分機器上設定的參數有問題，預設的 buffer size 太小，導緻 TCP 滑動視窗 size 上不去，影響了資料收發速率。
3. 修改核心參數 tcp_autocorking：設定為 1 的情況下，作業系統會盡量将較小的包彙聚成一個較大的包再發送。這裡我們将雙方網關的 tcp_autocorking 設定為 0。
4. 增加 DNS 異步解析緩存，避免 DNS 解析導緻的高耗時。
5. 網關連接配接的 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 大促。