*作者：十眠*

*稽核&校對：望陶、亦盞*

*編輯&排版：雯燕*

今年雙 11，雲原生中介軟體完成了開源、自研、商業化三位一體，全面升級到中介軟體雲產品。MSE 微服務治理透過 Dubbo3.0 支撐了阿里集團核心業務雙 11 的流量洪峰，截止目前集團內 50% 的使用者已經習慣使用 MSE 微服務治理 HSF 和 Dubbo3.0 應用，今天我們來細聊一下 MSE 服務治理專業版中的全鏈路灰度能力，以及它在生產大規模實踐的一些場景。

# 背景

微服務架構下，有一些需求開發，涉及到微服務呼叫鏈路上的多個微服務同時發生了改動，需要透過灰度釋出方式來更好地控制新版本服務上線的風險和爆炸半徑。通常每個微服務都會有灰度環境或分組來接受灰度流量，我們希望透過進入上游灰度環境的流量，也能進入下游灰度的環境中，確保 1 個請求始終在灰度環境中傳遞，即使這個呼叫鏈路上有一些微服務沒有灰度環境，這些應用請求下游的時候依然能夠回到灰度環境中。透過 MSE 提供的全鏈路灰度能力，可以在不需要修改任何您的業務程式碼的情況下，能夠輕鬆實現上述能力。

# MSE 微服務治理全鏈路灰度特點

全鏈路灰度作為 MSE 服務治理專業版中的拳頭功能，具備以下六大特點

- 可透過定製規則引入精細化流量

除了簡單地按照比例進行流量引入外，我們還支援 Spring Cloud 與 Dubbo 流量按規則引入，Spring Cloud 流量可根據請求的 cookie、header、param 引數或隨機百分比引入流量，Dubbo 流量可按照服務、方法、引數來引入。

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

- 全鏈路隔離流量泳道

1) 透過設定流量規則對所需流量進行“染色”，“染色”流量會路由到灰度機器。

2) 灰度流量攜帶灰度標往下游傳遞，形成灰度專屬環境流量泳道，無灰度環境應用會預設選擇未打標的基線環境。

- 端到端的穩定基線環境

未打標的應用屬於基線穩定版本的應用，即穩定的線上環境。當我們將釋出對應的灰度版本程式碼，然後可以配置規則定向引入特定的線上流量，控制灰度程式碼的風險。

- 流量一鍵動態切流

流量規則定製後，可根據需求進行一鍵停啟，增刪改查，實時生效。灰度引流更便捷。

- 低成本接入，基於 Java Agent 技術實現無需修改一行業務程式碼

MSE 微服務治理能力基於 Java Agent 位元組碼增強的技術實現，無縫支援市面上近 5 年的所有 Spring Cloud 和 Dubbo 的版本，使用者不用改一行程式碼就可以使用，不需要改變業務的現有架構，隨時可上可下，沒有繫結。只需開啟 MSE 微服務治理專業版，線上配置，實時生效。

- 具備無損上下線能力，使得釋出更加絲滑

應用開啟 MSE 微服務治理後就具備無損上下線能力，大流量下的釋出、回滾、擴容、縮容等場景，均能保證流量無損。

# 大規模生產實踐的場景

本文主要介紹 MSE 微服務治理在支援大客戶過程中總結抽象出來的常用的幾個全鏈路灰度方案生產落地實踐的場景。

### 場景一：對經過機器的流量進行自動染色，實現全鏈路灰度

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

- 進入帶 tag 的節點後續呼叫優先選擇帶有相同 tag 的節點，即對經過 tag 節點的流量進行“染色”。

- 有 tag 的呼叫鏈路上找不到相同 tag 的節點，則 fallback 到無 tag 的節點。

- 有 tag 的呼叫鏈路經過無 tag 的節點，如果鏈路後續呼叫有 tag 的節點，則恢復 tag 呼叫的模式。

### 場景二：透過給流量帶上特定的 header 實現全鏈路灰度

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

客戶端透過在請求中增加制定環境的標識，接入層根據表示進行轉發至表示對應環境的閘道器，對應環境的閘道器透過隔離外掛呼叫標識對應的專案隔離環境，請求在業務專案隔離環境中閉環。

### 場景三：透過自定義路由規則來進行全鏈路灰度

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

透過在灰度請求中增加指定的 header，且整條呼叫鏈路會將該 header 透傳下去，只需在對應的應用配置該 header 相關的路由規則，帶指定 header 的灰度請求進入灰度機器，即可按需實現全鏈路流量灰度。

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

