PCon全球产品创新大会最新日程上线,这里直达 了解详情
写点什么

Martin Fowler 谈如何理解事件驱动

  • 2017 年 3 月 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 年 3 月 13 日 19:002194
用户头像

发布了 321 篇内容, 共 116.3 次阅读, 收获喜欢 121 次。

关注

评论

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

【Redis实战】集合类型,unixlinux编程实践教程

Java 程序员 后端

前端组件化工程实践

循环智能

AI 组件化 智能化

【Spring Boot实战与进阶】Controller的使用及获取请求参数的示例

Java 程序员 后端

【Spring Cloud 2】注册中心Eureka,java架构面试题spring原理

Java 程序员 后端

【Spring 基础注解】对象创建相关注解,java开发实战经典答案百度云

Java 程序员 后端

【Java知识点详解 8】Java反射机制,java项目经验面试题

Java 程序员 后端

自定义注解实现方式全解析

小鲍侃java

11月日更

【MyBatis-plus】条件构造器详解,mysql索引原理及btree

Java 程序员 后端

重磅|Apache ShardingSphere 5.0.0 即将正式发布

SphereEx

数据库 ShardingSphere Meetup Apache ShardingSphere DateBase

【Spring 持久层】Spring 与 Mybatis 整合,spring教程极客学院

Java 程序员 后端

【SpringBoot系列】配置多环境配置文件,hadoop环境搭建教程

Java 程序员 后端

【Spring Boot实战与进阶】AOP的两种动态代理,java注解的实现原理

Java 程序员 后端

【云计算】云的七大分类定义说明

行云管家

云计算 公有云 私有云 云资源

【SpringMVC 笔记】Json 交互处理,顺丰java社招面试

Java 程序员 后端

Kafka 3.0 重磅发布,来看下值得关注的新功能

大数据技术指南

kafka 11月日更

等保测评机构每年都需要年审吗?年审时候需提供哪些资料?

行云管家

网络安全 等级保护 等保测评 等保办

【Spring Boot 25】JdbcTemplate配置类 (1),鬼知道我经历了啥

Java 程序员 后端

【Spring Boot 25】JdbcTemplate配置类 ,设计模式面试题java

Java 程序员 后端

【Quarkus 技术系列】,Java高级工程师面试答案大全

Java 程序员 后端

深入理解 TCP 拥塞控制

拍乐云Pano

TCP 音视频 RTC TCP通信

【JVM系列5】深入分析Java垃圾收集算法和常用垃圾收集器

Java 程序员 后端

【Spring Boot 6】自定义starter,花了6个月肝完阿里技术官的笔记

Java 程序员 后端

【Spring Cloud 8】熔断与限流Sentinel,java现在的主流技术

Java 程序员 后端

【SpringMVC笔记】Ajax 入门,linux编程基础李养群课后答案

Java 程序员 后端

【Java程序员必知必会的90个细节】1,隔壁都馋哭了

Java 程序员 后端

【MyBatis 2】MyBatis-Plus,java分布式框架技术方案

Java 程序员 后端

【Spring Boot 23】MyBatis事务管理,java基础知识点思维导图

Java 程序员 后端

就这?彻底搞懂单例模式

蝉沐风

Java 面试 设计模式 单例模式

【SpringMVC 笔记】Json 交互处理(1),面试官都被搞懵了

Java 程序员 后端

【Spring 工厂】反转控制与依赖注入,spring集成mybatis原理面试题

Java 程序员 后端

彻底说透简单工厂那些你没有关注过的细节

Tom弹架构

Java 架构 设计模式

ShadowRealm 与微前端沙箱

ShadowRealm 与微前端沙箱

Martin Fowler谈如何理解事件驱动-InfoQ