基于DDD、CQRS、微服务和事件溯源构建系统

2019 年 11 月 03 日

基于DDD、CQRS、微服务和事件溯源构建系统

对于构建系统来说,模块化是至关重要的,但实现模块化需要应对一些反模块化的做法。两种典型的反模块化做法就是在不考虑业务领域的情况下走捷径和拆分微服务,这会增加技术债务。最近,在由AxonIQ举办的阿姆斯特丹事件驱动微服务大会上,Allard Buijze分享了他的一些想法,以及基于DDDCQRS、微服务和事件溯源构建系统的亲身经验。


Buijze 是 AxonIQ 的 CTO。他指出,另一个反模块化做法就是名词驱动设计(noun-driven design)。名词驱动设计用于发现应用程序中的对象,通常是通过查找应用程序中出现的名词,而非采用那些用于创建服务的对象。如果开发人员需要一次性重新部署多个服务,或是某个服务需要依赖于其他服务,就会从单体应用转为分布式单体应用,但潜在的问题并没有得到解决,这并不是微服务架构。


Buijze 认为,转向微服务需要一个过程,无法一步将业务模型转为微服务。反之,我们应该从那些具有良好结构和模块化的单体应用着手,根据需求逐步拆分出新的微服务。他强调,创建微服务的需求应该是非功能性需求。


Buijze 指出,将组件抽取成微服务的重点在于实现位置透明性。组件不应该知道或者假定知道与之交互的其他组件的位置。这意味着当组件可被抽取为微服务时就无需重写现有组件与新服务之间的通信。


解决位置透明性问题的通常做法是使用事件。一个服务无需直接调用与之通信的其他服务,而是通过发布事件并设置服务去监听事件。Buijze 指出,使用事件的一个重要特点是实现了依赖关系的转置,即订阅事件的组件或服务可以直接监听发送的事件。


Buijze 介绍了只使用事件会出现的一个常见错误,即事件也会被用于间接请求发生于其他服务中的操作,这会增加服务间的耦合度,可能导致双向依赖,使得服务间依赖关系难以编排。如下例,图中没有负责业务流程的服务:



组件间会因为不同的原因发起通信。除了使用事件之外,还存在另外两种消息,一种是用于表示改变事物的“命令”(Command),另一是用于获取信息的“查询”(Query)。在上例中,订单服务(Order)可使用“命令”去请求支付(Payment)和交货(Shipping)服务,交货服务可使用“查询”去请求订单服务细节。Buijze 建议我们应该像使用事件那样同等使用命令和查询。


事件溯源是另一个与事件相关的概念。在使用事件溯源时,组件中存储的并非实体的具体状态,而是导致每个实体状态发生变更的事件。Buijze 认为,事件源就是获取所有的事实,并且只关心事实。但他也指出,事件溯源必须被正确实现,否则就无法确保事实的完整性。要验证事件溯源是否被正确实现,可以试着抛开事件存储以外的东西。如果应用程序的状态可重现,说明事件溯源做对了。Buijze 进一步指出,要在服务中使用事件溯源,服务必须使用自己发布的事件来保持一致的状态。


从业务和技术方面来看,事件溯源都有一些优势,审计和单一数据源就是两个很好的例子。 事件溯源同样存在一些挑战,例如增加了存储规模、实现复杂度高。但 Buijze 认为,这些问题现已不复存在,目前最大的挑战在于事件思维(event thinking)。在 Buijze 看来,事件是一种更为自然的理解应用程序行为的思维方式。他建议,我们应该将注意力放在行为上,而非状态上。事件和命令描述了应用程序的功能,因此让应用程序的行为变得更容易理解。但他并不建议对所有应用程序使用事件溯源。与其他工具一样,事件溯源仅在合适的场景才能发挥作用。


最后,Buijze 强调,所有的通信都是某种形式的合约。基于事件架构的一个缺点是需要对很多未知的组件建立合约。因此,我们要对事件和合约的范围加以约束,避免各个有界上下文之间存在耦合。在同一上下文中,所有服务使用同一种语言,并且能理解所有的事件。但是很多事件,尤其是事件溯源中的事件,只在特定的上下文中是有用的,不应该被发布到上下文之外。对于一些公共事件,一种好的做法是将事件转换为公共 API。