# 全鏈路灰度的實踐

我們如何快速獲得上述同款全鏈路灰度的能力呢？下面我會帶大家從 0 到 1 快速搭建我們的全鏈路灰度能力。

我們假設應用的架構由 Ingress-nginx 以及後端的微服務架構（Spring Cloud）來組成，後端呼叫鏈路有 3 跳，購物車（a），交易中心（b），庫存中心（c），他們透過 Nacos 註冊中心做服務發現，客戶端透過客戶端或者是 H5 頁面來訪問後端服務。

### 前提條件

#### 安裝 Ingress-nginx 元件

訪問容器服務控制檯，開啟應用目錄，搜尋 ack-ingress-nginx ，選擇名稱空間 kube-system，點選建立，安裝完成後，在 kube-system 名稱空間中會看到一個 deployment ack-ingress-nginx-default-controller ，表明安裝成功。

```
$ kubectl get deployment -n kube-system
NAME                                      READY   UP-TO-DATE   AVAILABLE   AGE
ack-ingress-nginx-default-controller      2/2     2            2           18h
```

#### 開啟 MSE 微服務治理專業版

- 點選開通 MSE 微服務治理專業版 以使用全鏈路灰度能力。

- 訪問容器服務控制檯，開啟應用目錄，搜尋 ack-mse-pilot ，點選建立。

- 在 MSE 服務治理控制檯，開啟 K8s 叢集列表，選擇對應叢集，對應名稱空間，並開啟微服務治理。

#### 部署 Demo 應用程式

將下面的檔案儲存到 ingress-gray.yaml 中，並執行 kubectl apply -f ingress-gray.yaml 以部署應用，這裡我們將要部署 A, B, C 三個應用，每個應用分別部署一個基線版本和一個灰度版本。

```
# A 應用 base 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-a
  name: spring-cloud-a
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      annotations:
        msePilotCreateAppName: spring-cloud-a
      labels:
        app: spring-cloud-a
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:0.1-SNAPSHOT
        imagePullPolicy: Always
        name: spring-cloud-a
        ports:
        - containerPort: 20001
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 10
          periodSeconds: 30
      
# A 應用 gray 版本
---            
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-a-new
  name: spring-cloud-a-new
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-a-new
  strategy:
  template:
    metadata:
      annotations:
        alicloud.service.tag: gray
        msePilotCreateAppName: spring-cloud-a
      labels:
        app: spring-cloud-a-new
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        - name: profiler.micro.service.tag.trace.enable
          value: "true"
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:0.1-SNAPSHOT
        imagePullPolicy: Always
        name: spring-cloud-a-new
        ports:
        - containerPort: 20001
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 10
          periodSeconds: 30
            
# B 應用 base 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-b
  name: spring-cloud-b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-b
  strategy:
  template:
    metadata:
      annotations:
        msePilotCreateAppName: spring-cloud-b
      labels:
        app: spring-cloud-b
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-b:0.1-SNAPSHOT
        imagePullPolicy: Always
        name: spring-cloud-b
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 10
          periodSeconds: 30
            
# B 應用 gray 版本  
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-b-new
  name: spring-cloud-b-new
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-b-new
  template:
    metadata:
      annotations:
        alicloud.service.tag: gray
        msePilotCreateAppName: spring-cloud-b
      labels:
        app: spring-cloud-b-new
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-b:0.1-SNAPSHOT
        imagePullPolicy: Always
        name: spring-cloud-b-new
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 10
          periodSeconds: 30
            
# C 應用 base 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-c
  name: spring-cloud-c
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      annotations:
        msePilotCreateAppName: spring-cloud-c
      labels:
        app: spring-cloud-c
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:0.1-SNAPSHOT
        imagePullPolicy: Always
        name: spring-cloud-c
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 10
          periodSeconds: 30
            
# C 應用 gray 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-c-new
  name: spring-cloud-c-new
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-c-new
  template:
    metadata:
      annotations:
        alicloud.service.tag: gray
        msePilotCreateAppName: spring-cloud-c
      labels:
        app: spring-cloud-c-new
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:0.1-SNAPSHOT
        imagePullPolicy: IfNotPresent
        name: spring-cloud-c-new
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 10
          periodSeconds: 30

# Nacos Server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nacos-server
  name: nacos-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nacos-server
  template:
    metadata:
      labels:
        app: nacos-server
    spec:
      containers:
      - env:
        - name: MODE
          value: standalone
        image: nacos/nacos-server:latest
        imagePullPolicy: Always
        name: nacos-server
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
      dnsPolicy: ClusterFirst
      restartPolicy: Always

# Nacos Server Service 配置
---
apiVersion: v1
kind: Service
metadata:
  name: nacos-server
spec:
  ports:
  - port: 8848
    protocol: TCP
    targetPort: 8848
  selector:
    app: nacos-server
  type: ClusterIP
```

