EDA事件驱动架构

文章来源：

事件代表过去发生的事件，事件既是技术架构概念，也是业务概念。以事件为驱动的编程模型称为事件驱动架构EDA。

　　EDA是一种以事件为媒介，实现组件或服务之间最大松耦合的方式。传统面向接口编程是以接口为媒介，实现调用接口者和接口实现者之间的解耦，但是这种解耦程度不是很高，如果接口发生变化，双方代码都需要变动，而事件驱动则是调用者和被调用者互相不知道对方，两者只和中间消息队列耦合。

　　事件驱动有以下特征：

1. 生产者producer发生实时事件
2. 推送通知
3. 生产者发射即完成fire-and -orget
4. 消费者consumer立即响应
5. 事件与命令是有区别的

　　借助消息系统异步模型的特点，事件驱动也有异步特征，传统方法调用比如调用b.xxmethod()是一种同步模型，这时必须等待b的方法执行完才能继续执行其他代码，RPC远程方法调用也是一种同步模型，而对于异步模型来说，事件生产者发出事件后，不必等待回应，可以继续执行下面的代码。

　　但是不代表使用了消息系统的架构都是EDA，SOA面向服务驱动的架构中也使用消息系统作为ESB，两者使用方式不同，三种不同交互方式：

1. 时间驱动：比如cron定时计划执行
2. 请求驱动：客户端和服务器端之间，常见SOA
3. .事件驱动：以事件为特征。实时。

　　请求驱动+消息系统和事件驱动+消息系统有本质区别，前者是由请求者作为消息生产者，主要目的是为了得到响应，因此是一种请求响应模型；而后者重点是在消息消费者，不是在消息生产者，业务逻辑站在消费者角度完成，业务逻辑的完成靠事件驱动来执行，而前者业务逻辑是在消息生产者完成，当业务逻辑中需要什么依赖或资源，依靠发送消息来拉取完成。这两种区别本质是拉Poll和推Push的区别。

　　正是因为EDA这种和传统SOA的本质区别，现在诞生一种领域EDA，其中包括 等等。同时，传统的SOA将业务领域逻辑切分成不同系统，对外表现为服务，这种方式导致业务逻辑跨越多个系统，导致业务逻辑散落各处，寻找维护不方便，造成业务逻辑的污染和膨胀。

　　使用EDA改造传统SOA，比如，如果一个报表系统想知道交易系统的状态，它不是发送一个消息给交易系统，拉取它当前的状态，而是向事件总线订阅，这样当交易系统有状态报告时，将发出事件通知报表系统：

　　EDA的可扩展性和吞吐量上要强于传统SOA，EDA类似组装生产线，下图对于一个顺序线性的处理过程，6个步骤分别是接受 确认 保存 产生PDF 发送Email 输出展现，花去365ms：

而组装线的EDA方式，总是询问着6步中是否可以让别人协同帮助完成？其中第4步和第5步是可以的，因此整个处理时间提升到115ms，提升了70%的响应时间：

详细的组装线如下，这实际也是一种SEDA，Staged EDA:

　　最终我们可以完成一个新的基于领域事件的D-EDA+SOA架构如下：

EDA架构的核心仍然是基于消息的发布订阅模式，消息的特定就是准实时，异步和彻底解耦。同时通过发布订阅模式实现事件的一对多灵活分发。不论是哪种消息中间件基本需要实现上面所谈到的核心能力。消息中间件有消息存储和持久化功能，有消息消费方的配置功能，正是由于有这些功能才谈得上消息发布方和消息接收方的彻底解耦，消息消费方对发送方而言完全透明，消息发送方只管把消息发送到消息中间件，其它事情全部不用关心，由于消息中间件中的MQ等技术，即使发送消息时候消息接收方不可用仍然可以正常发送，这才叫彻底解耦。其次一对多的发布订阅模式是另外一个核心重点，对于消息的订阅方和订阅机制可以在消息中间件灵活的进行配置和管理，而对于消息发送方和发送逻辑基本没有任何影响。

消息中间件如果需要持久化存储到硬盘；超出内存部分，dump新数据到硬盘，从老数据开始让消费者处理，消费者来不及，就dump硬盘。