
218
|
第
16
章
证构建是否已准备好进行部署。然而,部署本身并不是自动化的,需要服务所有者一方进
行一些人工干预。
持续部署
是构建的自动化部署。在一个端到端的持续部署流程中,提交的代码变更通过持
续集成管道传播,到达一个可交付状态,然后根据部署配置自动部署到生产环境。这有助
于时间紧张的开发迭代,因为提交的变更可以很快进入生产环境。
图
16-1
展示了持续交付和持续部署之间区别的持续集成管道。
1) 提交代码
2) 单元测试
和集成测试
3) 部署前
验证
4) 部署
5) 部署后
验证
持续交付:人工部署
持续部署:自动化部署
图 16-1:展示持续交付和持续部署之间区别的持续集成管道
持续部署在实践中是很难的。有状态的服务特别有挑战性,因为部署可能需
要重建状态存储及再处理事件流,这对依赖服务尤其具有干扰性。
16.2.2
CMS
和商业硬件
CMS
提供了管理、部署和控制容器化应用程序资源的方法(参见
2.9.3
节)。在持续集成
过程中构建的容器被存放到容器库中,在那里它等待
CMS
的
部署指示。持续集成管道和
CMS
之间的集成对于流水化部署过程至关重要
,如第
2
章所述,大部分领先的
CMS
供应
商提供了这个功能。
商业硬件通常用于部署事件驱动型微服务,因为它价格便宜、性能可靠,并且支持服务的
水平伸缩。可以根据需要在资源池中添加和删除硬件,而恢复故障实例只需要将发生故障
的微服务实例重新部署到新硬件。虽然你的微服务实现可能会不同,但事件驱动型微服务
不需要操作任何特殊的硬件。如果真的需要操作,可以将专门的资源分配到它们自己的独
立池中,这样就可以相应地部署相关的微服务了。这样的例子包括用于缓存目的的内存密 ...