### 動手實踐

#### 場景一：對經過機器的流量進行自動染色，實現全鏈路灰度

有時候，我們可以透過不同的域名來區分線上基線環境和灰度環境，灰度環境有單獨的域名可以配置，假設我們透過訪問 www.gray.com 來請求灰度環境，訪問 www.base.com 走基線環境。

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

呼叫鏈路 Ingress-nginx -> A -> B -> C ，其中 A 可以是一個 spring-boot 的應用。

注意：入口應用 A 的 gray 和 A 的 base 環境，需要在 MSE 服務治理控制檯開啟 A 應用的按照流量比例透傳開關，表示開啟向後透傳當前環境的標籤的功能。這樣， 當 Ingress-nginx 路由 A 的 gray 之後，即使請求中沒有攜帶任何 header，因為開啟了此開關，所以往後呼叫的時候會自動新增 x-mse-tag:gray 這個 header，其中的 header的值 gray 來自於 A 應用配置的標籤資訊。如果原來的請求中帶有 x-mse-tag:gray則會以原來請求中的標籤優先。

針對入口應用 A ，配置兩個 k8s service, spring-cloud-a-base 對應 A 的 base 版本，spring-cloud-a-gray 對應 A 的 gray 版本。

```
apiVersion: v1
kind: Service
metadata:
  name: spring-cloud-a-base
spec:
  ports:
    - name: http
      port: 20001
      protocol: TCP
      targetPort: 20001
  selector:
    app: spring-cloud-a

---
apiVersion: v1
kind: Service
metadata:
  name: spring-cloud-a-gray
spec:
  ports:
    - name: http
      port: 20001
      protocol: TCP
      targetPort: 20001
  selector:
    app: spring-cloud-a-new
```

配置入口的 Ingress 規則，訪問 www.base.com 路由到 A 應用的 base 版本，訪問 www.gray.com 路由到 A 應用的 gray 版本。

```
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base
spec:
  rules:
  - host: www.base.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-base
          servicePort: 20001
        path: /

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-gray
spec:
  rules:
  - host: www.gray.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-gray
          servicePort: 20001
        path: /

```

##### 結果驗證

此時，訪問 www.base.com 路由到 基線環境

```
curl -H"Host:www.base.com" http://106.14.155.223/a
A[172.18.144.155] -> B[172.18.144.120] -> C[172.18.144.79]

```

此時，訪問 www.gray.com 路由到灰度環境

```
curl -H"Host:www.gray.com" http://106.14.155.223/a
Agray[172.18.144.160] -> Bgray[172.18.144.57] -> Cgray[172.18.144.157]
```

進一步的，如果入口應用 A 沒有灰度環境，訪問到 A 的 base 環境，又需要在 A -> B 的時候進入灰度環境，則可以透過增加一個特殊的 header x-mse-tag 來實現，header 的值是想要去的環境的標籤，例如 gray。

```
curl -H"Host:www.base.com"  -H"x-mse-tag:gray" http://106.14.155.223/a
A[172.18.144.155] -> Bgray[172.18.144.139] -> Cgray[172.18.144.8]
```

可以看到第一跳，進入了 A 的 base 環境，但是 A->B 的時候又重新回到了灰度環境。

這種使用方式的好處是，配置簡單，只需要在 Ingress 處配置好規則，某個應用需要灰度釋出的時候，只需要在灰度環境中部署好應用，灰度流量自然會進入到灰度機器中，如果驗證沒問題，則將灰度的映象釋出到基線環境中；如果一次變更有多個應用需要灰度釋出，則把他們都加入到灰度環境中即可。

##### 最佳實踐

- 給所有灰度環境的應用打上 gray 標，基線環境的應用預設不打標。

- 線上常態化引流 2% 的流量進去灰度環境中

#### 場景二：透過給流量帶上特定的 header 實現全鏈路灰度

