*作者：十眠*

流量路由，顧名思義就是將具有某些屬性特徵的流量，路由到指定的目標。流量路由是流量治理中重要的一環，多個路由如同流水線一樣，形成一條路由鏈，從所有的地址表中篩選出最終目的地址集合，再透過負載均衡策略選擇訪問的地址。開發者可以基於流量路由標準來實現各種場景，如灰度釋出、金絲雀釋出、容災路由、標籤路由等。

直播課程觀看：

<https:>

## 微服務治理與 OpenSergo

隨著微服務(MicroServices) 理念的興起，讓大規模、高併發、低延遲的分散式應用成為可能。但是微服務架構是一把雙刃劍，隨著微服務架構複雜化，在大規模之下，再小的問題都會牽一髮而動全身，因此隨著微服務架構增長，如果不對微服務進行恰當的治理，微服務架構帶來的效率、穩定性問題很可能會遠大於微服務本身帶來的架構紅利。可以說，現代微服務架構的四 大件：服務提供者、服務消費者、註冊配置中心，當然還有容易被大家忽視但又十分重要的一點，那就是微服務治理。微服務治理的使命就是對微服務體系中的各個元件與環節進行治理，可以說做好微服務治理那就是把微服務做穩做好的必不可少的一環。

在企業內部，往往存在著不同語言、不同通訊協議的微服務，這種異構化的架構會導致治理微服務的過程中，業務開發者、架構師無法用統一的方式來對所有服務進行治理管控，並且這類異構會衍生出更多的痛點：

-   業內對服務治理的能力和邊界沒有明確的認識，每個企業所定義的服務治理概念不一致，造成很高的理解和溝通成本。

-   開源微服務框架眾多，對於服務治理缺乏一些標準化的約定。例如，Spring Cloud 中定義的微服務介面和 Dubbo 中定義的介面就沒有辦法互通，透過 Dubbo 和 Istio 管理的微服務也沒有辦法進行統一治理。開發者無法透過統一的配置方式來對不同框架、不同語言的服務進行統一治理管控。

-   缺少真正面向業務、能夠減輕認知負擔的抽象和標準。開發者真正想要的可能是簡單的、指定服務間的呼叫關係和配置規則。但現在對於業務開發者來說，不僅需要了解不同微服務框架的部署架構，也要了解不同服務治理方式的概念和能力區別，認知成本很大。

基於上面這些痛點，阿里巴巴在 2022 年 1 月開始和 bilibili、CloudWego 等廠商、社群討論服務治理如何規範化和更加普及，從而共同發起了 OpenSergo 專案。

OpenSergo 是開放通用的，覆蓋微服務及上下游關聯元件的微服務治理專案，從微服務的角度出發，涵蓋流量治理、服務容錯、服務元資訊治理、安全治理等關鍵治理領域，提供一系列的治理能力與標準、生態適配與最佳實踐，支援 Java, Go, Rust 等多語言生態。OpenSergo 的最大特點就是**以統一的一套配置/DSL/協議定義服務治理規則，面向多語言異構化架構，做到全鏈路生態覆蓋**。對於開發者來說可以透過同一套 OpenSergo CRD 標準配置針對微服務架構涉及到的每一個元件進行統一的治理管控，而無需關注各框架、語言的差異點，降低異構化、全鏈路服務治理管控的複雜度。

下面我們將從流量路由這個場景入手，從常見的微服務治理場景出發。先是根據流量路由的實踐設計流量路由的 Spec，同時在 Spring Cloud Alibaba 中實踐遵循 OpenSergo 標準的流量路由能力。

## 流量路由

流量路由，顧名思義就是將具有某些屬性特徵的流量，路由到指定的目標。流量路由是流量治理中重要的一環，我們可以基於流量路由標準來實現各種場景，如全鏈路灰度、標籤路由、金絲雀釋出等。

### 標籤路由

標籤路由是按照標籤為維度對目標負載進行劃分，符合條件的流量匹配至對應的目標，從而實現標籤路由的能力。當然基於標籤路由的能力，賦予標籤各種含義我們就可以實現各種流量路由的場景化能力。

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

### 金絲雀釋出

金絲雀釋出是一種降低在生產中引入新軟體版本的風險的技術，方法是在將更改推廣到整個基礎架構並使其可供所有人使用之前，緩慢地將更改推廣到一小部分使用者。金絲雀釋出是一種在黑與白之間，能夠平滑過渡的一種釋出方式。讓一部分使用者繼續用舊版本，一部分使用者開始用新版本，如果使用者對新版本沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到新版本上面來。一直都有聽說，安全生產三板斧的概念：可灰度、可觀測、可回滾。那麼灰度釋出能力就是幫助企業軟體做到快速迭代驗證的必備能力。

在 K8s 中金絲雀釋出的最佳實踐如下：

第一步：新建灰度 Deployment，部署新版本的映象，打上新版本的標籤。

第二步：配置針對新版本的標籤路由規則。

第三步：驗證成功，擴大灰度比例。

第四步：若驗證成功，將穩定版本的應用更新成最新映象；若驗證失敗，把灰度的 Deployment 副本數調整到 0 或刪除該 Deployment。

