什么是蓝绿，红黑，灰度发布

一 理解蓝绿、红黑部署与灰度发布的区别

科学部署的意义;

尽可能减少服务停机时间,控制新版本带来的质量风险.

流程:

1. 版本集群A和B最开始都是1.0版本，遇到新版1.1时
2. 在网关根据规则，将流量全部引入B
3. 对集群A进行升级
4. 网关配置，流量重新引入集群A
5. 流量从B切断，更新B
6. 流量重新引入B
7. 升级完成

蓝绿部署在切换过程中，只有一半的资源在工作。

流程：

1. 新版本需要部署，原集群不做任何操作
2. 新建新集群B，版本为1.1
3. 流量引入B
4. A集群下线

与蓝绿部署相比，红黑部署可以充分利用了云计算的弹性伸缩优势，从而获得了两个收益：一是，简化了流程；二是，避免了在升级的过程中，由于只有一半的服务器提供服务，而可能导致的系统过载问题。

二 灰度发布会遇到哪些挑战？

灰度发布

灰度发布，也被叫作金丝雀发布。与蓝绿部署、红黑部署不同的是，灰度发布属于增量发布方法。也就是说，服务升级的过程中，新旧版本会同时为用户提供服务。

灰度发布遇到的挑战：

1. 考虑数据库变更对旧版本的兼容性影响

例如：某数据表有ab两个字段

程序猿小甲的SQL是： insert into t values(‘a’,’b’);

但v1.1版本中在数据表增加了c字段，就版本运行就会报错

因此在考虑未来灰度发布的情况，要求团队成员写SQL必须明确字段

insert into t(a,b) values(‘a’,’b’);

TIPS:任何删除、更新字段信息的操作都要格外谨慎

1. 对于新旧版本无法协同作业的情况

方案二（了解一下即可，项目几乎不会考虑）

可以考虑独立部署数据源进行迁移

为新旧版本分配独立的数据源

但新旧数据源之间数据同步会更考验架构师与DBA的智慧

灰度发布遇到的挑战2

1. 灰度发布用户群的选择

不能直接采用类似于Nginx的权重Weight

会导致一个用户不同请求在新旧版本间反复横跳，出现无法预期的Bug

解决方法：利用Nginx + Lua脚本化

基于IP或者UA等用户稳定特性然后Hash取模来决定访问新旧版本

Hash(192.168.31.102) % 10 = 7 #送给旧版本

Hash(192.168.31.108) % 10 = 9 #送给新版本

灰度发布遇到的挑战3

1. 什么时候才可以提升分配比例

在发布过程中，我们应该注意监测用户请求失败率、用户请求处理时长和异常出现数量这几个信息，以保证快速发现问题并及时回滚。

在灰度发布的时候，可以部署相对较小的集群，让集群保持在高压力确认新版应用的性能情况，之后再酌情进行扩容。

TIPS：推荐了解下SkyWalking，国产开源监控系统，简单粗暴