微服务全链路灰度新能力-六虎

作者： 十眠、洵沐

布景

微服务体系架构中，服务之间的依靠联系扑朔迷离，有时某个功能发版依靠多个服务一起晋级上线。咱们希望能够对这些服务的新版别一起进行小流量灰度验证，这便是微服务架构中特有的全链路灰度场景，通过构建从网关到整个后端服务的环境阻隔来对多个不同版别的服务进行灰度验证。在发布过程中，咱们只需布置服务的灰度版别，流量在调用链路上流转时，由流经的网关、各个中间件以及各个微服务来辨认灰度流量，并动态转发至对应服务的灰度版别。如下图：

上图能够很好展示这种方案的效果，咱们用不同的色彩来表示不同版别的灰度流量，能够看出无论是微服务网关仍是微服务自身都需求辨认流量，根据管理规矩做出动态决议计划。当服务版别发生变化时，这个调用链路的转发也会实时改动。相比于运用机器搭建的灰度环境，这种方案不仅能够节省许多的机器本钱和运维人力，并且能够协助开发者实时快速的对线上流量进行精细化的全链路操控。

全链路灰度才能提升了微服务架构带来的快速迭代、稳定性验证的优势，给企业生产环境的体系带来了真真切切的好处。本文将着重介绍 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，就可轻松在全链路灰度场景中运用装备推送才能，免除事务代码中繁琐的环境信息检测逻辑。如图所示：

具体操作过程能够参考微服务管理实战派：help.aliyun.com/practice_de…

过程一：还原线上场景

咱们将布置 spring-cloud-zuul、spring-cloud-a、spring-cloud-b、spring-cloud -c 四个事务运用和注册中心 Nacos Server。其调用链路如下：

这些运用都是最简略的 Spring Cloud 和 Dubbo 运用，您能够在下方链接获取到项目源码：

github.com/aliyun/alib…

接着在左边导航栏挑选运用装备 > 装备列表，点击开关 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 的全链路灰度才能还在随着客户场景的深入而不断扩展与迭代，咱们需求继续地投入把这样一个重要的场景做深做透做到愈加易用，能够预见的关于全链路灰度才能的打磨咱们还有许多的路要继续探索，现在全链路灰度现已有近百家企业运用，咱们一直相信只要通过客户继续打磨的产品才会愈发历久弥新。假如您也感兴趣，欢迎运用与体验。

微服务全链路灰度新能力

布景