EDA 事件驱动框架
事件代表过去发生的事件,事件既是技术架构概念,也是业务概念。以事件为驱动的编程模型称为事件驱动架构EDA。
EDA是一种以事件为媒介,实现组件或服务之间最大松耦合的方式。传统面向接口编程是以接口为媒介,实现调用接口者和接口实现者之间的解耦,但是这种解耦程度不是很高,如果接口发生变化,双方代码都需要变动,而事件驱动则是调用者和被调用者互相不知道对方,两者只和中间消息队列耦合。
事件驱动有以下特征:
- 生产者producer发生实时事件
- 推送通知
- 生产者发射即完成fire-and -orget
- 消费者consumer立即响应
- 事件与命令是有区别的
借助消息系统异步模型的特点,事件驱动也有异步特征,传统方法调用比如调用b.xxmethod()是一种同步模型,这时必须等待b的方法执行完才能继续执行其他代码,RPC远程方法调用也是一种同步模型,而对于异步模型来说,事件生产者发出事件后,不必等待回应,可以继续执行下面的代码。
但是不代表使用了消息系统的架构都是EDA,SOA面向服务驱动的架构中也使用消息系统作为ESB,两者使用方式不同,三种不同交互方式:
- 时间驱动:比如cron定时计划执行
- 请求驱动:客户端和服务器端之间,常见SOA
- .事件驱动:以事件为特征。实时。
请求驱动+消息系统和事件驱动+消息系统有本质区别,前者是由请求者作为消息生产者,主要目的是为了得到响应,因此是一种请求响应模型;而后者重点是在消息消费者,不是在消息生产者,业务逻辑站在消费者角度完成,业务逻辑的完成靠事件驱动来执行,而前者业务逻辑是在消息生产者完成,当业务逻辑中需要什么依赖或资源,依靠发送消息来拉取完成。这两种区别本质是拉Poll和推Push的区别。
正是因为EDA这种和传统SOA的本质区别,现在诞生一种领域EDA,其中包括CQRSEventSourcing 领域事件等等。同时,传统的SOA将业务领域逻辑切分成不同系统,对外表现为服务,这种方式导致业务逻辑跨越多个系统,导致业务逻辑散落各处,寻找维护不方便,造成业务逻辑的污染和膨胀。
使用EDA改造传统SOA,比如,如果一个报表系统想知道交易系统的状态,它不是发送一个消息给交易系统,拉取它当前的状态,而是向事件总线订阅,这样当交易系统有状态报告时,将发出事件通知报表系统。
EDA的可扩展性和吞吐量上要强于传统SOA,EDA类似组装生产线,下图对于一个顺序线性的处理过程,6个步骤分别是接受 确认 保存 产生PDF 发送Email 输出展现,花去365ms:
而组装线的EDA方式,总是询问着6步中是否可以让别人协同帮助完成?其中第4步和第5步是可以的,因此整个处理时间提升到115ms,提升了70%的响应时间:
详细的组装线如下,这实际也是一种SEDA,Staged EDA:
最终我们可以完成一个新的基于领域事件的D-EDA+SOA架构如下: