浅谈服务发布方式（蓝绿部署、金丝雀发布、滚动升级）
最近由于其他依赖服务升级的问题导致我们的项目大面积不可用，造成了较大的损失，因此仔细梳理了一下服务升级的方式。这几种方式各有优点，可以根据自己当前项目的现状，选择合适的部署方式，以最小的代价完成服务的升级。
蛮力发布
传统发布升级，手动将要升级的服务替换。
适合场景：
- 服务单节点部署。
- 服务数量少。
- 服务中断对于业务没多少影响。
- 新旧版本的代码可以不兼容，改动可以很大。
注意事项：
- 手动升级在服务多的时候会非常繁琐。
- 升级时候会有服务中断。
- 原始版本的软件包需要备份，以防出现问题需要回滚。
- 升级失败的回滚可能浪费大量时间。
蓝绿部署
图示：
将新版本的服务部署在另一组服务器上，升级的时候切换流量到新的服务上，完成升级。
如果新版本的服务出现问题，流量切换回去就可以快速完成回滚。
适合场景：
- 服务器资源充足
- 用户无感知
- 版本升级代码差距很大，可以防止出现不一致问题
注意事项：
- 需要的服务器资源多一倍。
滚动升级
图示：
每次只升级一个或者多个服务，不断执行这个过程，直到升级完成。
适合场景：
- 用户体验要求较高
- 服务器资源紧张
- 部署的自动化程度较高
注意事项：
- 在升级过程中有些节点可能升级失败，到时候无法确认正常的环境，不易回滚
- 部署时间慢，取决于每个阶段的时间
- 发布策略较为复杂。
- 升级代码改动较大，可能会存在一致性问题
金丝雀发布（灰度发布）
图示：
只升级一部分服务，让一部分用户使用新的环境，一部分用户使用老的环境。如果升级成功，没什么问题，逐渐全部升级；如果升级出现问题，只影响一部分的用户，可以进行回滚。
适合场景：
- 用户体验要求较高
- 服务器资源紧张
- 自动化程度较高
注意事项：
- 升级代码改动较大，可能会存在一致性问题。