*作者：澄潭*

## 雲原生閘道器介紹

MSE 雲原生閘道器是阿里雲提供的下一代閘道器解決方案，完全相容 Kubernetes Ingress 標準 API，將流量閘道器、微服務閘道器和安全閘道器三合一，解決了多層閘道器架構獨立設計、獨立運維導致的資源消耗大、效能損耗大、穩定性難控、安全防護複雜等難題。相比傳統閘道器，雲原生閘道器在資源成本、效能、安全性和易用性上更有優勢。

![1.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cd1e46365a9d43aab062af0de7bfcb28~tplv-k3u1fbpfcp-zoom-1.image "1.jpeg")

傳統多層閘道器架構

在這個架構中，用 WAF 閘道器實現安全能力，SLB 實現負載均衡能力，Ingress 閘道器實現叢集入口閘道器能力（非 K8s 場景也會部署一層 Nginx），Zuul 實現微服務閘道器能力。這樣的架構需要對每一層閘道器都進行容量評估，每一層閘道器都是潛在的瓶頸點，都可能需要進行擴容。這樣造成的資源成本和運維人力成本都是巨大的。並且每多一層閘道器，就多一層可用性風險。

![2.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/04d19a72d3044f4fb387c2045081c60e~tplv-k3u1fbpfcp-zoom-1.image "2.jpeg")

MSE 雲原生閘道器架構

使用 MSE 雲原生閘道器，在保留 SLB 作負載均衡的基礎上，只透過一層閘道器就實現了叢集入口閘道器、WAF 閘道器、微服務閘道器的全部能力。並且這一層閘道器由阿里雲託管部署，無需使用者自己運維機器例項，並且提供閘道器可用性的 SLA 保障。除了大幅度降低人力成本、資源成本，還能提供更好的穩定性。

## EDAS 場景的 Quick Start 示例

雲原生閘道器支援多種服務發現機制，包括 K8s Service/MSE Nacos/MSE Zookeeper/EDAS 註冊中心等。在 EDAS 場景下，微服務空間的註冊中心，不論指定為 MSE Nacos 或者 EDAS 註冊中心，雲原生閘道器均可以發現 EDAS 上部署的服務，並建立路由進行轉發。下面以使用 EDAS 註冊中心為例，說明如何快速上手雲原生閘道器。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9e9b4fab67264c1fb0fc95b9aec8a213~tplv-k3u1fbpfcp-zoom-1.image "3.png")

### Step 1. 購買建立雲原生閘道器

> 購買連結：

> <https:>

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/680127ce36a94b91832c506cf453c613~tplv-k3u1fbpfcp-zoom-1.image "4.png")

請注意 VPC 專有網路需要與 EDAS 中服務例項部署所在的 VPC 一致

### Step 2.  建立服務來源

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/db37947f1159480096c2bc9ff6c8a54c~tplv-k3u1fbpfcp-zoom-1.image "5.png")

在服務管理一欄的來源管理中，建立服務來源，以部署在 Default 微服務空間下的 EDAS 應用為例，此處選擇對應的微服務空間即可。DEFAULT_GROUP 為 EDAS 註冊中心預設的服務分組，若應用配置使用了dubbo.registry.group、spring.cloud.nacos.discovery.group 等指定了服務分組時，需要額外新增對應的服務分組。

每個 EDAS 微服務空間對應一個服務來源，此處可以建立多個服務來源，各自對應不同的微服務空間。

### Step 3.  建立服務

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/de7f1c1f1d444551ab72d1ce5e09f149~tplv-k3u1fbpfcp-zoom-1.image "6.png")

可以一鍵匯入指定微服務空間下的所有服務

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fb815b70e5574775b586ffe1c22609e7~tplv-k3u1fbpfcp-zoom-1.image "7.png")

匯入後可以看到每個服務對應的後端例項 IP，這表明服務發現已經 OK；健康檢查狀態說明閘道器到這些服務例項 IP 的網路聯通性也是 OK 的。

### Step 4.  建立路由

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3a50cd9194d7470f9c0325ac717b9120~tplv-k3u1fbpfcp-zoom-1.image "8.png")

