成熟的部署方案对于构建可靠且稳定的微服务是至关重要的。微服务部署和单体应用部署是不同的。在单体应用中，可以针对单个用例(功能场景)优化部署方案，而微服务的部署方案需要扩展到多个服务，而这些服务可能是用不同的编程语言实现的，并且可能各自有自己的外部依赖。
由于微服务应用是以部署单元级别进行演进的，因此部署新服务的成本必须小到可以忽略不计，能够让工程师快速创新、引进新内容并向用户交付价值。如果不能快速且可靠地将微服务部署到生产环境中，那么微服务方案所提高的开发速度就会被浪费掉。自动化的部署方案对于大规模微服务开发而言是必不可少的。
在软件系统的生命周期中，部署是风险最大的时刻。和现实世界最贴切的类比就是换轮胎——而且这辆车还在以约160km/h的速度飞驰着。没有哪个公司能够不受这一风险的影响：比如Google的网站可靠性(site reliability)团队认为大概有70%的服务不可用是由于对生产环境的修改导致的。
微服务极大地增加了系统中活动部件的数量，从而增大了部署的复杂性。在部署微服务时，开发者将面临四大挑战：
1）面对大量的发布和组件变更时应保持稳定性；
2）避免会导致组件在构建阶段或者发布阶段产生依赖关系的紧耦合；
3）服务API发布不兼容的变更可能会对客户端产生非常大的负面影响；
4）服务下线。
如果做得好，部署方案都是基于简单性和可预测性而实现的。相同的构建流水线生成的工件都是可预测的，开发者可以将其自动应用到生产环境中。
小版本发布降低风险和提高可预测性
发布的版本规模越大，引入故障的风险就越高。微服务发布的版本规模都是比较小的，因为它们的代码库更小一些。发布小版本的频率越高，开发者对每次变更产生的总体影响也就越小。不用为了部署而停止所有工作，开发者可以设计自己的服务和部署方案，并期望它们面临持续的变更。减少可能的暴露范围可以加快发布速度、简化监控工作，并且对应用的正常运行产生更小的干扰。
自动化推动部署节奏和一致性
即便部署版本的规模更小，开发者仍需确保这些变更集尽可能没有缺陷。开发者可以通过将提交验证的过程以及上线的过程自动化来实现。这有助于开发者对所做的代码改动有足够的信心并对多个服务采用同一套方案。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
