ServiceMesh 4：实现流量染色和分级发布

★ ServiceMesh系列

1 什么是流量染色

在复杂的生产场景中，经常会有同一个服务中，存在多个版本长期共存的需求。为了让不同的用户在不一样的版本中使用，就需要对用户的请求进行采样和染色，打上不同的标识。

这样的目的有几个：

1. 支撑分级发布，避免全量发布时可能遇到的大规模风险，如系统崩溃、用户流失。
2. 支持染色实验，让部分人优先体验新版本或者实验功能
3. QA的线上问题分析、验证、调试，甚至压测都可以放在染色部署区域去做，因为是强隔离模式，可以避免对线上其他用户的影响

使用Service Mesh的流量染色能力，可以在单个服务中根据特征值进行多元版本流量分发。特别是链路繁琐的巨型网格中，能够管理长达10个以上的链路分流调度，这个能力显得非常重要。常见的 Canary Release（金丝雀）、ABTesting、Diversified Version（多版本分流），都是基于此类算法实现。这边介绍在无侵入业务的情况下，Mesh如何实现流量染色。

1. Canary Release

2. Diversified Version

3. Diversified Version

2 Mesh使用标签特性进行染色

Mesh如果想要实现流量染色，需要具备以下几个条件：

• 请求的流量中，需要附带某些特征，如流量的请求的Header、Cookies、queryParams等，它们带有某些信息。
• 部署多版本服务
  • 部署在kubernetes上的服务（svc）的实例（pod）需要接入Mesh，并打上版本标签
  • 或者创建不同的服务（svc），后面把流量引入到这个新的服务上去
• 在Mesh平台上对应的服务中配上策略：当请求的流量带有某些特征（如header中带有UserID=12345678）时，流量路由到对应标签（如 version = v1.7 ）的服务实例上。
• 不符合条件的路由则默认走到默认版本中（如 version = default）。

所以，Mesh的染色本质上是通过在流量中携带一些特征（如流量的请求的Header、Cookies、queryParams等），而Mesh会根据这些请求的特征进行路由匹配，转发到对应的带有某些特征的服务实例上。

未匹配成功的流量则走到默认版本中，从而实现多个版本和跟默认版本的业务隔离的目标。

2.1 Mesh 染色流转原理

2.1.1 Istio支持的策略模型

即Istio支持的流量特征包括uri、scheme、method、headers、queryParams等条件，可以根据这些特征进行路由转发：

完整参考官方文档：https://istio.io/latest/docs/reference/config/networking/virtual-service/

2.1.2 流量转发实现

基于上述的策略模型，如果你想配置如下：请求的header 带有 username=brand 或者 dep=A1025 的时候，将流量转发到服务的v1版本，否着转发到default版本。

则策略代码如下：

# 说明：VirtualService 流量染色，根据不同的条件将流量发往不同特征的版本中，假设这边有default、v1、v2 版本
apiVersion: networking.istio.io/beta
kind: VirtualService
metadata:
  name: router-test-vs
spec:
  hosts:
  - router-test-vs  # 调度router-test服务的流量
exportTo:
- "."
http:  # 加各种路由条件，比如匹配人员、所属部门进行路由
- match  # 用户匹配 brand，部门匹配 A1025 时
  - headers:
    username:
      exact: brand
  - headers:
    department:
      exact: A1025
  route:
    destination:
    # todo 匹配条件的流量路由到对应的服务上，比如ServiceA-V1
route:
  destination:
  # todo 不匹配条件的流量路由到其他服务上，比如ServiceA-V2

3 总结

本文介绍了在Mesh场景下如何使用流量染色，来对不同特征的流量进行分发的实现过程。流量染色在我们实际的生产环境中可以有很多收益和价值：

1. 支撑分级发布，避免全量发布时出现问题
2. 支持染色实验，让部分人进入实验环境
3. QA的线上问题分析、验证、调试，甚至压测