写点什么

Martin Fowler 谈如何理解事件驱动

  • 2017-03-13
  • 本文字数:1877 字

    阅读完需:约 6 分钟

去年年底,ThoughtWorks 内部开展了一个研讨会,讨论“事件驱动”应用程序的性质。在过去的几年里,他们建立了许多基于事件的系统,有被称赞,也有被吐槽。ThoughtWorks 的北美办公室组织了一次峰会,来自世界各地的 ThoughtWorks 高级开发人员在会上分享了他们的想法。 峰会的最大结果是得出这样的一个结论:当人们谈论“事件”时,他们实际上意味着一些完全不同的事情。 所以 Martin Fowler 花了很多时间试图从中挑出一些有用的模式, 本文就是对这些内容的简要总结。

事件通知(Event Notification)

事件通知是最基本也是最简单的模型。当一个系统发生了变更,它会通过发送事件消息的形式通知其他系统。发送消息的系统不要求接收消息的系统返回任何响应,即使有响应返回,它也不对其进行任何处理。这也就是所谓的“fire and forget”模式。

事件通知的好处在于它的简单性,并且有助于降低系统间的耦合性。不过,如果在一个复杂的生态系统里使用了太多的事件通知,可能会带来一些问题。太多的事件难以跟踪,发生问题难以调试,除非借助完善的实时监控系统。消息流错综复杂,当其规模开始膨胀开来,就会造成隐患。

通知事件不会包含太多的数据,一般只包含了一些 ID 或者链接之类的信息。对于接收消息的系统来说,如果它们想得到进一步的信息,或者要基于当前事件做出一些变更,那么它们就需要向源系统发起请求,以便获取更多的数据。那么问题来了,额外的请求不仅会造成延迟,而且一旦源系统宕机,后续的流程就无法继续进行。

事件传递状态转移(Event-Carried State Transfer)

事件传递状态转移模型比事件通知更进一步,可以看作是对事件通知的改进。这个模型最大的特点是,事件里包含了发生变更的数据。对于接收事件的系统来说,如果想要采取进一步措施,可以直接使用事件里的数据,而无需再次向源系统发起请求,从而降低了延迟。而且就算源系统宕机,也不会影响到后续的流程。

不过,既然把变更数据放在事件里进行传输,那么占用更多的带宽是不可避免的了。而且,如果有多个系统接收事件,那么这些数据就会有多个拷贝。

除此之外,接收事件的系统需要维护事件的状态,从而将原本存在于源系统的复杂性转移到了接收事件的系统上。

事件溯源(Event-Sourcing)

事件溯源的核心理念是说,在对系统的状态做出变更时,把每次变更记录为一个事件,在未来的任何时刻,都可以通过重新处理这些事件来重建系统的状态。事件存储是主要的事件来源,可以从事件存储中重建系统的状态。对于程序员来说,版本控制系统是一个最好的例子。提交日志就是事件存储,而代码工作副本就是系统状态。在某个指定的工作副本上重播提交日志就可以创建另一个工作副本,也就是重建了某个时刻的系统状态。

使用事件溯源的系统有哪些好处?首先,事件存储结构简单,易于存储,它们可以被存储在数据库里、文件系统或者其他任意的存储引擎里。因为记录事件是插入操作,没有修改也没有删除,就不需要用到事务控制,这也意味着可以避免使用锁。所以,使用事件溯源可以提升系统的性能。其次,事件本身可以充当审计日志的作用。如果不使用事件溯源,那么就需要为系统维护单独的审计日志。使用单独的审计日志就意味着有存在两个“真相源”,如果审计日志发生丢失,那么通过审计日志重建的状态与真实的系统状态会不一致。

不过,事件溯源也存在一些不足。如果事件很多,重放事件是一个耗时的过程,而且在重放过程中可能会涉及与第三方外部系统发生交互,所以需要做一些额外的操作。查询某个时刻的状态会变得很麻烦,因为需要通过重播事件来重建当时的状态。解决办法是使用快照。不过,系统没有必要为每次变更都创建快照,而是阶段性地创建快照。在查询状态时,通过在临近的快照上重放少量的事件就可以获得想要查询的状态。