先填寫路由匹配規則，可以分別針對 HTTP 路徑/方法/請求頭/請求引數配置匹配規則

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d5bac1cf7d6b4aafb7d722e5e7fbf6ab~tplv-k3u1fbpfcp-zoom-1.image "9.png")

點選下一步，選擇目標服務進行路由，下拉選單可以看到 Step 3 中匯入的 EDAS 服務。點選儲存並上線，這條路由將立即生效。

## 作為全鏈路灰度的入口閘道器

利用 EDAS 成熟的微服務治理能力，配合雲原生閘道器，可以輕鬆利用多套邏輯環境實現全鏈路灰度。EDAS 實現了基於位元組碼增強技術在編譯時對開發框架進行功能擴充，這種方案業務無感知，不需要修改任何一行業務程式碼，即可擁有全鏈路灰度的治理能力，並且支援近 5 年內所有的 Spring Boot、Spring Cloud 和 Dubbo。實現架構如下圖所示：

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f9b0bd1b55c3486980f6645a23f17b8d~tplv-k3u1fbpfcp-zoom-1.image "10.png")

用不同的顏色來表示不同版本的灰度流量，可以看出無論是入口微服務閘道器還是微服務本身都需要識別流量，根據治理規則做出動態決策。當服務版本發生變化時，這個呼叫鏈路的轉發也會實時改變。相比於利用機器搭建物理灰度環境，這種方案不僅可以節省大量的機器成本和運維人力，而且可以幫助開發者實時快速的對線上流量進行精細化的全鏈路控制。

下面以 SpringCloud 應用為例，演示如何在 EDAS 上，搭配雲原生閘道器，實現全鏈路灰度。

### Step 1. 部署服務

假設應用的架構由MSE雲原生閘道器以及後端的微服務架構（Spring Cloud）組成，後端呼叫鏈路有 3 個：購物車（sc-A），交易中心（sc-B），庫存中心（sc-C），可以透過客戶端或者是 HTML 來訪問後端服務，這些服務之間透過 EDAS 註冊中心實現服務發現，呼叫鏈路為：sc-A -> sc-B -> sc-C。

> 可以透過映象的方式部署這三個服務，三個服務的映象地址分別是：
> 
> sc-A：
> 
> msecrinstance-registry.cn-hangzhou.cr.aliyuncs.com/mse-demo/spring-cloud-a:0.1
> 
> sc-B：
> 
> msecrinstance-registry.cn-hangzhou.cr.aliyuncs.com/mse-demo/spring-cloud-b:0.1
> 
> sc-C：
> 
> msecrinstance-registry.cn-hangzhou.cr.aliyuncs.com/mse-demo/spring-cloud-c:0.1

是用自定義映象方式部署：

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ceb75a35da874024b72e46a8a713a9e6~tplv-k3u1fbpfcp-zoom-1.image "11.png")

-   **sc-A 服務**

服務 A 是需要暴露給閘道器，閘道器會透過註冊中心的後設資料資訊中獲取服務的版本資訊，所以這裡透過環境變數的方式分別設定。

> 為基線版本設定應用配置：
> 
> spring.cloud.nacos.discovery.metadata.version=base
> 
> 為灰度版本設定：
> 
> spring.cloud.nacos.discovery.metadata.version=gray

同時在灰度版本的 pod annotations 中設定 alicloud.service.tag: gray，用於 Java Agent 區分當前服務所在的邏輯環境。

基線版本部署配置：

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bdb986d846d24033a4dc45fba19b2be4~tplv-k3u1fbpfcp-zoom-1.image "12.png")

灰度版本部署配置：

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/155f3833b6dc413795f2cf80c334b4e3~tplv-k3u1fbpfcp-zoom-1.image "13.png")

-   **sc-B 服務/sc-C 服務**

這兩個服務無需暴露給閘道器，除了映象地址配置不同外，其餘部署配置一樣。只需在灰度版本的 pod annotations 中設定 alicloud.service.tag: gray，用於 Java Agent 區分當前服務所在的邏輯環境。

基線版本部署配置：

