在链路中已透传引流请求头场景使用宽松模式流量泳道

您可以使用宽松模式的流量泳道实现应用版本隔离，将链路透传请求头指定为引流请求头，使用链路透传请求头的内容向不同泳道引流。泳道中服务相互调用时，若目标服务不存在当前泳道则转发至基线泳道，保障链路完整性，简化流量管理。

重要

开始阅读前，请确保您已经阅读并理解了使用宽松模式流量泳道实现全链路流量管理及其相关的内容。

场景概述

本示例使用mocka、mockb、mockc三个服务创建代表服务调用链三个版本的三个泳道：s1、s2、s3。其中s1为基线泳道，包含完整的三个服务，s2仅包含mocka、mockc两个服务，s3仅包含mockb一个服务。同时，链路透传请求头与引流请求头都指定为my-request-id。

步骤一：创建泳道组和对应泳道

创建泳道组。

登录ASM控制台，在左侧导航栏，选择服务网格 > 网格管理。
在网格管理页面，单击目标实例名称，然后在左侧导航栏，选择流量管理中心 > 流量泳道。

在流量泳道页面，单击创建泳道组，在创建泳道组面板，配置相关信息，然后单击确定。

配置项	说明
泳道组名称	本示例配置为test。
入口网关	选择ingressgateway。
泳道模式	选择宽松模式。
调用链路上下文透传方式	选择自定义请求头透传。
链路透传请求头	配置为my-request-id。
泳道服务	选择目标Kubernetes集群和default命名空间，在下方列表中选中mocka、mockb和mockc服务，单击图标，添加目标服务到已选择区域。

创建s1、s2、s3泳道，并分别绑定v1、v2、v3版本。

在流量泳道页面的流量规则定义区域，单击创建泳道。

在创建泳道对话框，配置相关信息，然后单击确定。

配置项	说明
泳道名称	三条泳道分别配置为s1、s2、s3。
配置服务标签	标签名称：配置为ASM_TRAFFIC_TAG 标签值：三条泳道分别配置为v1、v2和v3。
添加服务	s1泳道：选择mocka(default)、mockb(default)、mockc(default)。 s2泳道：选择mocka(default)、mockc(default)。 s3泳道：选择mockb(default)。

创建s1泳道的示例图如下。

三个泳道创建完成后，示例效果如下。默认情况下，您在泳道组中创建的第一个泳道将被设定为基线泳道。您也可以修改基线泳道，当流量发往其它泳道中不存在的服务时，通过回退机制将请求转发至基线泳道。关于修改基线泳道的具体操作，请参见修改基线泳道。

三个泳道创建完成后，针对泳道组中的每个服务都将生成泳道规则对应的目标规则DestinationRule和虚拟服务VirtualService。您可以在控制台左侧导航栏，选择流量管理中心 > 目标规则或虚拟服务进行查看。例如，针对mocka服务会自动创建如下DestinationRule和VirtualService。

展开查看DestinationRule YAML示例

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

展开查看VirtualService YAML示例

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:
        - headers:
            my-request-id:
              exact: s1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-request-id:
              exact: s2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-request-id:
              exact: s3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

创建三个泳道对应的引流规则。

在流量泳道页面的流量规则定义区域，单击目标泳道右侧操作列下的引流规则。

在添加引流规则对话框，配置相关信息，然后单击确定。

本文以泳道服务对应入口API均为/mock为例，为每个泳道配置相同的引流规则。

配置项	说明
入口服务	选择mocka.default.svc.cluster.local。
引流规则	配置三个泳道的引流规则名称分别为r1、r2、r3，域名为*。
匹配请求的URI	配置匹配方式为精确，匹配内容为/mock。

为s1泳道添加引流规则的示例图如下：

三个泳道的引流规则创建成功后，示例效果如下：

创建成功后，会自动生成每条泳道的引流规则，即虚拟服务VirtualService。例如，针对s2泳道会生成如下的虚拟服务VirtualService。

展开查看VirtualService YAML示例

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: swimlane-ingress-vs-test-s2
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            my-request-id:
              exact: s2
          uri:
            exact: /mock
      name: r2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

步骤二：验证全链路灰度功能是否生效

获取ASM网关的公网IP。具体操作，请参见获取ASM网关地址。
执行以下命令，设置环境变量。
xxx.xxx.xxx.xxx为上一步获取的IP。
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```
验证全链路灰度功能是否生效。
1. 执行以下命令，查看s1泳道的访问效果。
  my-request-id对应的值s1为步骤一.2创建s1泳道时配置的泳道名称。
```
for i in {1..100};  do curl -H'my-request-id: 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标头my-request-id: s1声明的流量流向s1泳道下的相关服务，符合预期。
2. 执行以下命令，查看s2泳道的访问效果。
  my-request-id对应的值s2为步骤一.2创建s2泳道时配置的泳道名称。
```
for i in {1..100};  do curl -H'my-request-id: s2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  预期输出：
```
mocka(version: v2, ip: 192.168.1.101)-> mockb(version: v1, ip: 192.168.1.100)-> mockc(version: v2, ip: 192.168.1.116)
```
  可以看到，通过设置HTTP标头my-request-id: s2声明的流量流向s2泳道下的相关服务。当流量发往泳道s2中不存在的服务mockb时，流量通过回退机制发往基线泳道s1中的mockb服务，后续流量发往mockc服务时，目标重新设定为s2泳道中的mockc服务，符合预期。
3. 执行以下命令，查看s3泳道的访问效果。
  my-request-id对应的值s3为步骤一.2创建s3泳道时配置的泳道名称。
```
for i in {1..100};  do curl -H'my-request-id: s3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  预期输出：
```
mocka(version: v1, ip: 192.168.1.103)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 192.168.1.105)
```
  可以看到，通过设置HTTP标头my-request-id: s3声明的流量流向s3泳道下的相关服务。当流量发往泳道s3中不存在的服务mocka、mockc时，流量通过回退机制发往基线泳道s1中的mocka、mockc服务，符合预期。