成本直降50%，下一代閘道器震撼釋出

阿里巴巴雲原生發表於2021-10-15

作者｜如葑

傳統閘道器分類及部署模式

行業中通常把閘道器分為兩個大類：流量閘道器與業務閘道器，流量閘道器主要提供全域性性的、與後端業務無關的策略配置，例如阿里內部的的統一接入閘道器 Tengine 就是典型的流量閘道器；業務閘道器顧名思義主要提供獨立業務域級別的、與後端業務緊耦合策略配置，隨著應用架構模式從單體演進到現在的分散式微服務，業務閘道器也有了新的叫法 - 微服務閘道器（圖示說明如下）。在目前容器技術與 K8s 主導的雲原生時代，下一代閘道器模式依然是這樣嗎？

下一代閘道器產品畫像

正如上文圖中的提問：在容器技術與 K8s 主導的雲原生時代，下一代的閘道器模式仍然會是傳統的流量閘道器與微服務閘道器兩層架構嗎？帶著這個問題並結合阿里內部沉澱的閘道器技術與運維經驗，我們嘗試為下一代閘道器產品做了產品畫像，說明如下：

作為下一代閘道器產品，我們對其中幾個非常核心的要素展開說明下：

雲原生：要支援標準 K8s Ingress、K8s Gateway API 以及 K8s 服務發現，在雲原生時代 K8s 已經成為雲 OS，而 K8s 原生叢集內外部的網路是隔離的，負責外部流量進入 K8s 叢集的規範定義就是 K8s Ingress，K8s Gateway API是 K8s Ingress 的進一步演化，基於此作為下一代閘道器勢必要支援這種特性。
擁抱開源：要基於開源生態構建閘道器，藉助開源並助力開源，相信這點大家應該都不陌生。
高擴充套件：任何一個閘道器的能力都不可能覆蓋所有的使用者訴求，要具備可擴充套件能力，例如 K8s 的蓬勃發展與其開放的擴充套件能力功不可沒。
服務治理：隨著應用架構演進到分散式微服務，閘道器本身就是為後端業務提供流量排程能力，其支援基本的服務治理能力也就順其自然了。
豐富的可觀測性：分散式微服務架構帶來協同效率提升等益處的同時，對於問題排查及運維帶來了更大的挑戰，作為流量橋頭堡的閘道器需要具備豐富的可觀測資料，幫助使用者來定位問題。

雲原生閘道器的誕生

基於上述我們對下一代閘道器的理解，率先在阿里內部推出了雲原生閘道器，併成功在多業務上線部署且經歷了雙11大促的考驗，雲原生閘道器圖示說明如下：

雲原生閘道器的產品優勢

更經濟：將流量閘道器與微服務閘道器合二為一，使用者資源成本直降50%

在虛擬化時期的微服務架構下，業務通常採用流量閘道器 + 微服務閘道器的兩層架構，流量閘道器負責南北向流量排程和安全防護，微服務閘道器負責東西向流量排程和服務治理，而在容器和 K8s 主導的雲原生時代，Ingress 成為 K8s 生態的閘道器標準，賦予了閘道器新的使命，使得流量閘道器 + 微服務閘道器合二為一成為可能。

此次阿里雲 MSE 釋出的雲原生閘道器在能力不打折的情況下，將兩層閘道器變為一層，不僅可以節省50%的資源成本，還可以降低運維及使用成本。部署結構示意圖如下，左邊為傳統閘道器模式，右圖為下一代雲原生閘道器模式。

在微服務的大背景下，豐富的可觀測能力也是使用者的基礎核心訴求，雲原生閘道器基於此預設整合了阿里雲應用實時監控服務ARMS，提供豐富的可觀測資料，且該功能對使用者免費。

更安全：提供豐富的認證鑑權能力，降低客戶的安全接入成本

認證鑑權是客戶對閘道器的剛需，MSE 雲原生閘道器不僅提供常規的 JWT 認證，也提供基於授權開放網路標準 OAuth 2.0 的 OIDC 認證。同時，MSE 雲原生閘道器天然支援阿里雲的應用身份服務 IDaaS，幫助客戶實現支付寶、淘寶、天貓等的三方認證登入，並以外掛的方式支援來擴充套件認證鑑權功能，以降低客戶的安全接入成本。現有認證鑑權功能如下圖：

更統一：閘道器直連後端服務，打通 Nacos/Eureka/K8s 多種服務來源，並且率先支援 Apache Dubbo3.0 協議

開源已經成為推動軟體發展的源動力之一，面向社群標準、開放的商業產品更有生命力。

Envoy 是最受 K8s 社群歡迎的 Ingress 實現之一，正成為雲原生時代流量入口的標準技術方案。MSE 雲原生閘道器依託於 Envoy 和 Istio 進行構建，實現了統一的控制面管控，並直連後端服務，支援了 Dubbo3.0、Nacos，打通阿里雲容器服務ACK，自動同步服務註冊資訊。MSE 雲原生閘道器對 Dubbo 3.0 與 Nacos 的支援，已經率先在釘釘業務中上線，下圖是釘釘 Dubbo 3.0 落地的部署簡圖如下：