版本发布方式

一、全量发布

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.分批切换的时机必须配合良好的监控，否则会有风险。

总体来说适合新的、体量较小、追求快速迭代的项目。