CQRS

CQRS 是 Command Query Resposibility Segregation(命令查询职责分离)的缩写,它将读操作(查询)和写操作(增、删、改命令)进行分离,不仅让逻辑更清晰,而且可以各自进行优化。对于读多写少的系统来说,就特别适合使用 CQRS,因为可以针对读性能和写性能进行优化,而且可以进行横向扩展。

不过 CQRS 的概念虽然简单,但是实现起来相对复杂,而且涉及到很多领域驱动设计的(DDD)概念,最好结合事件溯源一起使用。

更多资料


感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2017-03-13 19:003412
用户头像

发布了 322 篇内容, 共 158.3 次阅读, 收获喜欢 148 次。

关注

评论

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

架构设计系列三 详细架构设计文档编写

nydia

详细架构设计文档 架构设计文档

疯狂涨知识,spring全方位深入探索,

Java 程序员 后端

架构实战营模块三作业 - 外包学生管理系统的架构文档

李焕之

边缘计算如何实现海量IoT数据就地处理

孙叫兽

物联网 边缘计算 引航计划

手撸二叉树之恢复二叉树

HelloWorld杰少

9月日更

疯狂复习半个月,三面蚂蚁金服(交叉面)定级阿里P6

Java 程序员 后端

乘着汽车智能化的浪潮,“汽车人”职业方向的选择(一)

SOA开发者

软件 职业成长 汽车

《鸿蒙理论知识04》HarmonyOS概述之系统定义

孙叫兽

鸿蒙 鸿蒙系统 引航计划

Vue进阶(幺幺玖):element-ui table组件适应性问题(横向滚动条)

No Silver Bullet

Vue 9月日更

netty系列之:在netty中处理CORS

程序那些事

Java Netty 程序那些事 响应式系统

外包学生管理系统架构文档

看,有只猪

我理想中的任务调度系统

分布式 任务调度 scheduler

如何对技术视频转换文章投稿进行二次创作

孙叫兽

技术社区 投稿 引航计划

疯狂复习20天卷土从来,tomcat原理及优化

Java 程序员 后端

【LeetCode】链表中的下一个更大节点Java题解

Albert

算法 LeetCode 9月日更

疯狂复习半个月,全栈系统化的学习路线

Java 程序员 后端

《鸿蒙理论知识03》HarmonyOS概述之系统安全

孙叫兽

鸿蒙 鸿蒙开发 鸿蒙系统 引航计划

《鸿蒙理论知识01》HarmonyOS概述之技术特性

孙叫兽

鸿蒙 鸿蒙开发 引航计划

疯狂复习20天卷土从来,2021Java笔试题总结

Java 程序员 后端

疯狂复习20天卷土从来,Java面试真题解析火爆全网

Java 程序员 后端

疯狂复习半个月,rocketmq原理面试题

Java 程序员 后端

架构实战课程 模块三作业

Frank

架构实战营 模块八 作业

一雄

作业 架构实战营 模块八

再见了,我的散装研发管理平台;再见了,4台ECS!

阿里巴巴云原生

云计算 阿里云

【Flutter 专题】44 图解矩阵变换 Transform 类 (一)

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 9月日更

《鸿蒙理论知识06》HarmonyOS概述之应用开发基础知识

孙叫兽

鸿蒙 HarmonyOS 鸿蒙系统 引航计划 领航计划

系统的可靠性 Reliability

BlockQuant

MySQL 稳定性 可用性 可靠性

28分钟完成一款Python游戏,《客服戏翻总裁牌》

梦想橡皮擦

9月日更

《鸿蒙理论知识02》HarmonyOS开发平台和工具

孙叫兽

鸿蒙 HarmonyOS 鸿蒙系统 引航计划

Apache APISIX 社区周报 | 2021 8.30-9.12

API7.ai 技术团队

Apache 开源 API网关 APISIX 社区周报

《鸿蒙理论知识05》HarmonyOS概述之下载与安装软件

孙叫兽

鸿蒙 鸿蒙系统 引航计划

Martin Fowler谈如何理解事件驱动_语言 & 开发_ Martin Fowler_InfoQ精选文章