之前一直没有玩过灰度发布，这次单位业务有这个需求，所以来研究一下。

======================服务灰度发布===================

灰度发布:黑白之间，平滑过渡。可以有多种具体的实现方式，主要是一种思想。

AB-Test:是其中1种灰度发布方案，一部分用户继续用A,另外一部分用户继续用B，如果这些用户对B没有问题，则逐步扩大范围，把所有用户都迁移到B上来。

为什么要使用灰度发布:可以保证整个系统的稳定,在初始灰度的时候就可以及时发现问题，止损，保证影响度。

===服务灰度发布的流程设计===

主要作用如下：

1)解决服务升级不兼容的问题

2)完善系统，提高质量

3)降低升级风险

4)及早参与产品测试

 

下面，我们来具体的看看流程具体要怎么做！

=====================================

1）灰度环境准备

首先，需要对灰度环境进行划分、隔离和准备，流程如下:

1.1)登录服务治理的灰度发布界面.

1.2)圈定本轮灰度发布的范围，通常是一个集群。

1.3)范围信息保存到服务注册中心

1.4)通知灰度升级范围内的服务实例下线,通常采用优雅停机的方式让待升级的服务下线 .保证升级不中断业务。

1.5)进程收到优雅停机指令后,优雅退出。

1.6)从软件仓库选择需要升级的服务安装镜像包,用于版本升级。

1.7)将包上传到灰度环境中，升级服务版本

1.8)完成以后,返回灰度环境部署成功消息给灰度发布管理控制台，进行后续操作。

 

这样，基本准备工作就做好了，其实就是在灰度发布的机器上启动了新版本的进程。

 

2）灰度规则设置

环境准备完成以后，这个时候，运维人员可以对灰度的规则进行设置了，这个规则主要用于服务路由。

按照规则的不同，一部分用户调用老的服务，一部分用户调用新的服务。

常用的灰度规则可以有如下几种:

1)按照接入类型分类: 网上营业厅，手机客户端等.

2)终端类型:Android,IOS,Windows Phone.

3)按照区域划分: 各个地方

4)其它...

通常，服务框架会提供几种默认的灰度规则，用户也可以自定义规则。

技术实现有很多种,支持复杂规则可以用规则引擎，简单的可以用表达式，或者JSON文本；

 

具体使用什么技术，需要看应用场景，

一种比较好的策略是：服务框架不限制灰度规则的具体实现技术，支持用户自定义灰度规则。

 

3）灰度规则下发

灰度规则完成后，需要将规则下发给SLB,或者web前台和后台服务，谁需要就下发给谁。

主要由服务注册中心负责推送，推送给所有相关的服务器节点。

 

各个节点将灰度规则缓存到本地内存中，通过路由插件解析灰度规则，将请求路由到指定的版本。

 

需要指出的是：灰度规则的通知范围是整个生产环境集群，包括灰度发布环境和非灰度发布环境。

 

4）灰度路由【开始执行】

通过SLB定制的灰度发布插件，可以将HTTP消息分发到不同的web前台

web前台根据内置的服务框架SDK,通过灰度路由插件，解析灰度规则，将服务路由到灰度发布或者非灰度环境，实现服务的灰度路由。

 

如果无法判定走灰度还是非灰度，一律走老的软件版本，不应该走新的版本。

 

如果新的版本无法提供服务，需要对灰度做回滚处理。

 

5）灰度回滚

如果灰度升级失败，需要支持失败回滚。

可以是全自动，也可以是人工干预，看平台的自动化程度。

 

6)灰度总结

一言以蔽之，就是需要对灰度服务进行业务API级别的监控。

 

7）全局总结

互联网的产品不停的升级，版本升级伴随着不同的风险。

为了避免这些风险，很多产品采用了灰度发布的策略，主要思想就是把影响集中到1个点，然后再发散到一个面，出现意外则回滚。

 

分布式服务框架支持服务的灰度发布，可以实现业务的快速试错和交付，非常重要。！