写点什么

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:003275
用户头像

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

关注

评论

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

译文《最常见的10种Java异常问题》

潘大壮

Java 异常 java异常处理 Exception

区区一个SpringBoot问题就干趴下了?我却凭着这套“神级PDF文档”吊打面试官

Java 编程 面试 微服务

《程序员修炼之道》- 务实的哲学(3)

石云升

读书笔记 程序员 28天写作 批判性思维 完成好过完美

数据库恢复子系统的常见技术和方案对比(二)

星环科技

数据库 大数据

产品训练营--第二期作业

曦语

产品训练营

智能汽车为什么新势力有胜算(28天写作 Day20/28)

mtfelix

28天写作 新能源汽车 智能汽车 造车新势力

10 个 JavaScript 简洁代码小技巧(文末彩蛋)

零和幺

JavaScript 大前端 CleanCode

Libra演进与数字货币国际化

CECBC

区块链

kotlin高阶函数let、with、apply、run、also使用场景

陈吉米

kotlin

抽奖助手利益相关方

千竹

新思科技发布《美国不良软件质量成本:2020年报告》

InfoQ_434670063458

软件质量 新思科技

【推荐收藏!】Gradle 与 Android 构建入门

百度Geek说

研发工具 andiod

程序员入职新公司,只需8步,直接凸显出个人价值

Java架构师迁哥

教你用Java字节码做点有趣的事

比伯

Java 编程 架构 程序人生 计算机

这是阿里技术专家对 SRE 和稳定性保障的理解

阿里巴巴云原生

项目管理 运维 云原生 安全 监控

nodejs的调试debug

程序那些事

debug 调试 nodejs 程序那些事 程序调试

KubeVela:标准化的云原生平台构建引擎

阿里巴巴云原生

容器 云原生 k8s API OAM

Flink 学习路线总结

大数据学习指南

大数据 flink

开发质量提升系列:问题登记列表(下)

罗小龙

生产事故 28天写作 解决思路

三张图解释静态NAT、动态NAT、PAT

数据库恢复子系统的常见技术和方案对比(一)

星环科技

数据库 大数据

拍乐云 Flutter SDK 全新发布,跨平台音视频开发更easy

拍乐云Pano

flutter 音视频 WebRTC RTC

一个 3 年 Java 程序员 5 家大厂的面试总结(已拿Offer)

Java架构之路

Java 程序员 架构 面试 编程语言

“区块链新闻编辑部”: 从“云媒体”到“链媒体”的现实跨越

CECBC

区块链技术

阿里四年技术 TL 的得失总结:如何做好技术 Team Leader

阿里巴巴云原生

云计算 项目管理 程序员 微服务 云原生

30天消化MyBatis源码解析笔记,吊打面试官,offer接到手软

Java架构之路

Java 程序员 架构 面试 编程语言

Elasticsearch 基于脚本进行 partial update

escray

elastic 七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

5年Java经验不会源码被拒,苦学这些Spring源码笔记后,面试不再慌

Java架构之路

Java 程序员 架构 面试 编程语言

Flink可靠性的基石-checkpoint机制详细解析

五分钟学大数据

大数据 flink

内存数据库解析与主流产品对比(三)

星环科技

数据库 大数据

Dubbo 3.0 前瞻之对接 Kubernetes 原生服务

阿里巴巴云原生

容器 运维 云原生 k8s dubbo

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