浅谈服务发布方式（蓝绿部署、金丝雀发布、滚动升级）

浅谈服务发布方式（蓝绿部署、金丝雀发布、滚动升级）

最近由于其他依赖服务升级的问题导致我们的项目大面积不可用，造成了较大的损失，因此仔细梳理了一下服务升级的方式。这几种方式各有优点，可以根据自己当前项目的现状，选择合适的部署方式，以最小的代价完成服务的升级。

蛮力发布

传统发布升级，手动将要升级的服务替换。

适合场景：

1. 服务单节点部署。
2. 服务数量少。
3. 服务中断对于业务没多少影响。
4. 新旧版本的代码可以不兼容，改动可以很大。

注意事项：

1. 手动升级在服务多的时候会非常繁琐。
2. 升级时候会有服务中断。
3. 原始版本的软件包需要备份，以防出现问题需要回滚。
4. 升级失败的回滚可能浪费大量时间。

蓝绿部署

图示：

将新版本的服务部署在另一组服务器上，升级的时候切换流量到新的服务上，完成升级。
如果新版本的服务出现问题，流量切换回去就可以快速完成回滚。

适合场景：

1. 服务器资源充足
2. 用户无感知
3. 版本升级代码差距很大，可以防止出现不一致问题

注意事项：

1. 需要的服务器资源多一倍。

滚动升级

图示：

每次只升级一个或者多个服务，不断执行这个过程，直到升级完成。

适合场景：

1. 用户体验要求较高
2. 服务器资源紧张
3. 部署的自动化程度较高

注意事项：

1. 在升级过程中有些节点可能升级失败，到时候无法确认正常的环境，不易回滚
2. 部署时间慢，取决于每个阶段的时间
3. 发布策略较为复杂。
4. 升级代码改动较大，可能会存在一致性问题

金丝雀发布（灰度发布）

图示：

只升级一部分服务，让一部分用户使用新的环境，一部分用户使用老的环境。如果升级成功，没什么问题，逐渐全部升级；如果升级出现问题，只影响一部分的用户，可以进行回滚。

适合场景：

1. 用户体验要求较高
2. 服务器资源紧张
3. 自动化程度较高

注意事项：

1. 升级代码改动较大，可能会存在一致性问题。