有些客戶端沒法改寫域名，希望能訪問 www.demo.com 透過傳入不同的 header 來路由到灰度環境。例如下圖中，透過新增 x-mse-tag:gray 這個 header，來訪問灰度環境。

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

這個時候 demo 的Ingress 規則如下，注意這裡增加了 nginx.ingress.kubernetes.io/canary 相關的多條規則

```
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base
spec:
  rules:
  - host: www.demo.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-base
          servicePort: 20001
        path: /
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-gray
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "x-mse-tag"
    nginx.ingress.kubernetes.io/canary-by-header-value: "gray"
    nginx.ingress.kubernetes.io/canary-weight: "0"
spec:
  rules:
  - host: www.base.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-gray
          servicePort: 20001
        path: /
```

##### 結果驗證

此時，訪問 www.demo.com 路由到基線環境

```
curl -H"Host:www.demo.com" http://106.14.155.223/a
A[172.18.144.155] -> B[172.18.144.56] -> C[172.18.144.156]
```

如何訪問灰度環境呢？只需要在請求中增加一個header x-mse-tag:gray 即可。

```
curl -H"Host:www.demo.com"  -H"x-mse-tag:gray" http://106.14.155.223/a
Agray[172.18.144.82] -> Bgray[172.18.144.57] -> Cgray[172.18.144.8]
```

可以看到 Ingress 根據這個header直接路由到了 A 的 gray 環境中。

##### 更進一步

還可以藉助 Ingress 實現更復雜的路由，比如客戶端已經帶上了某個header，想要利用現成的 header來實現路由，而不用新增一個 header，例如下圖所示，假設我們想要 x-user-id 為 100 的請求進入灰度環境。

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

只需要增加下面這 4 條規則:

```
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base
spec:
  rules:
  - host: www.demo.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-base
          servicePort: 20001
        path: /
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base-gray
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
    nginx.ingress.kubernetes.io/canary-by-header-value: "100"
    nginx.ingress.kubernetes.io/canary-weight: "0"
spec:
  rules:
  - host: www.demo.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-gray
          servicePort: 20001
        path: /
```

訪問的時候帶上特殊的 header ，滿足條件進入灰度環境

```
curl -H"Host:www.demo.com"  -H"x-user-id:100" http://106.14.155.223/a
Agray[172.18.144.93] -> Bgray[172.18.144.24] -> Cgray[172.18.144.25]
```

不滿足條件的請求，進入基線環境:

```
curl -H"Host:www.demo.com"  -H"x-user-id:101" http://106.14.155.223/a
A[172.18.144.91] -> B[172.18.144.22] -> C[172.18.144.95]
```

相比場景一這樣的好處是，客戶端的域名不變，只需要透過請求來區分。

#### 場景三：透過自定義路由規則來進行全鏈路灰度

有時候我們不想要自動透傳且自動路由，而是希望微服務呼叫鏈上下游上的每個應用能自定義灰度規則，例如 B 應用希望控制只有滿足自定義規則的請求才會路由到 B 應用這裡，而 C 應用有可能希望定義和 B 不同的灰度規則，這時應該如何配置呢，場景參見如下圖：

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

注意，最好把場景一和二中配置的引數清除掉。

第一步，需要在入口應用 A 處（最好是所有的入口應用都增加該環境變數，包括 gray 和 base） 增加一個環境變數：alicloud.service.header=x-user-id，x-user-id 是需要透傳的 header，它的作用是識別該 header 並做自動透傳。

注意這裡不要使用 x-mse-tag, 它是系統預設的一個 header，有特殊的邏輯。

第二步，在中間的 B 應用處，在 MSE 控制檯配置標籤路由規則

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

第三步，在 Ingress 處配置路由規則，這一步參考場景二，並採用如下配置：

```
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base
spec:
  rules:
  - host: www.base.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-base
          servicePort: 20001
        path: /
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: 'true'
    nginx.ingress.kubernetes.io/canary-by-header: x-user-id
    nginx.ingress.kubernetes.io/canary-by-header-value: '100'
    nginx.ingress.kubernetes.io/canary-weight: '0'
  name: spring-cloud-a-gray
spec:
  rules:
    - host: www.base.com
      http:
        paths:
          - backend:
              serviceName: spring-cloud-a-gray
              servicePort: 20001
            path: /
```

##### 結果驗證

