背景

在微服务架构的实践过程中，将上下游服务完全解耦几乎只能存在于理想状态下。常见的情况是，频繁地对微服务做变更发布，通常都会导致业务流量出现大量损失，于是研发人员不得不在晚上业务低峰期做变更。并且在发布过程中，涉及到的上下游团队必须全程待命，以便于在发布阶段发现问题之后，立刻修复，极大地降低了研发人员的幸福感。

如何落地可灰度、可观测、可回滚的安全生产能力，满足业务高速发展情况下快速迭代和小新验证的诉求，是企业在微服务化深入过程中必须面对的问题。
本文将介绍在MSAP中，对 Spring Cloud 微服务应用进行全链路流量控制的整体方案。通过全链路流量控制功能，可以快速创建流量控制环境，将具有一定特征的流量路由到目标版本应用。

什么是全链路灰度

全链路灰度涵盖了整个系统链路中的所有的服务，确保新版本应用程序在整个系统中的各个环节都得到验证，保证新版本与现有系统的兼容性和稳定性。

如下图所示：用户流量从网关进来，调用商城应用，商城应用内部调用订单应用，订单应用再调用支付应用。现在对商城应用和订单应用都发布了新的版本V1.1。在灰度验证时，需要进来的灰度流量同时经过商城应用和订单应用的V1.1版本，而其它不符合灰度规则的流量则继续走基线版本，这样就建立了两条逻辑上隔离的流量链路，可以更好的控制新版本的风险和影响范围。

全链路灰度实现方案

一般目前比较流行的是通过服务治理中的元数据去传递灰度标签，并在服务治理的负载均衡的过程中去识别标签，再读取对应标签的路由规则，从而实现全链路灰度，MSAP就是通过这个方式来实现的。

1 在MSAP平台发布应用，会通过JavaAgent的方式对服务进行无侵入的增强。

2 服务启动后，agent上报服务标签信息到服务治理中心，同时将标签信息添加到注册配置中心的元数据中。

3 服务调用时，由于agent对服务调用逻辑做了增强，会先识别标签，再去获取路由规则，最后对符合规则的应用进行调用。

MSAP全链路流量灰度

入口应用：入口应用微服务体系内的流量入口，通常使用网关作为入口应用。

泳道：为相同版本应用定义的一套隔离环境。只有满足了流控路由规则的请求流量才会路由到对应泳道里的打标应用。一个应用可以属于多个泳道，一个泳道可以包含多个应用，应用和泳道是多对多的关系。

泳道组：泳道的集合。泳道组的作用主要是为了区分不同团队或不同场景。

部署应用

在MSAP部署5个应用，其中gateway为网关，在配置泳道时作为入口应用。consumer-sw、provider-sw作为基线版本应用。consumer-sw1、provider-sw1作为新版本V1应用。

创建泳道组

入口应用选择 gateway，泳道组涉及应用选择consumer-sw、provider-sw、consumer-sw1、provider-sw1。

创建泳道

如下图所示，代表参数中id = 1的流量都会被请求到consumer-sw1、provider-sw1应用中。

灰度验证

对网关发起请求，可以发现参数中id=1的流量都路由到了consumer-sw1、provider-sw1中，观察监控信息能够看到请求流量的路由情况。

总结

本文介绍了MSAP实现全链路灰度的整体方案，同时基于MSAP做了一个简单的示例。MSAP 深度融合集成服务治理的能力，让开发人员能更专注与业务逻辑的开发，欢迎大家体验交流。