版本发布方式
一、全量发布
1.1 蓝绿发布
部署两个常驻集群A、B,由A承载日常流量,B作为冷备份;
发布时,流量整体切到B,先对A升级,A升级完后,再将流量整体切到A;
再升级B;
当然可以灵活部署,比如我司XBos就是使用的这套的变体方案:
如上图:XBos采用的是,A、B两个常驻集群;
A负责承载日常业务流量;
B接受日常的频繁特性变更,方便交付在生产环境验证;
B上的新特性全部验证后,发版日短暂地将流量整体切到B;
然后将B上的特性变更同步到A;
最后将流量整体切回A;
1.2 红黑发布
部署一个常驻集群A,承载日常流量,无冷备份;
发布时,用新版代码弹性部署一个集群B,再将流量整体切到B;
弹性回收集群A;
比较:
1.充分利用云计算的容器化、虚拟化带来的伸缩能力,更快速。
2.流程更简单,网关切换次数更少;
3.不需要象蓝绿那样,将全量计算资源一分为二,集群始终都使用着全量计算资源,不需要蓝绿那样要避开业务高峰期升级。
实践中,可以两者结合;
在fygs项目交付早期,采用的就是蓝绿发布,A集群做冷备,且发布窗口开得密集,主要用于特性验证,通过后再同步到B集群。
但同时利用CI/CD,Kubernets,Dev/Ops的方式。
二、增量发布
2.1 灰度发布(金丝雀)
部署一个常驻集群A,承载日常流量,无冷备份;
发布时,新版本代码部分替换A集群中的应用副本;
观察新副本接受流量后是否正常,如果正常,再扩大替换的副本数,直至全部替换。
注意:
1.针对改动较大的版本升级,比如DML,或者RPC接口改动较大,代码层面必须做好新老兼容。
2.用户量请求的分批时,必须考虑一致性路由。
3.分批切换的时机必须配合良好的监控,否则会有风险。
总体来说适合新的、体量较小、追求快速迭代的项目。
学习使我充实,分享给我快乐!