無需任何配置

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/86afa04cdbdd46789db1ce8571b76347~tplv-k3u1fbpfcp-zoom-1.image "14.png")

灰度版本部署配置：

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6d95dbcd8dd94506a3db13b16866d4f4~tplv-k3u1fbpfcp-zoom-1.image "15.png")

### Step 2. 在雲原生閘道器建立服務

前置步驟需要建立服務來源，在 Quick Start 中已經給出說明，此處不再贅述，直接到建立服務這步，匯入 sc-A 這個服務。

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8676846a14834a758f00448177a1fdf4~tplv-k3u1fbpfcp-zoom-1.image "16.png")

匯入成功後點選服務名稱，進入服務策略配置，設定對應的服務版本。定義兩個版本 base 和 gray，基於服務註冊後設資料資訊中的 version 標籤值進行區分（ Step 1 中透過 spring.cloud.nacos.discovery.metadata.version 配置）

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/26fe37a0a31642d2a407fdf61c573240~tplv-k3u1fbpfcp-zoom-1.image "17.png")

### Step 3. 在雲原生閘道器建立路由

首先建立兩個不同的域名，用於區分基線環境和灰度環境：

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/52fb22d5e6054a1b9235809bbd1c318a~tplv-k3u1fbpfcp-zoom-1.image "18.png")

分別建立兩條路由：

![19.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1a883977f3c34555b46a2793c469c804~tplv-k3u1fbpfcp-zoom-1.image "19.png")

精確匹配路徑/a 轉發給 sc-A 服務，透過標籤路由的方式，將 gray.example.com/a 轉發給 sc-A 服務的 gray 版本；將 base.example.com/a 轉發給 sc-A 服務的 base 版本。以前者為例，配置方式如下：

指定路由匹配/方式：

![20.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b1f2a5e17ed842949554f2553fdce5c2~tplv-k3u1fbpfcp-zoom-1.image "20.png")

選擇目標服務為標籤路由，配置路由到 sc-A 服務的特定版本：

![21.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/52fa77b2428f440e8ca80440847c6949~tplv-k3u1fbpfcp-zoom-1.image "21.png")

點選 gray 路由名稱，對於這條灰度環境路由，透過設定請求頭的方式，進行環境標籤的設定，該請求頭起到流量染色的作用，會在後續服務呼叫鏈上一路透傳，Java Agent 會根據該請求頭選擇對應環境的服務

![22.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0af54677857740e9ab396c07f730e884~tplv-k3u1fbpfcp-zoom-1.image "22.png")

### Step 4. 驗證全鏈路灰度效果

路由配置完成後，實現瞭如下環境隔離的效果（本例中透過域名區分不同環境，還可以透過不同的路由匹配規則，實現基於 header、url 引數等區分不同環境）：

![23.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cd7f7f4d58ad4c268ef32ff406868b28~tplv-k3u1fbpfcp-zoom-1.image "23.png")

-   訪問 base.example.com 路由到基線（base）環境

-   -   curl 命令

```
curl -H "Host: base.example.com" http://118.31.XX.XX/a
```

-   -   執行結果

```
A[10.66.3.133] -> B[10.66.0.113] -> C[10.66.3.132]
```

-   訪問 gray.example.com 路由到灰度（gray）環境

-   -   curl 命令

```
curl -H "Host: gray.example.com" http://118.31.XX.XX/a
```

-   -   執行結果

```
Agray[10.66.2.3] -> Bgray[10.66.2.69] -> Cgray[10.66.2.195]
```

-   如果入口應用 A 沒有灰度（gray）環境，訪問到 A 的基線（base）環境，又需要在 A->B 的時候進入灰度環境，則可以透過增加一個特殊的 Header：x-mse-tag 來實現，Header 的值是流量走向的環境的標籤，例如 gray。

-   -   curl 命令

```
curl -H "Host: base.example.com" -H "x-mse-tag: gray" http://118.31.XX.XX/a
```

-   -   執行結果

```
A[10.66.3.133] -> Bgray[10.66.2.69] -> Cgray[10.66.2.195]
```</https:>

EDAS 流量入口閘道器最佳實踐

相關文章