電商雲 BEP 閘道器詳解
文 | 和君 on 雲平臺
一、背景
1.1 什麼是電商雲？
電商雲是在有贊 SAAS 產品的基礎上提供的一整套定製解決方案，提供了完善的 APP 執行時託管，強大的前端視覺化定製能力以及後端業務流程編排定製能力。
1.2 什麼是 BEP?
BEP 全稱是 Bussiness Extension Point（業務擴充套件點），業務擴充套件點是由有贊（內部）核心域系統定義的擴充套件點 API，這些擴充套件點 API 由電商雲（外部）定製域 APP 根據自己的定製需求實現，從技術來講類似 SPI（Service Provider Interface），有贊（內部）核心域系統會將這些業務擴充套件點編排起來提供強大的執行時可定製能力。
1.3 什麼是BEP閘道器？
BEP 閘道器的核心作用是將有贊（內部）核心域系統發起的業務擴充套件點請求路由到電商雲（外部）定製域 APP。
二、BEP 閘道器設計難點
2.1 如何適配兩種完全不同的服務治理解決方案？
BEP 閘道器設計難點是有贊（內部）核心域跟電商雲（外部）定製域採用完全不同的服務治理解決方案，有贊（內部）核心域服務治理方案已經成型，基於 Dubbo 定製實現，而電商雲（外部）定製域服務治理方案是全新選型的，以 Kubernetes 容器排程平臺為基礎來實現。
2.2 部署上如何實現網路隔離？
有贊（內部）核心域跟電商雲（外部）定製域是兩個需要嚴格網路隔離的域，BEP 閘道器處於兩個域的中心，需要在部署上考慮如何實現網路隔離。
三、BEP 閘道器選型
3.1 BEP 閘道器跟 API Gateway 的異同
API Gateway 的架構一般如下：
3.1.1 API 開放性的差異
API Gateway 一般是從外部到內部，完成請求的鑑權、路由、協議適配等，而BEP閘道器是從內部到外部。API Gateway 提供的 API 從開放性上可以分為 PRIVATE/PUBLIC/PARTNER，而 BEP 閘道器提供的擴充套件點 API 從開放性上只有 PUBLIC，因此 BEP 閘道器的鑑權是非常輕的，不需要獨立的身份認證和鑑權體系。
3.1.2 API 請求協議的差異
API Gateway 的請求協議一般是 HTTP+JSON，而 BEP 閘道器為了儘量保留有贊（內部）核心域系統的使用習慣，採用是 Dubbo Rpc。
3.1.3 Backend 請求協議的多樣性
API Gateway 跟 BEP 閘道器的 Backend 請求協議都是多樣性的，電商雲（外部）定製域目前只提供了 Java 語言的 APP 執行時，但是未來一定會引入更多的開發語言，要求 BEP 閘道器能夠支援協議適配轉換。
3.2 技術選型
綜上所述，BEP 閘道器不適合直接選用業內現成的 API Gateway 方案，比如 Zuul、Spring Cloud Gateway，我們選擇了基於內部定製 Dubbo 版本的基礎上進行自研。
3.3 部署架構
3.3.1 兩種完全不同的服務治理解決方案適配
BEP 閘道器 Backend 路由轉發採用類似 Service Mesh 的技術架構，Sidecar 對 BEP 閘道器遮蔽了電商雲（外部）定製域的服務治理細節，從而降低了 BEP 閘道器的實現成本，BEP 閘道器只需要感知有贊（內部）核心域的服務治理方案，不需要感知電商雲（外部）定製域服務治理方案（而是交給 Edge Sidecar 來感知），這樣就能保證兩種完全不同的服務治理解決方案之間的鬆耦合，各自可以獨立的進行迭代。
3.3.2 網路隔離
電商雲（外部）定製域採用公網 LVS 接入 Edge Sidecar，BEP 閘道器跟 Sidecar 同機部署，BEP 閘道器轉發請求時，直接將請求轉發給 Sidecar 暴露的本機埠，而 Sidecar 跟公網 LVS 保持長連線，並且通過 TLS 進行加密和鑑權（特別注意，雖然是通過公網訪問 LVS，但是因為兩個域都在雲廠商的同一個可用區，所以訪問延遲和穩定性是有保障的）。
3.4 詳細設計
3.4.1 SDK
SDK 完成 BEP 呼叫核心公共邏輯的封裝，在有贊（內部）核心域，身份主體標識一般是店鋪，而電商雲（外部）定製域 APP 的身份主體標識是 APP，SDK 需要判斷店鋪所有者是否授權 APP 進行能力定製，並且查詢已授權的 APP 有沒有訂閱相關擴充套件點的實現，通過將這些關鍵的核心邏輯前置在 SDK，可以保證對標準店鋪（沒有進行能力定製的店鋪）的訪問效能基本不受影響。
3.4.2 請求接入
BEP 閘道器通過一個通用的 Dubbo Provider 接入所有的擴充套件點呼叫請求，新增擴充套件點 BEP 閘道器無需重啟，通過元資料快取模組非同步管理擴充套件點元資料。
3.4.3 協議轉換
BEP閘道器的接入協議是預設的 Dubbo Rpc 協議，該協議有一個非常大的問題是報文的可擴充套件區域不在頭部而在尾部，要想解析可擴充套件區域需要對整個報文做完整的解析，這對於 Sidecar 的效能和對協議細節的侵入性是一個巨大的挑戰，因此我們選擇把 Dubbo Rpc 協議封裝成 HTTP2 協議，通過 HTTP2 協議強大的頭部可擴充套件能力實現路由控制等服務治理能力。
3.4.4 路由轉發
BEP 閘道器的路由轉發邏輯比較簡單，只需要將請求轉發給 Sidecar 暴露的本機介面即可，不需要直接路由到目的地址和埠，但是特別注意，BEP 閘道器需要在協議轉換時將目的路由資訊附加到報文頭部可擴充套件區域，如上圖所示，放到 HEADERS frame，Edge Sidecar 會解析報文頭部可擴充套件區域獲得目的路由資訊，然後進行真正的路由轉發。
3.4.5 健壯的隔離保護機制
電商雲（外部）定製域 APP 是由外部開發者開發的，穩定性無法保證，為了避免將有贊（內部）核心域系統拖垮，BEP 閘道器實現了超時控制和熔斷保護。
3.5 未來規劃
3.5.1 支援多語言APP
目前電商雲（外部）定製域提供的 APP 執行時環境只支援 Java 語言，BEP 閘道器也只支援路由到 Java 語言 APP，未來隨著更多開發者進來，需要BEP閘道器對請求做協議轉換適配以支援多語言 APP。
3.5.2 完善通用閘道器能力
BEP 閘道器未來會繼續完善限流、日誌、監控等通用閘道器能力，會盡量利用有贊內部或者業內開源的成熟的元件和產品。
四、電商雲（外部）定製域服務治理
電商雲（外部）定製域採用 Kubernetes 容器編排排程平臺，服務治理採用基於 Istio 的 Service Mesh 架構上進行定製。
4.1 Kubernetes 實現多租戶隔離
電商雲（外部）定製域是一個非常典型的多租戶場景，不同的APP會根據自己的需求實現業務擴充套件點，電商雲（外部）定製域基於 Kubernetes 成熟的多租戶技術實現租戶隔離。
4.2 Tether 取代 Envoy
有贊內部應用非常成熟的 Tether 中介軟體取代了 Envoy，由 Tether 跟 Istio 的控制平面進行互動，完成服務發現和路由控制，應用框架只需要將請求轉交給部署在同一個 Pod 裡的 Tether 即可。
4.3 Edge Sidecar
Edge Sidecar 是兩個隔離的服務治理域之間互相呼叫的一個關鍵，我們驚喜的發現，螞蟻金服開源的 SOFA Mesh 從設計上也採用了 Edge Sidecar 作為東西向服務間通訊的一個特殊橋樑。
五、總結
BEP 閘道器不但是有贊（內部）核心域訪問電商雲（外部）定製域的核心閘道器，同時也引入了全新的電商雲（外部）定製域服務治理方案，這些寶貴的實踐經驗也將給有贊（內部）核心域服務治理帶來新的演進方向。
-The End-
Vol.126
有贊技術團隊
為 300 萬商家，150 個行業，200 億電商交易額
提供技術支援
微商城｜零售｜美業
技術部落格：tech.youzan.com
The bigger the dream,
the more important the team.