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