Martin Fowler 在 2015 年发表的一篇博文中提到,他已经注意到乎所有成功的微服务均源于单体应用。但此后不久,Stefan Tilkov 在其博客中提出了不同的看法,即如果目标是实现微服务架构,那么从单体应用着手是完全错误的做法


欧洲2019 DDD大会的一个演讲中,Eric Evans 介绍了各种类型的“有界上下文”,其中一些类型尤其适用于基于事件的系统。


大会演讲全程录像,并将于近几周内公开发布。


原文链接:


Sense and Nonsense in Event Thinking and Microservices


2019 年 11 月 03 日 08:002228

评论

发布
暂无评论
发现更多内容

[Redis] 你了解 Redis 的三种集群模式吗?

猴哥一一 cium

redis redis高可用 redis哨兵模式 群集安装

搞定 HTTP 协议(一):HTTP 与网络基础

零和幺

技术 前端 HTTP

深入理解ContextClassLoader

NORTH

深入理解JVM ContextClassLoader

ARTS打卡 第2周

引花眠

ARTS 打卡计划

经历了新冠疫情,我们如何重塑死亡观?

lmymirror

人生 感悟 死亡观

万字长文,助你吃透Eureka服务发现机制!

攀岩飞鱼

分布式 微服务 微服务发现 Eureka

iOS 动画 - 窗景篇(一)

柯烂

ios objective-c swift 移动应用 动画

深入理解JVM内存管理 - 方法区

NORTH

深入理解JVM 方法区 老年代

这些Java8官方挖的坑,你踩过几个?

码大叔

Java 踩坑 加密 「Java 25周年」

Linux 自动化运维工具 ansible

杨仪军

Linux 运维自动化

【求锤得锤的故事】Redis锁从面试连环炮聊到神仙打架。

why技术

redis 分布式锁 分布式系统

深度解读 Flink 1.11:流批一体 Hive 数仓

Apache Flink

大数据 flink 流计算 实时计算 大数据处理

赢的境界 - 双赢思维

石云升

创业 创业心态 双赢思维

CPU的性能,编译器是这样压榨的!

GPU

算法 cpu 编译器 程序语言

匆忙的一周 ARTS第二周

困到清醒

java的时间利器:joda

毛佳伟🐳

Java

坏的开始是成功的一半

escray

啪啪,打脸了!领导说:try-catch必须放在循环体外!

王磊

Java 性能优化 性能 java编程

信息的表示与存储-整数的表示

引花眠

不想被下载限速,教你自建属于自己的云盘!

小傅哥

小傅哥 云服务 云盘 在线网盘

从技术到管理,我在极客时间的成长历程

邓建春

MySQL实战笔记-事务隔离和MVCC

shiziwen

MySQL 事务隔离级别 学习笔记

除了直接看余额,谁更有钱还能怎么比(三)

石君

零知识证明 多方计算 同态加密

深入理解JVM类加载机制

NORTH

类加载 深入理解JVM

【大厂面试01期】高并发场景下,如何保证缓存与数据库一致性?

NotFound9

Java MySQL 数据库 redis 后端

深入理解ClassLoader

NORTH

类加载 深入理解JVM ClassLoader

万恶的NPE如何避免,几种你必须知道的方案!!!

不才陈某

后端

关于区块链的“去中心化”,90% 的人都搞错了

CECBC区块链专委会

CECBC 区块链技术 去中心化 专制

游戏夜读 | 2020周记(5.24-5.31)

game1night

产品经理的商业能力

夜来妖

程序人生 产品经理 商业 商业模式 商业价值

是公司养活了你,还是你养活了公司?

四猿外

生涯规划 程序员 个人成长

AI如何在普惠金融的探索中发挥作用?

AI如何在普惠金融的探索中发挥作用?

基于DDD、CQRS、微服务和事件溯源构建系统-InfoQ