模板网站怎么修改,长沙创建一个网站需要多少钱,建设设计公司网站,网站开发前端与后端目录
1、概述
2、领域事件
2.1 如何识别领域事件
1.微服务内的领域事件
2.微服务之间的领域事件
3、领域事件总体架构
3.1 事件构建和发布
3.2 事件数据持久化
3.3 事件总线 (EventBus)
3.4 消息中间件
3.5 事件接收和处理
4、案例
5、总结 1、概述
在事件风暴Event Storming时我们知道除了命令和操作等业务行为以外还有一种非常重要
的事件这种事件发生后通常会导致进一步的业务操作在DDD中这种事件被称为领域事件。
那到底什么是领域事件领域事件的技术实现机制是怎样的
2、领域事件
领域事件是领域模型中非常重要的一部分用来表示领域中发生的事件。一个领域事件将导
致进一步的业务操作在实现业务解耦的同时还有助于形成完整的业务闭环。
举例来说的话领域事件可以是业务流程的一个步骤比如投保业务缴费完成后触发投保
单转保单的动作也可能是定时批处理过程中发生的事件比如批处理生成季缴保费通知
单触发发送缴费邮件通知操作或者一个事件发生后触发的后续动作比如密码连续输错
三次触发锁定账户的动作。
2.1 如何识别领域事件
在做用户旅程或者场景分析时我们要捕捉业务、需求人员或领域专家口中的关键词“如果发
生……则……”“当做完……的时候请通知……”“发生……时则……”等。
在这些场景中如果发生某种事件后会触发进一步的操作那么这个事件很可能就是领域事件。
那领域事件为什么要用最终一致性而不是传统SOA的直接调用的方式呢
聚合的一个设计原则在边界之外使用最终一致性。
一次事务最多只能更改一个聚合的状态。如果一次业务操作涉及多个聚合状态的更改应采用领域
事件的最终一致性。
领域事件驱动设计可以切断领域模型之间的强依赖关系事件发布完成后发布方不必关心后续订
阅方事件处理是否成功这样可以实现领域模型的解耦维护领域模型的独立性和数据的一致性。
在领域模型映射到微服务系统架构时领域事件可以解耦微服务微服务之间的数据不必要求强一
致性而是基于事件的最终一致性。
1.微服务内的领域事件
当领域事件发生在微服务内的聚合之间领域事件发生后完成事件实体构建和事件数据持久化发
布方聚合将事件发布到事件总线订阅方接收事件数据完成后续业务操作。
微服务内大部分事件的集成都发生在同一个进程内进程自身可以很好地控制事务因此不一定
需要引入消息中间件。但一个事件如果同时更新多个聚合按照DDD“一次事务只更新一个聚合”的
原则你就要考虑是否引入事件总线。
微服务内应用服务可以通过跨聚合的服务编排和组合以服务调用的方式完成跨聚合的访问这
种方式通常应用于实时性和数据一致性要求高的场景。这个过程会用到分布式事务以保证发布方
和订阅方的数据同时更新成功。
2.微服务之间的领域事件
跨微服务的领域事件会在不同的限界上下文或领域模型之间实现业务协作其主要目的是实现微服
务解耦减轻微服务之间实时服务访问的压力。
跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、消息中间件甚至事件
数据持久化时还可能需要考虑引入分布式事务机制等。
微服务之间的访问也可以采用应用服务直接调用的方式实现数据和服务的实时访问弊端就是跨
微服务的数据同时变更需要引入分布式事务以确保数据的一致性。分布式事务机制会影响系统性
能增加微服务之间的耦合所以我们还是要尽量避免使用分布式事务。
总之通过领域事件驱动的异步化机制可以推动业务流程和数据在各个不同微服务之间的流转
实现微服务的解耦减轻微服务之间服务调用的压力提升用户体验。
3、领域事件总体架构
领域事件的执行需要一系列的组件和技术来支撑。领域事件处理包括事件构建和发布、事件数
据持久化、事件总线、消息中间件、事件接收和处理等。 3.1 事件构建和发布
事件基本属性至少包括事件唯一标识、发生时间、事件类型和事件源其中事件唯一标识应该是
全局唯一的以便事件能够无歧义地在多个限界上下文中传递。事件基本属性主要记录事件自身以
及事件发生背景的数据。
另外事件中还有一项更重要那就是业务属性用于记录事件发生那一刻的业务数据这些数据会
随事件传输到订阅方以开展下一步的业务操作。
事件基本属性和业务属性一起构成事件实体事件实体依赖聚合根。领域事件发生后事件中的业
务数据不再修改因此业务数据可以以序列化值对象的形式保存这种存储格式在消息中间件中也
比较容易解析和获取。
为了保证事件结构的统一我们还会创建事件基类DomainEvent子类可以扩充属性和方法。由
于事件没有太多的业务行为实现方法一般比较简单。 事件发布之前需要先构建事件实体并持久化。事件发布的方式有很多种你可以通过应用服务或者
领域服务发布到事件总线或者消息中间件也可以从事件表中利用定时程序或数据库日志捕获技术
获取增量事件数据发布到消息中间件。
3.2 事件数据持久化
事件数据持久化可用于系统之间的数据对账或者实现发布方和订阅方事件数据的审计。当遇到消
息中间件、订阅方系统宕机或者网络中断在问题解决后仍可继续后续业务流转保证数据的一致
性。
事件数据持久化有两种方案 持久化到本地业务数据库的事件表中利用本地事务保证业务和事件数据的一致性。 持久化到共享的事件数据库中。
需要注意的是业务数据库和事件数据库不在一个数据库中它们的数据持久化操作会跨数据库
因此需要分布式事务机制来保证业务和事件数据的强一致性结果就是会对系统性能造成一定的影
响。
3.3 事件总线 (EventBus)
事件总线是实现微服务内聚合之间领域事件的重要组件它提供事件分发和接收等服务。
事件总线是进程内模型它会在微服务内聚合之间遍历订阅者列表采取同步或异步的模式传递数据。
事件分发流程大致如下 如果是微服务内的订阅者其它聚合则直接分发到指定订阅者 如果是微服务外的订阅者将事件数据保存到事件库表并异步发送到消息中间件 如果同时存在微服务内和外订阅者则先分发到内部订阅者将事件消息保存到事件库表再异步发送到消息中间件。
3.4 消息中间件
跨微服务的领域事件大多会用到消息中间件实现跨微服务的事件发布和订阅。
消息中间件的产品非常成熟市场上可选的技术也非常多比如KafkaRabbitMQ等。
3.5 事件接收和处理
微服务订阅方在应用层采用监听机制接收消息队列中的事件数据完成事件数据的持久化后就
可以开始进一步的业务处理。领域事件处理可在领域服务中实现。
4、案例
发生的领域事件是缴费通知单已生成。下一步的业务操作是缴费。 事件起点出单员生成投保单核保通过后发起生成缴费通知单的操作。 投保微服务应用服务调用聚合中的领域服务createPaymentNotice 和createPaymentNoticeEvent分别创建缴费通知单、缴费通知单事件。其中缴费通知单事件类PaymentNoticeEvent继承基类DomainEvent。 利用仓储服务持久化缴费通知单相关的业务和事件数据。为了避免分布式事务这些业务和事件数据都持久化。 到本地投保微服务数据库中。 通过数据库日志捕获技术或者定时程序从数据库事件表中获取事件增量数据发布到消息中间件。这里说明事件发布也可以通过应用服务或者领域服务完成发布。 收款微服务在应用层从消息中间件订阅缴费通知单事件消息主题监听并获取事件数据后应用服务调用领域层的领域服务将事件数据持久化到本地数据库中。 收款微服务调用领域层的领域服务PayPremium完成缴费。 事件结束。
提示缴费完成后后续流程的微服务还会产生很多新的领域事件比如缴费已完成、保单已保存
等等。这些后续的事件处理基本上跟16的处理机制类似。
5、总结
今天我们主要学习领域事件以及领域事件的处理机制。
领域事件驱动是很成熟的技术在很多分布式架构中得到了大量的使用。领域事件是DDD的一个
重要概念在设计时我们要重点关注领域事件用领域事件来驱动业务的流转尽量采用基于事件
的最终一致降低微服务之间直接访问的压力实现微服务之间的解耦维护领域模型的独立性和
数据一致性。
除此之外领域事件驱动机制可以实现一个发布方N个订阅方的模式这在传统的直接服务调用设
计中基本是不可能做到的。