### 全鏈路灰度

全鏈路灰度釋出就是透過線上多個應用部署灰度版本，灰度流量全部進入灰度版本，正常流量進入生產版本。灰度版本只針對灰度流量驗證，有效減少風險。我們可以透過流量路由結合流量染色可以實現全鏈路的流量灰度能力。

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

## 流量路由標準化

業界微服務治理存在概念不統一、配置形式不統一、能力不統一、多框架統一管控較為複雜等問題。比如我們希望實現流量路由的能力，在 Spring Cloud 中可能需要透過 Spring Cloud 動態規則的方式進行配置，在 istio 中可能又是另一套配置方式，在其它元件上可能又是不同的配置。不同框架治理配置方式的不一致使得微服務統一治理管控的複雜度相當高。為此我們需要透過 OpenSergo 實現一套標準化的流量路由能力與實踐，這樣在任 OpenSergo 生態中的元件上需透過配置 OpenSergo TrafficRouter 規則，即可實現一致的流量路由能力。

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

我們在實踐了許多流量路由的場景後，將流量路由規則進行了如下的設計與抽象。

OpenSergo 的流量路由規則 (v1alpha1) 主要分為如下：

-   Workload 集合的抽象 (`VirtualWorkloads`)：將某一組 `VirtualWorkload`（如 Kubernetes Deployment, Statefulset 或者一組 pod，或某個 JVM 程式，甚至是一組 DB 例項）按照一定的特徵進行分類。

-   流量標籤規則 (`RouterRule`)：將特定特徵的流量對映至特定特徵所對應的 VirtualWorkloads 上。

-   路由鏈規則(`RouterChain`)將特定的 `RouterRule` 跟 `VirtualWorkloads`按照一定邏輯排列組合成 pipeline。

### Workload 集合的抽象 (VirtualWorkloads)

`VirtualWorkloads` 虛擬工作負載集合的抽象即 VirtualWorkload 集合，其中會將 VirtualWorkload 按照一定的特徵進行分類。

`VirtualWorkload`虛擬工作負載即 workload 集合的抽象，將一定屬性特徵的 workload 集合劃分成一個 VirtualWorkload，其中 VirtualWorkload 可以是目標 service 集合也可以是 deployment，甚至可以是 database 的例項、庫、表集合。

對於通用的 workload 場景，我們可以利用 VirtualWorkloads CRD 進行描述。特別地，對於 Kubernetes workload，我們可以透過直接在 workload 上打 label 的方式進行特徵標記，如在 Deployment 上打上 `traffic.opensergo.io/label: gray` 標籤代表當前 Deployment 的標籤特徵為 gray。

一個標準的 workloads 描述應該類似於：

```
apiVersion: traffic.opensergo.io/v1alpha1
kind: VirtualWorkloads
metadata:
  name: tag-rule
spec:
  selector:
    app: my-app
  virtualWorkload:
    - name: my-app-gray
      target: my-app-gray-deployment    
      type: deployment
      selector:
        tag: gray
```

### 流量路由規則 (RouterRule)

流量路由規則 (`RouterRule`) 將特定特徵的流量對映至特定特徵所對應的 VirtualWorkloads 上。

假設現在需要將內部測試使用者灰度到新版主頁，測試使用者 uid=12345，UID 位於 X-User-Id header 中，不符合條件的外部使用者流量訪問原版主頁。那麼只需要配置如下 CRD 即可：

```
apiVersion: traffic.opensergo.io/v1alpha1
kind: RouterRule
metadata:
  name: tag-traffic-router-rule
spec:
  selector:
    app: my-app
  http: 
    - name: my-traffic-router-http-rule
      rule:  
        match:
          header: 
            X-User-Id:   # 引數名
              exact: 12345       # 引數值
          uri:
            exact: "/index"
        targets:
          - workloads: my-app-worksloads
            name: gray
      target:
        workloads: my-app-worksloads
        name: base
```

透過上述配置，我們可以將 path 為 `/index`，且 uid header 為 12345 的 HTTP 流量為灰度流量，訪問灰度版本的新版主頁。

-   **標籤路由場景的流量路由配置**

假設我們希望 Header x-user-id 為 123 的流量訪問 spring-cloud-a 的具備 gray 標籤的例項。其中 spring-cloud-a 的標籤情況如下：

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

那麼我們需要配置對應的 TrafficRouterRule 配置如下：

```
apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficRouterRule
metadata:
  name: tag-traffic-router-rule
spec:
  selector:
    app: spring-cloud-a
  http: 
    - name: my-traffic-router-http-rule
      rule:  
        match:
          headers: 
            X-User-Id:   # 引數名
              regex: "^(?!(?:\d{1,2}|100)$)[0-9]\d+$"       # 引數值
          queryParams:
            name:
              exact: xiaoming
          uri:
            prefix: "/"
        targets:
          - workloads: spring-cloud-a-worksloads
            name: gray
      target:
        - workloads: spring-cloud-a-worksloads
          name: base
```

