IT老齐架构300讲笔记(035) 蓝绿、红黑、灰度发布

目录

一、蓝绿、红黑、灰度发布概念区别

1.蓝绿部署

2.红黑部署

3.灰度发布

二、灰度发布遇到的挑战1 考虑数据库变更对旧版本的兼容性影响

2.1 方案一:放弃灰度,采用红黑方式全量发布

2.2 方案二:考虑独立部署数据源进行迁移

三、灰度发布遇到的挑战2 灰度发布用户群的选择

四、灰度发布遇到的挑战3 什么时候才可以提升分配比例

专栏链接:IT老齐架构300讲笔记专栏


一、蓝绿、红黑、灰度发布概念区别

科学部署的意义

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

IT老齐架构300讲笔记(035) 蓝绿、红黑、灰度发布_第1张图片

1.蓝绿部署

IT老齐架构300讲笔记(035) 蓝绿、红黑、灰度发布_第2张图片

IT老齐架构300讲笔记(035) 蓝绿、红黑、灰度发布_第3张图片

IT老齐架构300讲笔记(035) 蓝绿、红黑、灰度发布_第4张图片

2.红黑部署

IT老齐架构300讲笔记(035) 蓝绿、红黑、灰度发布_第5张图片

蓝绿部署相比,红黑部署可以充分利用了云计算的弹性伸缩优势,从而获得了两个收益:

一是,简化了流程

二是,避免了在升级的过程中,由于只有一半的服务器提供服务,而可能导致的系统过载问题 

3.灰度发布

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

IT老齐架构300讲笔记(035) 蓝绿、红黑、灰度发布_第6张图片IT老齐架构300讲笔记(035) 蓝绿、红黑、灰度发布_第7张图片

IT老齐架构300讲笔记(035) 蓝绿、红黑、灰度发布_第8张图片

二、灰度发布遇到的挑战1 考虑数据库变更对旧版本的兼容性影响

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

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

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

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

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

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

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

2.1 方案一:放弃灰度,采用红黑方式全量发布

2.2 方案二:考虑独立部署数据源进行迁移

为新旧版本分配独立的数据源,但新旧数据源之间数据同步会更考验架构师与DBA的智慧

三、灰度发布遇到的挑战2 灰度发布用户群的选择

灰度发布用户群的选择

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

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

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

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

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

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

四、灰度发布遇到的挑战3 什么时候才可以提升分配比例

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

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

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

IT老齐架构300讲笔记(035) 蓝绿、红黑、灰度发布_第9张图片

你可能感兴趣的:(架构,中间件,IT老齐架构300讲笔记,DevOps,架构,部署,DevOps)