作者：尹航
1. 概述
在流量比例切换的过程中，我们可以逐步验证新版本服务的功能特性、可靠性等特性，一旦新版本服务不满足需求，还可以时刻将流量切回老版本，因此灰度发布也是一种在软件工程领域中得到广泛应用的发布方案。
当前，服务网格的无侵入式灰度发布已经是一个非常成熟的特性：我们可以同时部署服务的多个版本，使用 DestinationRule 来制定工作负载的版本定义，并使用 VirtualService 的流量比例分割的能力将不同比例的服务流量发往不同版本的工作负载，直至所有流量都直接发往新版本服务。
然而，在云原生应用广泛采用的大背景下，应用程序往往不再以单体服务的形式存在，而是被分解为一系列云原生服务部署在 Kubernetes 集群中，服务之间存在调用链路、共同对外提供服务。
当服务之间存在调用链路时，对服务的灰度发布往往不局限于单个服务，而是需要对服务的整条请求链路进行环境隔离与流量控制，即：保证灰度流量只发往调用链路中服务的灰度版本，实现调用链路之间相互隔离的隔离环境。针对整个调用链路的流量管理需求为服务网格的无侵入式流量管理方案带来了新的挑战：
- 流量规则复杂度高
基于 Istio 社区的 VirtualService 和 DestinationRule 规则需要针对每个服务进行单独定制，在全链路流量管理的场景下会提高配置出错的几率与服务流量的维护成本。
- 流量管理灵活度低
针对不同的全链路流量管理需求，难以通过简单调整流量规则实现全部需求（例如：针对一条灰度链路，仅发布链路中部分服务的新版本）。
服务网格 ASM 支持将应用的相关版本（或者其他特征）隔离成一个独立的运行环境（即泳道），然后通过设置泳道规则，将满足规则的请求流量路由到目标版本（或者其他特征）的应用上。ASM 流量泳道具有以下特点：
- 配置简单
通过使用 ASM 流量泳道功能，您仅需制定少量的治理规则，便可构建从网关到整个后端服务的多个流量隔离环境，有效保障多个服务顺利安全发布以及服务多版本并行开发，进一步促进业务的快速发展。
- 支持不同维度的全链路流量管理需求
ASM 流量泳道支持严格模式与宽松模式，两种模式各自有着自己的优势、限制以及适配使用场景，适配更多样的流量治理需求。
2. 流量泳道的严格模式与宽松模式
2.1 严格模式的流量泳道
在严格模式下，每条流量泳道中包含调用链路上的全部服务。该模式对于您的应用程序无任何要求，只需配置流量泳道即可实现。如下图所示：
2.2 宽松模式的流量泳道
在宽松模式下，您只需要确保创建一条包含调用链路中所有服务的泳道：基线泳道。其它泳道可以不包含调用链路上的全部服务。当一个泳道中的服务进行相互调用时，若目标服务在当前泳道中不存在，则请求将被转发到基线泳道中的相同服务，并在请求目标存在当前泳道中存在时将请求重新转发回当前泳道。使用宽松模式的流量泳道时，您的应用程序必须包含一个能够在整条调用链路中透传的请求头（链路透传请求头），并另外使用一个引流请求头用来根据请求头内容将流量路由到不同的流量泳道上。如下图所示：
本文接下来主要演示严格模式泳道在服务网格 ASM 中的应用。
3. 演示：使用严格模式的流量泳道实现全链路灰度管理
在本文的示例场景下，将使用上图所示的三个服务 mocka、mockb、mockc 创建代表服务调用链三个版本的三个泳道：s1、s2、s3。
3.1 前提条件
- 已创建 ASM 企业版或旗舰版实例，且版本为 1.18.2.111 及以上。具体操作，请参见创建 ASM 实例[1]。
- 已添加 ACK 集群到 ASM 实例。具体操作，请参见添加集群到 ASM 实例[2]。
- 已创建名称为 ingressgateway 的 ASM 网关。具体操作，请参见创建入口网关服务[3]。
- 已创建名称为 ingressgateway 且命名空间为 istio-system 的网关规则。具体操作，请参见管理网关规则[4]。
apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: ingressgateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - '*'
3.2 部署示例服务
首先在 ACK 集群中部署示例中的应用服务，以实现全链路灰度场景。为 default 命名空间启用 Sidecar 网格代理自动注入（具体操作，请参见启用自动注入[5]），接下来在 ACK 集群中执行以下命令，部署示例服务。
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-v1.yaml kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-v2.yaml kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-v3.yaml
3.3 创建泳道组和对应泳道
在示例中，我们将 mocka->mockb->mockc 服务调用链路的 v1、v2、v3 三个版本分隔成 s1、s2、s3 三条泳道，三条泳道组成的集合称为泳道组。在服务网格 ASM 中，可以通过简单的配置完成泳道组和泳道的创建。
- 登录 ASM 控制台[6]，在左侧导航栏，选择服务网格 > 网格管理。
- 在网格管理页面，单击目标实例名称，然后在左侧导航栏，选择流量管理中心 > 流量泳道。
- 在流量泳道页面，单击创建泳道组，在创建泳道组面板，配置相关信息，然后单击确定。
| 配置项 | 说明 |
| 泳道组名称 | 本示例配置为test。 |
| 入口网关 | 选择ingressgateway。 |
| 泳道模式 | 选择严格模式 |
| 泳道服务 | 选择目标Kubernetes集群和default命名空间，在下方列表中选中mocka、mockb和mockc服务，单击图标，添加目标服务到已选择区域。 |
接下来在泳道组内创建 s1、s2、s3 泳道，分别对应服务调用链路的 v1、v2、v3 版本。
- 在流量泳道页面的流量规则定义区域，单击创建泳道。
- 在创建泳道对话框，配置相关信息，然后单击确定。
三个泳道创建完成后，示例效果如下：
每创建一个泳道，流量泳道会自动创建出泳道对应的目标规则 DestinationRule。例如所有泳道创建完成后，会针对 mocka 服务自动创建如下目标规则 DestinationRule。
apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: labels: asm-system: 'true' provider: asm swimlane-group: test name: trafficlabel-dr-test-default-mocka namespace: istio-system spec: host: mocka.default.svc.cluster.local subsets: - labels: ASM_TRAFFIC_TAG: v1 name: s1 - labels: ASM_TRAFFIC_TAG: v2 name: s2 - labels: ASM_TRAFFIC_TAG: v3 name: s3
三个泳道创建完成后，针对泳道组中的每个服务都将生成泳道规则对应的虚拟服务 VirtualService。例如，针对 mocka 服务会自动创建如下虚拟服务 VirtualService。
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: labels: asm-system: 'true' provider: asm swimlane-group: test name: trafficlabel-vs-test-default-mocka namespace: istio-system spec: hosts: - mocka.default.svc.cluster.local http: - match: - sourceLabels: ASM_TRAFFIC_TAG: v1 route: - destination: host: mocka.default.svc.cluster.local subset: s1 - match: - sourceLabels: ASM_TRAFFIC_TAG: v2 route: - destination: host: mocka.default.svc.cluster.local subset: s2 - match: - sourceLabels: ASM_TRAFFIC_TAG: v3 route: - destination: host: mocka.default.svc.cluster.local subset: s3
最后创建各个泳道对应的引流规则。通过不同的引流规则，ASM 网关可以将不同特征的请求路由到不同的泳道隔离环境之内，实现泳道内服务调用链路之间的完全隔离。下文以创建 s1 泳道的引流规则为例进行说明，请参照以下步骤创建 s2 和 s3 泳道的引流规则。
- 在流量泳道页面的流量规则定义区域，单击目标泳道右侧操作列下的引流规则。
- 在添加引流规则对话框，配置相关信息，然后单击确定。本文以泳道服务对应入口 API 均为 /mock 为例，为每个泳道配置相同的引流规则。
| 配置项 | 说明 |
| 入口服务 | 选择mocka.default.svc.cluster.local。 |
| 引流规则 | 配置名称为r1，域名为*。 |
| 匹配请求的URI | 配置匹配方式为精确，匹配内容为/mock。 |
| 添加Header匹配规则 | 单击添加Header匹配规则，在添加的Header匹配规则中，填写名称为x-asm-prefer-tag，匹配方式为精确，匹配内容为s1。 |
三个泳道的引流规则创建成功后，示例效果如下：
创建成功后，会自动生成每条泳道的引流规则，即虚拟服务 VirtualService。例如，针对泳道 s1 会生成如下的虚拟服务 VirtualService：
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: labels: asm-system: 'true' provider: asm swimlane-group: test name: swimlane-ingress-vs-test-s1 namespace: istio-system spec: gateways: - istio-system/ingressgateway hosts: - '*' http: - match: - headers: x-asm-prefer-tag: exact: s1 uri: exact: /mock name: r1 route: - destination: host: mocka.default.svc.cluster.local subset: s1
3.4 验证全链路灰度功能是否生效
通过以上的规则配置，ASM 流量泳道已经自动创建好了用于维护不同调用链路间相互隔离的流量规则。可以通过简单的访问验证通过流量泳道实现的全链路灰度是否生效。
1）获取 ASM 网关的 IP 地址（参考获取 ASM 网关地址[7]）。
2）执行以下命令设置环境变量。xxx.xxx.xxx.xxx 为上一步获取的 IP。
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
3）验证全灰度链路功能是否生效。
- 执行以下命令，查看 s1 泳道的访问效果。x-asm-prefer-tag 对应的值 s1 为步骤二创建 s1 泳道时配置的泳道名称。
for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出：
-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)
由预期输出得到，通过设置 HTTP 标头 x-asm-prefer-tag: s1 声明的流量流向 s1 泳道下的相关服务，符合预期。
- 执行以下命令，查看 s2 泳道的访问效果。x-asm-prefer-tag 对应的值 s2 为步骤二创建 s2 泳道时配置的泳道名称。
for i in {1..100}; do curl -H 'x-asm-prefer-tag: s2' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出：
-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v2, ip: 172.17.0.126)-> mockc(version: v2, ip: 172.17.0.128)
由预期输出得到，通过设置 HTTP 标头 x-asm-prefer-tag: s2 声明的流量流向 s2 泳道下的相关服务，符合预期。
- 执行以下命令，查看 s3 泳道的访问效果。x-asm-prefer-tag 对应的值 s3 为步骤二创建 s3 泳道时配置的泳道名称。
for i in {1..100}; do curl -H 'x-asm-prefer-tag: s3' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出：
-> mocka(version: v3, ip: 172.17.0.132)-> mockb(version: v3, ip: 172.17.0.127)-> mockc(version: v3, ip: 172.17.0.69)
由预期输出得到，通过设置 HTTP 标头 x-asm-prefer-tag: s3 声明的流量流向 s3 泳道下的相关服务，符合预期。
4. 总结
本文简要讨论了在使用服务网格治理云原生应用流量时，在全链路流量管理场景下的挑战与局限；并介绍了服务网格 ASM 中的流量泳道能力在服务网格全链路流量管理下的优势与特点。接下来针对 ASM 流量泳道的严格模式进行了详细演示与说明。接下来我们还会针对宽松模式下的 ASM 流量泳道进行进一步地深入介绍。
相关链接：
[1] 创建 ASM 实例
[2] 添加集群到 ASM 实例
[3] 创建入口网关服务
[4] 管理网关规则
[5] 开启 Sidecar 自动注入
[6] ASM 控制台
[7] 获取 ASM 网关地址
点击此处了解服务网格 ASM 产品详情