對應的 VirtualWorkloads 配置如下：

```
apiVersion: traffic.opensergo.io/v1alpha1
kind: VirtualWorkloads
metadata:
  name: spring-cloud-a-worksloads
spec:
  selector:
    app: spring-cloud-a
  virtualWorkload:
    - name: gray
      target: spring-cloud-a
      type: deployment
      selector:
        tag: gray
      loadbalance: random
    - name: base
      target: spring-cloud-a
      type: deployment
      selector:
        tag: _base
      loadbalance: random
```

-   **金絲雀釋出場景的流量路由配置**

我們配置瞭如下的金絲雀規則，希望 10% 的流量訪問 spring-cloud-a 中具有 gray 標籤的例項：

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

對應的 TrafficRouterRule 配置如下：

```
apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficRouterRule
metadata:
  name: tag-traffic-router-rule
spec:
  selector:
    app: spring-cloud-a
  http: 
    - name: my-traffic-router-http-rule
      rule:
        targets:
          - workloads: spring-cloud-a-worksloads
            name: gray
            weight: 10
          - workloads: spring-cloud-a-worksloads
            name: base
            weight: 90
      target:
        - workloads: spring-cloud-a-worksloads
          name: base
```

## 流量路由 Demo 演示

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

-   Spring Cloud Alibaba Consumer 應用中增加 OpenSergo 的依賴，並啟動 Spring Cloud Alibaba 流量路由的 Demo

```
<dependency>
    <groupid>com.alibaba.cloud</groupid>
    <artifactid>opensergo-resource-transform</artifactid>
    <version>2.2.9-SNAPSHOT</version>
</dependency>
```

### 配置 OpenSergo 流量路由

-   啟動 OpenSergo 控制面
-   下發 TrafficRouterRule CRD 規則

假設現在需要將灰度流量路由到 v2 版本，灰度請求符合如下條件 header：name=xiaoming，Params：location=shenzhen 的請求流量去往灰度 v2 版本，不符合條件的流量訪問 v1 版本。那麼只需要配置如下 CRD 即可：

```
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: TrafficRouterRule
metadata:
  name: http-foo-rule
  labels:
    app: foo-app
spec:
  http:
    match:
      headers:
        name: 'xiaoming'
      queryParams:
        location: 'shenzhen'
    targets:
      - name: "v2"
        selectors:
          version: "v2"
  target:
    name: "v1"
    selectors:
      version: "v1"
```

### 結果驗證

當我們執行 `curl http://127.0.0.1:18083/router-test`

```
NacosRegistration{nacosDiscoveryProperties=NacosDiscoveryProperties{serverAddr='127.0.0.1:8848', endpoint='', namespace='', watchDelay=30000, logName='', service='service-provider', weight=1.0, clusterName='DEFAULT', group='DEFAULT_GROUP', namingLoadCacheAtStart='false', metadata={preserved.register.source=SPRING_CLOUD, version=v1}, registerEnabled=true, ip='192.168.1.4', networkInterface='', port=18082, secure=false, accessKey='', secretKey='', heartBeatInterval=null, heartBeatTimeout=null, ipDeleteTimeout=null, failFast=true}}
```

其中返回預設 v1 版本的例項當我們執行`curl -H 'name:xiaoming' http://127.0.0.1:18083/router-test?location=shenzhen`

```
NacosRegistration{nacosDiscoveryProperties=NacosDiscoveryProperties{serverAddr='127.0.0.1:8848', endpoint='', namespace='', watchDelay=30000, logName='', service='service-provider', weight=1.0, clusterName='DEFAULT', group='DEFAULT_GROUP', namingLoadCacheAtStart='false', metadata={preserved.register.source=SPRING_CLOUD, version=v2}, registerEnabled=true, ip='192.168.1.4', networkInterface='', port=18081, secure=false, accessKey='', secretKey='', heartBeatInterval=null, heartBeatTimeout=null, ipDeleteTimeout=null, failFast=true}}
```

其中符合流量匹配的條件，返回預設 v2 版本的例項。

## 總結與展望

流量路由是微服務流量治理中的重要的一環，當然 MSE 還提供更廣範圍、更多場景的微服務治理能力，包括全鏈路灰度、無損上下線、微服務資料庫治理、日誌治理等一系列的微服務治理能力。服務治理是微服務改造深入到一定階段之後的必經之路，是將微服務做穩做好的關鍵。同時我們也在與 CloudWeGo、Kratos、Spring Cloud Alibaba、Dubbo、ShardingSphere 等社群共同建設 OpenSergo 微服務治理標準，將企業與社群中微服務治理的場景與最佳實踐共同提取成標準規範，也歡迎更多社群與企業一起參與 OpenSergo 微服務治理標準的共建。歡迎大家加入 OpenSergo 社群交流群（釘釘群）進行討論：34826335

**MSE 雲原生閘道器、註冊配置專業版預付費首購享 8 折，首購 1 年及以上享 7 折**。點選[此處](https://www.aliyun.com/product/aliware/mse)，即享優惠！</https:>

OpenSergo 流量路由：從場景到標準化的探索

相關文章