服务发版常见的三种方式

项目迭代的过程中，需要将软件从测试阶段顺利推进到生产环境，这个过程要确保系统可以正常的提供服务，我们需要避免服务中断和流量损失，还要有风险意识，部署对应着修改，修改则意味着风险。

为了规避和解决上述问题，下面介绍几种在常见的发布策略：蓝绿发布、灰度发布和滚动发布。

1、蓝绿发布（有钱玩法，回滚速度快）

项目上分为AB组，是两个分开的集群（集群上运行的版本是一致的），同时对外提供服务，在项目升级时，老版本不完全停止，把A组从负载均衡中摘除，进行新版本V2的部署。B组仍然继续提供服务（这里定义为V1版本）， 确认OK后将流量切到新版本，然后老版本同时也升级到新版本，最后要保持两个集群是一致的。

先下掉A组，流量都转到B组，A组发版新的代码V2版本

当A组升级完毕，负载再重新接入A组，同时下掉B组，确定A服务新版版没问题之后，B组进行新版本的部署

最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。

在部署期间，老的应用始终在线，老版本的状态不受影响，这样风险很小。并且只要老版本的资源不被删除，新版版有问题可以立刻回滚到老版本

• 优点 升级切换和回退速度非常快。
• 不足
  切换是全量的，如果V2版本有问题，则对用户体验有直接影响。需要两倍机器资源，需要考虑下线某一组的时候，另外一组的流量是否能单独扛得住

2、灰度发布

灰度发布，也叫作金丝雀发布。灰度发布只升级部分服务，让一部分人先用起来，也就是说，服务升级的过程中，新旧版本都会为用户提供服务，没问题在全部放开。

• 优点 升级功能是逐步开放，如果有问题，可以降低影响范围
• 不足
  自动化要求高，操作不甚可能会引发服务中断 增加了流量转发的控制逻辑实现难度，不同的架构处理情况各不一

3、滚动发布（最常用的）

滚动发布每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级为新版本。（最原始的多个服务实例一个个的去手动发布重启），在这个过程需要考虑到老版本下线的控制，不能在让现有流量打到老的服务上去，主要是有注册中心的，需要安全的下线之后，在进行部署的操作

部署过程：

• 滚动式发布一般先发1台，或者一个小比例，主要做流量验证用，类似金丝雀 (Canary) 测试，确定新版本服务是否是正常的

• 滚动式发布需要比较复杂的发布工具和智能 LB，支持平滑的版本替换和流量拉入拉出。

• 每次发布时，先将老版本V1流量从LB上摘除，然后清除老版本，发新版本V2，再将LB流量接入新版本。这样可以尽量保证用户体验不受影响。

• 一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀 10 分钟，后续间隔 2 分钟)。

• 回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的。

• 优点 用户体验影响小，体验较平滑； 节约资源。

• 不足
  发布和回退时间比较缓慢。
  无法确定正常的环境，回滚困难。 发布比较复杂，LB 流量上下线的需要比较平滑能力。