作者： 十眠、洵沐
背景
微服务体系架构中，服务之间的依赖关系盘根错节，有时某个性能发版依赖多个服务同时降级上线。咱们心愿能够对这些服务的新版本同时进行小流量灰度验证，这就是微服务架构中特有的全链路灰度场景，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。在公布过程中，咱们只需部署服务的灰度版本，流量在调用链路上流转时，由流经的网关、各个中间件以及各个微服务来辨认灰度流量，并动静转发至对应服务的灰度版本。如下图：
上图能够很好展现这种计划的成果，咱们用不同的色彩来示意不同版本的灰度流量，能够看出无论是微服务网关还是微服务自身都须要辨认流量，依据治理规定做出动静决策。当服务版本发生变化时，这个调用链路的转发也会实时扭转。相比于利用机器搭建的灰度环境，这种计划不仅能够节俭大量的机器老本和运维人力，而且能够帮忙开发者实时疾速的对线上流量进行精细化的全链路管制。
全链路灰度能力晋升了微服务架构带来的疾速迭代、稳定性验证的劣势，给企业生产环境的零碎带来了真真切切的益处。本文将着重介绍 MSE 服务治理基于全链路灰度能力的利用场景与痛点延长进去了新的能力。
全链路之运行时白屏化能力
在咱们生产环境应用全链路灰度的过程中，咱们经常会遇到一些问题。
- 咱们配置全链路灰度的流量流向是否合乎预期，咱们的流量是否依照咱们配置的灰度规定进行匹配。
- 咱们灰度的流量呈现了大量的慢调用、异样，我该如何确定是咱们新版本代码的业务问题还是因为咱们在流量灰度过程中思考不全导致的零碎问题，如何疾速定位问题，从而实现高效的迭代。
- 在咱们设计灰度零碎的过程中，咱们须要思考如何对咱们的灰度流量进行打标，有些时候在入口利用、微服务接口出可能难以找到适合的流量特色（参数、headers 等携带的具备业务语义的标识），在这样的场景下咱们如何快捷地对咱们的流量进行打标。
基于以上一些列的问题，也是咱们在反对云上客户落地全链路灰度的过程中一直碰到的问题。运行时白屏化能力也就是咱们在这个过程中形象设计进去的一个能力。
运行时白屏化的目标是为了帮忙咱们洞察全链路灰度的流量匹配以及运行的行为。
咱们基于流量路由的规定将运行时白屏化规定形象为如下：
WhiteScreenRule = Taget + Action**
Target：
- ResourceTarget: 指标接口，反对 Web、Rpc 以及自定义办法
- WorkloadTarget: 指标实例，能够抉择所有机器或指定机器 IP
- TrafficCondition: 是否仅针对异样、慢调用、全链路灰度标签
Action：
- 相干上下文诊断信息的收集
- 后续链路进行流量染色
- 后续链路是否日志打印
上面咱们来具体看一下如何使用运行时白屏化能力解决咱们在全链路灰度过程中遇到的问题。
灰度流量的匹配以及流向是否合乎预期
针对如上场景咱们只需配置 Zuul 利用入口的白屏化匹配规定即可：
咱们能够疾速察看到全链路中灰度流量的参数、返回值、headers 等特色属性。咱们也能够疾速发现全链路是否合乎预期以及定位不合乎预期的起因。
全链路之配置灰度
除了微服务实例和流量的灰度，微服务利用中的配置项也应该具备相应的灰度能力，以应答灰度利用对非凡配置值的诉求。
微服务利用通常会引入配置核心做配置管理，其提供动静的配置推送能力使得利用无需重启就能够动静地扭转运行逻辑。但配置核心的治理维度仅仅是配置项自身，并不能感知到前来获取配置的服务实例的环境信息，即无奈辨别申请配置的是正式环境的实例还是灰度环境的实例。在这种背景下，如果某项配置在正式环境和灰度环境中须要应用不同值，它们在配置核心中必须作为不同的配置项，咱们可能须要写出这样的代码：
...
if (env == "gray") {cfg = getConfig("cfg-1");
} else if (env == "gray2") {cfg = getConfig("cfg-2");
} else {cfg = getConfig("cfg-base");
}
...这一场景在 A/B 测试中十分常见。随着配置项和灰度环境的减少，这类代码还会反复许多次。此外，一套灰度环境中往往存在多个服务，每个服务都须要独立保护一套相似的代码。最终的解决方案如图所示，同一配置项在不同环境中应用的配置值须要在用户利用中被动进行辨别。
究其原因，还是来自于配置核心无奈感知服务实例的环境信息，使得咱们必须在代码中代替配置核心行使这一工作，从而导致了环境信息对业务代码产生了侵入。
针对这一问题，MSE 的配置标签推送性能将配置管理场景下的环境信息的感知下沉到平台侧，由 Agent 负责。用户只需接入 MSE，就可轻松在全链路灰度场景中应用配置推送能力，免去业务代码中繁琐的环境信息检测逻辑。如图所示：
具体操作步骤能够参考微服务治理实战派：https://help.aliyun.com/pract…
步骤一：还原线上场景
咱们将部署 spring-cloud-zuul、spring-cloud-a、spring-cloud-b、spring-cloud -c 四个业务利用和注册核心 Nacos Server。其调用链路如下：
这些利用都是最简略的 Spring Cloud 和 Dubbo 利用，您能够在下方链接获取到我的项目源码：
https://github.com/aliyun/ali…
登录 MSE 治理核心控制台，在左侧导航栏单击 利用治理，输出 cfg-spring-cloud-a，点击搜寻图标。抉择 cfg-spring-cloud-a 利用卡片，可进入利用详情页面。
接着在左侧导航栏抉择 利用配置 > 配置列表，点击开关 configValue 前的 +，能够看到此时 A 利用中基线版本和灰度版本的配置值雷同，均为利用中的初始值。
步骤二：配置利用 spring-cloud-a 的灰度规定
在 cfg-spring-cloud-a 的利用详情页中，抉择左侧导航栏的 流量治理 ，点击 标签路由。如图：
接着咱们为灰度实例配置灰度规定。点击 标签 gray > 流量规定 > 增加，配置如下的灰度规定，点击确定。
步骤三：验证配置灰度
接下来咱们来验证配置灰度。
1. 对灰度实例执行标签推送
回到 cfg-spring-cloud-a 的利用详情页的 利用配置 > 配置列表 ，选择开关 configValue 后的 按标签推送。在弹窗中抉择标签 gray，并设置灰度环境中的配置值。
之后点击 下一步：值比照 ，再点击 标签推送，实现推送。此时在管制台上能够看到灰度实例的配置值曾经变为了咱们刚刚设置的值。**
2. 验证配置灰度失效
登录容器服务控制台，点击左侧导航栏的 集群 ，进入部署了利用的集群。在集群详情页中抉择 网络 > 服务，找到 zuul-slb，点击其内部端点，拜访服务调用页面。
输出 /A/a，能够拜访到基线版本的 A 利用，能够看到其配置值仍为初始值。
输出 /A/a?name=xiaoming，能够通过刚刚配置的灰度规定拜访到灰度版本的 A 利用，能够看到其配置值曾经变为了咱们刚刚推送的值。
3. 验证灰度配置值的持久性
标签推送的配置值是长久化的。这意味着即便灰度环境中的利用重启也能主动从 MSE Agent 获取到之前推送的配置值。
登录容器服务控制台，点击左侧导航栏的 集群 ，进入部署了利用的集群。在集群详情页中抉择 工作负载 > 无状态 。勾选 spring-cloud-a-gray 负载，点击 批量重新部署。您也能够应用 kubectl 工具进行负载重部署，模仿灰度利用重启的过程。
利用重启实现后，从新执行上一步中拜访灰度利用的流程，能够发现配置值依然为之前推送的配置值。
总结
本文介绍了基于全链路灰度延长进去的运行时白屏化、配置灰度等能力，欠缺全链路灰度的场景，进一步晋升了全链路灰度的易用性。全链路灰度是微服务治理中比拟重要的一个场景，MSE 的全链路灰度能力还在随着客户场景的深刻而一直扩大与迭代，咱们须要继续地投入把这样一个重要的场景做深做透做到更加易用，能够预感的对于全链路灰度能力的打磨咱们还有很多的路要继续摸索，目前全链路灰度曾经有近百家企业应用，咱们始终置信只有通过客户继续打磨的产品才会愈发历久弥新。如果您也感兴趣，欢送应用与体验。
MSE 云原生网关预付费、MSE 注册配置预付费首购 8 折，首购 1 年及以上 7 折。点击浏览此处，即享优惠！