測試驗證，訪問灰度環境，帶上滿足條件的 header，路由到 B 的灰度環境中。

```
curl 120.77.215.62/a -H "Host: www.base.com" -H "x-user-id: 100" 
Agray[192.168.86.42] -> Bgray[192.168.74.4] -> C[192.168.86.33]
```

訪問灰度環境，帶上不滿足條件的 header，路由到 B 的base環境中。

```
curl 120.77.215.62/a -H "Host: www.base.com" -H "x-user-id: 101" 
A[192.168.86.35] -> B[192.168.73.249] -> C[192.168.86.33]
```

去掉 Ingress Canary 配置，訪問 base A 服務（基線環境入口應用需要加上 alicloud.service.header 環境變數），帶上滿足條件的 header，路由到 B 的灰度環境中。

```
curl 120.77.215.62/a -H "Host: www.base.com" -H "x-user-id: 100" 
A[192.168.86.35] -> Bgray[192.168.74.4] -> C[192.168.86.33]
```

訪問 base 環境，帶上不滿足條件的 header，路由到 B 的 base 環境中。

```
curl 120.77.215.62/a -H "Host: www.base.com" -H "x-user-id: 101" 
A[192.168.86.35] -> B[192.168.73.249] -> C[192.168.86.33]
```

# 總結

20 分鐘快速實踐完具有很大技術難度的全鏈路灰度能力，全鏈路灰度其實並不是那麼難！

基於 MSE 服務治理的全鏈路灰度能力，我們可以快速落地企業級的全鏈路灰度能力，以上三種場景是我們在生產實踐中大規模落地的標準場景，當然我們可以基於 MSE 服務治理的能力根據自己的業務個性化定製與適配；即使在多種流量來源的背景下，也能做到按照業務定製精準引流。

同時 MSE 服務治理專業版的可觀測效能力使得灰度有效性得到可衡量，灰沒灰到，灰得咋樣，做到“心裡有數”。

#### 灰度流量秒級監控

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

# 規範釋出流程

日常釋出中，我們常常會有如下一些錯誤的想法：

- 這次改動的內容比較小，而且上線要求比較急，就不需要測試直接釋出上線好了。

- 釋出不需要走灰度流程，快速釋出上線即可。

- 灰度釋出沒有什麼用，就是一個流程而已，釋出完就直接釋出線上，不用等待觀察。

- 雖然灰度釋出很重要，但是灰度環境很難搭建，耗時耗力 優先順序並不高。

這些想法都可能讓我們進行一次錯誤的釋出，不少故障是因為釋出直接或間接引起。因此提升釋出的質量，減少錯誤的發生，是有效減少線上故障的一個關鍵環節。做到安全的釋出，我們需要規範釋出的流程。

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

# 尾

隨著微服務的流行，越來越多公司使用了微服務框架，微服務以其高內聚、低耦合等特性，提供了更好的容錯性，也更適應業務的快速迭代，為開發人員帶來了很多的便利性。但是隨著業務的發展，微服務拆分越來越複雜，微服務的治理也成了一個比較令人頭疼的問題。

單單拿全鏈路灰度來看，為了保證應用新版本上線前的功能正確性的驗證同時需要兼顧應用釋出的效率，如果我們應用的規模很小，我們可以直接透過維護多套環境來保證釋出的正確性。但是當我們的業務發展到龐大且複雜程度時，假設我們的系統由 100 個微服務構成，即使測試/灰度環境每個服務佔用 1 到 2 個 pod，那麼多套環境下來我們需要面臨巨大的成本與運維環境帶來的效率的挑戰。

有沒有更加簡單且高效的方法來解決微服務治理的難題？

MSE 微服務引擎將推出服務治理專業版，提供開箱即用且完整專業的微服務治理解決方案，幫助企業更好地實現微服務治理能力。如果您的系統也可以像本文描述的那樣，快速具備完整的全鏈路灰度能力，並基於該能力進行進一步的微服務治理實踐，不僅可以節省客觀的人力與成本，還可以讓您的企業在微服務領域的探索更加有底氣。

瞭解更多相關資訊，請掃描下方二維碼或搜尋微訊號（AlibabaCloud888）新增雲原生小助手！獲取更多相關資訊！
![二維碼.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/998d601fffad421e90dfa4e1fa743461~tplv-k3u1fbpfcp-zoom-1.image)

如何用20分鐘就能獲得同款企業級全鏈路灰度能力？

相關文章