之前一直没有玩过灰度发布，这次单位业务有这个需求，所以来研究一下。
======================服务灰度发布===================
灰度发布:黑白之间，平滑过渡。可以有多种具体的实现方式，主要是一种思想。
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个点，然后再发散到一个面，出现意外则回滚。
分布式服务框架支持服务的灰度发布，可以实现业务的快速试错和交付，非常重要。！
3116
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
