dubbo文档_基于Dubbo的灰度发布

前言

保证系统的高可用和稳定性是互联网应用的基本要求。需求变化、版本迭代势必会影响系统的稳定性和可用性，如何兼顾需求变化和系统稳定呢？这个影响它的因素很多，发布是其中一个。我们要尝试尽可能让发布平滑、让新功能曝光、影响人群由少到多和由内部到外部、一旦有问题马上回滚等。

灰度发布

什么是灰度发布？看看百度百科的解释：灰度发布(又名金丝雀发布)是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。灰度发布开始到结束期间的这一段时间，称为灰度期。

这个解释很到位。

Dubbo 对灰度发布的支持

实现灰度发布，就要在请求到达服务提供者前，能将请求按预设的规则去访问目标服务提供者。要做到这一点，就要在消费端或者在服务集群之前的类似网关这样的中间层做好路由。我们知道Dubbo调用是端到端的，不存在一个中间层，所以，在Dubbo的消费端就要做好请求路由。我们先看一下Dubbo的调用链路，如下图

Dubbo调用链路——来自Dubbo官网

如上图所示，在Dubbo消费端，已经做了负载均衡了，但负载均衡不能满足我们对请求的路由需求。其实在负载均衡之前，invocation会先经过一个路由器链并返回一组合适的目标服务器地址列表，然后在这些备用的服务器地址中做负载均衡。源码如下：

AbstractClusterInvoker.invoke

所以只需要增加一个路由器，在路由器定义灰度的规则，就可以实现灰度发布了。

Dubbo原生已经按这种思路做了路由的支持了，它现在支持两种路由方式：条件路由、标签路由。

条件路由主要支持以服务或Consumer应用为粒度配置路由规则，源码对应的路由器是ConditionRouter.java。

标签路由主要是以Provider应用为粒度配置路由规则，通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，对应源码路由器是TagRouter.java。

具体的规则可以查阅文档：http://dubbo.apache.org/zh-cn/docs/2.7/user/demos/routing-rule/

Dubbo原生路由器支持的场景其实已经很丰富的了，比如条件路由器，可以设置排除预发布机器、指定Consumer应用访问指定的Provider应用，这其实就是蓝绿发布，还能设置黑白名单、按网段访问等等。但是这有一些问题，谁来管理这些规则，什么时候来管理。标签路由问题就更大一些，在配置了标签之后，还要侵入代码写入标签，至少也要在启动参数加上这个标签。使用是比较麻烦的。现在很多公司已经在落地Devops，或者使用商业开发平台如EDAS，有的也会搭建自己的运维平台，发布流程都在追求自动化、半自动化，所以易用性很重要。实现一个流畅的灰度发布流程，我们希望它能有一个统一的运维平台，能支持条件路由和权重路由，可以随时监控、回滚、或者继续发布。这样，我们有必要自定义一个路由器，并将其融入发布流程中。

自定义路由器

上篇文章我们介绍了Dubbo SPI的实现，这让Dubbo的扩展成本非常低，我们只需定义自己的路由器并把整合到应用就可以了，路由扩展文档请查阅文档：http://dubbo.apache.org/zh-cn/docs/2.7/dev/impls/router/

自定义路由器就叫GrayRouter吧，规划一下它的功能，如下图

GrayRouter功能

灰度路由器是以provider应用为粒度配置路由规则的，包含两个过滤器，条件过滤器和权重过滤器(不是Dubbo的过滤器)，它们的主要任务根据配置过滤出备用provoider。配置信息放在分布式配置上，首次加载放入应用缓存，一旦有变更将自动更新。这样在发布时可以动态调整灰度参数，达到逐步扩大流量和影响人群的目的。下面是路由器的主要实现代码

发布流程可视化

监控

我们使用了Skywalking做应用性能监控，下图是一个有两个节点的应用，灰度发布配置了权重发布，权重值10(全部是100)，灰度流量分布效果如下图

结束

灰度发布在版本迭代中给系统稳定提供了有力的保证，应该将其纳入到发布流程中。