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，其中包括CQRSEventSourcing 领域事件等等。同时，传统的SOA将业务领域逻辑切分成不同系统，对外表现为服务，这种方式导致业务逻辑跨越多个系统，导致业务逻辑散落各处，寻找维护不方便，造成业务逻辑的污染和膨胀。

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

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

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

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

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