ServiceMesh 4：实现流量染色和分级发布
1 什么是流量染色
在复杂的生产场景中，经常会有同一个服务中，存在多个版本长期共存的需求。为了让不同的用户在不一样的版本中使用，就需要对用户的请求进行采样和染色，打上不同的标识。
这样的目的有几个：
- 支撑分级发布，避免全量发布时可能遇到的大规模风险，如系统崩溃、用户流失。
- 支持染色实验，让部分人优先体验新版本或者实验功能
- 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场景下如何使用流量染色，来对不同特征的流量进行分发的实现过程。流量染色在我们实际的生产环境中可以有很多收益和价值：
- 支撑分级发布，避免全量发布时出现问题
- 支持染色实验，让部分人进入实验环境
- QA的线上问题分析、验证、调试，甚至压测