
部署事件驱动型微服务
|
217
产生大量输出事件,从而导致下游消费者的高负载。大型的事件流和那些有大量消费者
的事件流在处理启动需求时可能会出现不寻常的负载激增。还必须考虑到副作用,特别
是那些会对客户造成干扰的副作用(例如,重发多年之前的促销邮件)。
遵守 SLA
部署可能会干扰其他服务。例如,重建状态存储会产生大量的中断时间,再处理输入事
件流会产生大量事件。确保在部署过程中遵守所有
SLA
。
最小化依赖服务的变更
部署操作可能会要求其他服务变更它们的
API
或数据模型
,比如当用
REST API
进行交
互或引入领域
schema
变更时
。这些变更应该尽可能地最小化,因为它们侵犯了其他团
队的自主权,这些团队应该只在自身业务需求发生变化时才部署他们的服务。
与下游消费者协商破坏性变更
在某些情况下,破坏性的
schema
变更可能是不可避免的
,需要创建新的事件流并与下游
消费者重新协商数据契约。请确保在部署之前完成这些讨论,并为消费者制订迁移计划。
微服务应该是可独立部署的,如果不是则是反模式。如果一个特定的微服务
部署通常需要其他微服务同步进行部署,那么这预示着它们的界限上下文没
有被很好地定义,应该对其进行重新审视。
16.2
微服务部署的架构组件
微服务部署架构有几个主要组件,每个组件都起着关键作用。下面主要介绍用于构建和部
署代码的系统以及微服务所使用的计算资源。
16.2.1
持续集成系统
、
持续交付系统和持续部署系统
持续集成系统、持续交付系统和持续部署系统允许在将代码变更提交到代码库时构建、
测试和部署微服务。这是大规模成功管理和部署微服务必须要付 ...