灰度发布是指在 黑和白(0和1)之间，能够平滑过渡的一种发布方式。

AB test就是一种灰度发布方式，指为产品已发布A版本，在发布B版本时，在同一时间维度， 让一部分用户继续用A版本，一部分用户开始用B版本，如果用户对B版本没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B版本上面来。灰度发布可以保证整体系统的稳定，在初始灰度发布时就可以发现及调整问题，以保证其影响度。

针对我们当前现状，使用灰度发布的背景： 在目前app完成测试，准备上线发布时候，就需要运维支持了，其中的挑战点在于如何不影响当前在线业务的情况下来进行升级。 系统升级就会有风险，系统宕机风险，用户使用习惯改变而造成用户流失的风险，服务错误不可用等等风险。 利用灰度发布， 降低发布带来的影响，虽然功能都在test环境测过，但毕竟没发布到prod环境，如果先让少部分用户先使用新版本，提前发现bug，或者性能问题，提前做好修复，就可以降低新版本带来的影响。 其主要思想就是把影响集中到一个点，然后再发散到一个面，出现意外情况后很容易就回退，即使影响也是可控的。

灰度发布的主要分类：

1）金丝雀发布 金丝雀发布成本较低，只需要一个实例即可降低新版本存在的风险，适合缺乏足够的发布工具研发能力及成长型的小公司。但是，金丝雀发布也有缺点，当升级全部剩余实例时，如果流量过多，可能会导致服务中断。

2）滚动发布 滚动发布则是在金丝雀发布的基础上进行的改进和优化，第一次也是使用金丝雀发布，后续则使用多批次的形式发布剩余实例，每次批次之间会进行观察，如果有问题，再进行回滚。

3）蓝绿发布

蓝绿发布比较简单，只是对全量发布的一种优化而已，发布前不用全部停机，而是另外部署新版本全部实例，然后再把流量全部再切换到新版本。

全量发布：不建议使用

蓝绿发布：适合于对于资源预算比较充足的业务，或者是比较简单的单体应用，可以快速实现系统的整体变更

金丝雀和全链路灰度：适合需要针对特定用户或者人群进行现网请求验证的业务，可以显著减低风险

综上，建议选择 金丝雀或者全链路灰度 进行服务的升级发布。

用户请求————> 网关----->服务a----->服务b 1、用户会发送请求 2、经过网关分发请求到具体的服务A 3、服务A 调用服务B [图片] 灰度发布的核心就是路由转发，如果我们能够自定义网关到 服务A 及 服务A到服务B中间的路由策略，就可以实现用户引流，灰度发布。

通过网关寻找下层服务之前，通过拦截器处理请求头的参数信息，通过判断Redis数据当前请求是否符合灰度的要求，如果符合，走灰度服务；否则走正常服务。

原理：使用nginx做负载均衡和反向代理，nginx内嵌lua模块，解析并执行lua编写的脚本逻辑，可以通过lua解析cookie以及访问redis，而一些灰度发布分流的策略就是放在redis里通过cookie关联

执行过程：

OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项，用于方便地搭建能够处理高并发、高扩展性的动态 Web 应用、Web 服务和动态网关。 Http协议的灰度功能主要基于ngx_http_lua_module模块实现，Tcp协议的灰度功能主要基于ngx_stream_lua_module模块实现。

本系统实现了对Http协议和Tcp协议的灰度功能，并且提供后台管理系统对灰度白名单进行管理。 三种方式灰度实现： Http协议灰度实现如下功能：

说明： 1、当用户请求到达前端web（代理）服务器Openresty，内嵌的lua模块解析Nginx配置文件中的lua脚本代码； 2、Lua获取客户端IP地址、userId和设备ID，去查询Redis中是否有该键值，如果有则转发到灰度环境，否则转发到生产环境中； 3、后端管理系统提供可视化界面，可以管理redis中的白名单信息，包括：客户端IP白名单、userId白名单、设备Id白名单。