背景
微服务软件架构下，业务新功能上线前搭建完整的一套测试系统进行验证是相当费人费时的事，随着所拆分出微服务数量的不断增大其难度也俞大。这一整套测试系统所需付出的机器成本往往也不低，为了保证应用新版本上线前的功能正确性验证效率这套系统还必须一直单独维护好。当业务变得庞大且复杂时，往往还得准备多套，这是整个行业共同面临且难解的成本和效率挑战。如果能在同一套生产系统中完成新版本上线前的功能验证的话，所节约的人力和财力是相当可观的。
除了开发阶段的功能验证，生产环境中引入灰度发布才能更好地控制新版本软件上线的风险和爆炸半径。灰度发布是将具有一定特征或者比例的生产流量分配到需要被验证的服务版本中，以观察新版本上线后的运行状态是否符合预期。
阿里云 ASM Pro(https://servicemesh.console.aliyun.com/)基于 Service Mesh 所构建的全链路灰度方案，能很好帮助解决以上两个场景的问题。
ASM Pro 产品功能架构图：
核心能力使用的就是上图扩展的流量打标和按标路由以及流量Fallback 的能力，下面详细介绍说明。
场景说明
全链路灰度发布的常见场景如下：
以Bookinfo为例，入口流量会带上期望的tag分组，sidecar通过获取请求上下文（Header或Context) 中的期望tag，将流量路由分发到对应tag分组，若对应tag分组不存在，默认会fallback路由到base分组，具体fallback策略可配置。接下来详细描述具体的实现细节。
入口流量的tag标签，一般是在网关层面基于类似tag插件的方式，将请求流量进行打标。 比如将userid处于一定范围的打上代表灰度的tag，考虑到实际环境网关的选择和实现的多样性，网关这块实现不在本文讨论的范围内。
下面我们着重讨论基于ASM Pro如何做到全链路流量打标和实现全链路灰度。
实现原理
Inbound是指请求发到App的入口流量，Outbond是指App向外发起请求的出口流量。
上图是一个业务应用在开启mesh后典型流量路径：业务App接收到一个外部请求p1，接着调用背后所依赖的另一个服务的接口。此时，请求的流量路径是p1->p2->p3->p4，其中p2是Sidecar对p1的转发，p4是Sidecar对p3的转发。为了实现全链路灰度，p3和p4都需要获取到p1进来的流量标签，才能将请求路由到标签所对应的后端服务实例，且p3和p4也要带上同样的标签。关键在于，如何让标签的传递对于应用完全无感，从而实现全链路的标签透传，这是全链路灰度的关键技术。ASM Pro的实现是基于分布式链路追踪技术（比如，OpenTracing、OpenTelemetry等）中的traceId来实现这一功能。
在分布式链路追踪技术中，traceId被用于唯一地标识一个完整的调用链，链路上的每一个应用所发出的扇出（fanout）调用，都会通过分布式链路追踪的SDK将源头的traceId给带上。ASM Pro全链路灰度解决方案的实现正是建立在这一分布式应用架构所广泛采纳的实践之上的。
上图中，Sidecar本来所看到的inbound和outbound流量是完全独立的，无法感知两者的对应关系，也不清楚一个inbound请求是否导致了多个outbound请求的发生。换句话说，图中p1和 p3两个请求之间是否有对应关系Sidecar并不知情。
在ASM Pro全链路灰度解决方案中，通过traceId将p1和p3两个请求做关联，具体说来依赖了Sidecar中的x-request-id 这个trace header。Sidecar内部维护了一张映射表，其中记录了traceId和标签的对应关系。当Sidecar收到p1请求时，将请求中的traceId和标签存储到这张表中。当收到p3请求时，从映射表中查询获得traceId所对应的标签并将这一标签加入到p4请求中，从而实现全链路的打标和按标路由。下图大致示例了这一实现原理。
换句话说，ASM Pro的全链路灰度功能需要应用使用分布式链路追踪技术。如果想运用这一技术的应用没有使用分布式链路追踪技术的话不可避免地涉及到一定的改造工作。对于Java应用来说，仍可以考虑采用Java Agent以AOP的方式让业务无需改造地实现traceId在inbound和outbound之间透传。
实现流量打标
ASM Pro中引入了全新的TrafficLabel CRD用于定义Sidecar所需透传的流量标签从哪里获取。下面所例举的YAML文件中，定义了流量标签来源和需要将标签存储OpenTracing中（具体是x-trace头）。其中流量标的名为trafficLabel， 取值依次从$getContext(x-request-id))到最后从本地环境的$(localLabel)中获取。
apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
name: default
spec:
rules:
- labels:
- name: trafficLabel
valueFrom:
- $getContext(x-request-id) //若使用aliyun arms,对应为x-b3-traceid
- $(localLabel)
attachTo:
- opentracing
# 表示生效的协议，空为都不生效，*为都生效
protocols: "*"CR定义包含两块，即标签的获取和存储。
- 获取逻辑：先根据协议上下文或者头（Header部分）中的定义的字段获取流量标签，如果没有，会根据traceId通过Sidecar本地记录的map获取, 该map表中保存了traceId对应流量标识的映射。若map表中找到对应映射，会将该流量打上对应的流量标，若获取不到，会将流量标取值为本地部署对应环境的localLabel。localLabel对应本地部署的关联label，label名为ASM_TRAFFIC_TAG。
本地部署对应环境的标签名为"ASM_TRAFFIC_TAG"，实际部署可以结合CI/CD系统来关联。
- 存储逻辑：attachTo指定存储在协议上下文的对应字段，比如HTTP对应Header字段，Dubbo对应rpc context部分，具体存储到哪一个字段中可配置。
有了TrafficLabel 的定义，我们知道如何将流量打标和传递标签，但光有这个还不足以做到全链路灰度，我们还需要一个可以基于trafficLabel流量标识来做路由的功能，也就是“按标路由”，以及路由fallback等逻辑，以便当路由的目的地不存在时，可以实现降级的功能。
按流量标签路由
这一功能的实现扩展了Istio的VirtualService和DestinationRule。
在DestinationRule中定义Subset
自定义分组subset 对应的是trafficLabel 的value
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: myapp
spec:
host: myapp/*
subsets:
- name: myproject # 项目环境
labels:
env: abc
- name: isolation # 隔离环境
labels:
env: xxx # 机器分组
- name: testing-trunk # 主干环境
labels:
env: yyy
- name: testing # 日常环境
labels:
env: zzz
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: myapp
spec:
hosts:
- myapp/*
ports:
- number: 12200
name: http
protocol: HTTP
endpoints:
- address: 0.0.0.0
labels:
env: abc
- address: 1.1.1.1
labels:
env: xxx
- address: 2.2.2.2
labels:
env: zzz
- address: 3.3.3.3
labels:
env: yyySubset支持两种指定形式：
- labels用于匹配应用中带特定标记的节点（endpoint）；
- 通过ServiceEntry用于指定属于特定subset的IP地址，注意这种方式与labels指定逻辑不同，它们可以不是从注册中心（K8s或者其他）拿到的地址，直接通过配置的方式指定。适用于Mock环境，这个环境下的节点并没有向服务注册中心注册。
在VirtualService中基于subset
1）全局默认配置
- route部分可以按顺序指定多个destination，多个destination之间按照weight值的比例来分配流量。
- 每个destination下可以指定fallback策略，case标识在什么情况下执行fallback，取值：noinstances（无服务资源）、noavailabled（有服务资源但是服务不可用），target指定fallback的目标环境。如果不指定fallback，则强制在该destination的环境下执行。
- 按标路由逻辑，我们通过改造VirtualService，让subset 支持占位符 $trafficLabel, 该占位符$trafficLabel表示从请求流量标中获取目标环境， 对应TrafficLabel CR中的定义。
全局默认模式对应泳道，也就是单个环境内封闭，同时指定了环境级别的fallback策略。
配置样例如下：
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: default-route
spec:
hosts: # 对所有应用生效
- */*
http:
- name: default-route
route:
- destination:
subset: $trafficLabel
weight: 100
fallback:
case: noinstances
target: testing-trunk
- destination:
host: */*
subset: testing-trunk # 主干环境
weight: 0
fallback:
case: noavailabled
target: testing
- destination:
subset: testing # 日常环境
weight: 0
fallback:
case: noavailabled
target: mock
- destination:
host: */*
subset: mock # Mock中心
weight: 02）个人开发环境定制
- 先打到日常环境，当日常环境没有服务资源时，再打到主干环境。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: projectx-route
spec:
hosts: # 只对myapp生效
- myapp/*
http:
- name: dev-x-route
match:
trafficLabel:
- exact: dev-x # dev环境: x
route:
- destination:
host: myapp/*
subset: testing # 日常环境
weight: 100
fallback:
case: noinstances
target: testing-trunk
- destination:
host: myapp/*
subset: testing-trunk # 主干环境
weight: 03） 支持权重配置
将打了主干环境标并且本机环境是dev-x的流量，80%打到主干环境，20%打到日常环境。当主干环境没有可用的服务资源时，流量打到日常。
sourceLabels 为本地workload 对应的label
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: dev-x-route
spec:
hosts: # 对哪些应用生效（不支持多应用配置）
- myapp/*
http:
- name: dev-x-route
match:
trafficLabel:
- exact: testing-trunk # 主干环境标
sourceLabels:
- exact: dev-x # 流量来自某个项目环境
route:
- destination:
host: myapp/*
subset: testing-trunk # 80%流量打向主干环境
weight: 80
fallback:
case: noavailabled
target: testing
- destination：
host: myapp/*
subset: testing # 20%流量打向日常环境
weight: 20按（环境）标路由
该方案依赖业务部署应用时带上相关标识（例子中对应label 为 ASM_TRAFFIC_TAG: xxx），常见为环境标识，标识可以理解是服务部署的相关元信息，这个依赖上游部署系统CI/CD系统的串联，大概示意图如下：
- K8s场景，通过业务部署时自动带上对应环境/分组 label标识即可，也就是采用K8s本身作为元数据管理中心。
- 非k8s场景，可以通过微服务已集成的服务注册中心或者元数据配置管理服务（metadata server）来集成实现。
注：ASM Pro 自研开发了ServiceDiretory 组件（可以参看ASM Pro 产品功能架构图），实现了多注册中心对接以及部署元信息的动态获取；
应用场景延伸
下面是典型的一个基于流量打标和按标路由实现的多套开发环境治理功能；每个开发者对应的Dev X环境只需部署有版本更新的服务即可；如果需要和其他开发者联调，可以通过配置fallback将服务请求fallback流转到对应开发环境即可。如下图的Dev Y环境的B -> Dev X环境的C。
同理，将Dev X环境等同于线上灰度版本环境也是可以的，对应可以解决线上环境的全链路灰度发布问题。
总结
本文介绍的基于“流量打标”和“按标路由” 能力是一个通用方案，基于此可以较好地解决测试环境治理、线上全链路灰度发布等相关问题，基于服务网格技术做到与开发语言无关。同时，该方案适应于不同的7层协议，当前已支持HTTP/gRpc和Dubbo协议。
对应全链路灰度，其他厂商也有一些方案，对比其他方案ASM Pro的解决方案的优点是：
- 支持多语言、多协议。
- 统一配置模板TrafficLabel， 配置简单且灵活，支持多级别的配置（全局、namespace 、pod级别）。
- 支持路由fallback实现降级。
基于“流量打标” 和 “按标路由”能力还可以用于其他相关场景：
- 大促前的性能压测。在线上压测的场景中，为了让压测数据和正式的线上数据实现隔离，常用的方法是对于消息队列，缓存，数据库使用影子的方式。这就需要流量打标的技术，通过tag区分请求是测试流量还是生产流量。当然，这需要Sidecar对中间件比如Redis、RocketMQ等进行支持。
- 单元化路由。常见的单元化路由场景，可能是需要根据请求流量中的某些元信息比如uid，然后通过配置得出对应所属的单元。在这个场景中，我们可以通过扩展TrafficLabel定义获取“单元标”的函数来给流量打上“单元标”，然后基于“单元标”将流量路由到对应的服务单元。
