在现实应用中，开发者会频繁地部署服务，并需要能够在不停机的情况下部署新版本服务来保持应用的整体稳定性。因为每个服务的正常运行依赖于其他服务，所以还需要最大限度地提高每个服务的可用性。
不停机部署有3种常见的部署模式。
（1）滚动部署：在启动新实例（版本为N+1）时，逐步将旧实例（版本为N）从服务中剔除，确保在部署期间最小比例的负载容量得到保证。
（2）金丝雀部署：开发者在服务中添加一个新实例来验证N+1版本的可靠性，然后再全面推出。这种模式在常规滚动部署之外提供了附加安全措施。
金丝雀部署的每个阶段
向实例组中添加一个金丝雀实例，后端服务开始接受请求。
如果没有问题的话，可以继续执行滚动更新，更新速度取决于在滚动更新时期望保留多大的服务能力。
如果不满意的话，可以将金丝雀实例回滚。回滚命令和滚动部署命令是相同的，不过它用的是之前的版本。在现实世界中，回滚可能并不是原子化的。比如，对新实例执行错误操作可能会导致数据处于不一致的状态，这就需要人为干预和协调。发布小规模的变更并积极监控新发布版本的功能能够降低这些情况的发生和范围。
（3）蓝绿部署：创建一个运行新版本代码的并行服务组（绿色集合），开发者逐步将请求从旧版本（蓝色集合）中转移出去。在服务消费者对错误率高度敏感、无法接受不健康的金丝雀风险的情况下，这种方法比金丝雀部署模式更有效。
所有这些模式都是基于简单的操作构建的。开发者获取一个实例，在环境中运行该实例，并将流量导向该实例。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
