知识卡片

事件链式流转:微服务在发布方与订阅方角色间连续切换

普通读书笔记卡

内容

书中用保险承保流程说明领域事件如何驱动业务在多个微服务间流转:客户投保、生成投保单后,投保微服务生成缴费通知单、发布第一个事件”缴费通知单已生成”到消息中间件;收款微服务订阅这个事件、完成缴费,然后发布第二个事件”缴费已完成”——这时收款微服务从”事件订阅方”变成了”事件发布方”,而原来的发布方投保微服务则反过来变成了订阅方,接收到缴费完成信息后完成投保单转保单;投保单转保单完成后,投保微服务再发布第三个事件”保单已生成”,由保单微服务订阅接收、完成保单数据保存;保单数据保存后,还会继续以并发方式把保单事件发送给佣金、收付、再保、财务等一系列微服务,完成后续所有业务流程。这个链条揭示了一种没有中心指挥、完全靠事件驱动串联起来的协作模式(编排学界称为”编排式”或choreography):没有一个统一的”总控制器”来指挥整条流程该先做什么后做什么,每个微服务只需要关心”我订阅了哪些事件、我处理完之后要发布什么事件”,整条业务流程的顺序和走向,是靠一连串局部的发布订阅关系自然拼接出来的,这样的设计天然具有可扩展性:只要新增一个订阅者去监听某个已有事件,就能在不改动上游发布方代码的前提下,给流程接入新的后续处理环节。

参考来源

- 位置:第9章《领域事件:解耦微服务的关键》"9.2 领域事件案例"(源文件:_epub-src/OEBPS/Text/chapter3-5-2.xhtml) - 结论依据:原文说明"投保微服务生成缴费通知单,发布第一个事件:缴费通知单已生成……收款微服务缴费完成后,发布第二个领域事件:缴费已完成……原来的事件订阅方收款微服务这时则变成了事件发布方。原来的发布方投保微服务这时转换为缴费已完成事件的订阅方……投保微服务在投保单转保单完成后,发布第三个领域事件:保单已生成",直接支撑本卡片结论。 - 原始内容:收款微服务缴费完成后,发布第二个领域事件:缴费已完成。将缴费事件数据发布到消息中间件。原来的事件订阅方收款微服务这时则变成了事件发布方。原来的发布方投保微服务这时转换为缴费已完成事件的订阅方。