定义
Event-driven architecture (EDA), is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.
简单来说，事件驱动架构就是基于事件进行通信的软件架构，它具有以下的特点：
- 分布式异步架构，事件生产者和消费者高度解耦（生产者不知道有多少消费者要消费对应事件），事件消费者之间也高度解耦（消费者之间也互不感知）
- 更好的性能，由于事件的异步本质，软件不易产生拥堵，能够处理更高的流量。
- 事件处理器可以独立的开发，测试，部署，并容易接入到整个生态系统，故可扩展性好。
Orchestration vs Choreography
我们在聊事件驱动架构时，先了解下Orchestration 和 Choreography的区别：
-
他们都是服务组合的方式，一种是中心化的方式，另外一种是去中心化的方式，直接从下图就可以看出他们之间的区别：
Orchestration vs choreography.png
在上一篇文章里面已经介绍了，由于HTTP的同步特性(https://www.jianshu.com/p/a2c6126262d6），在很多场景下，Blocking式的http调用其实并不适用，因此为了提高系统性能，缩短总体响应时间（e.g后端多个服务编排的时间过长），提高系统的整体可用性（e.g： 下游downstream服务不稳定，导致的可用性问题），越来越多的系统都采用了Event Driven Architecture的方式进行服务的集成。
在Event-Based的系统里，服务的集成是通过Choreography的方式，而不是Orchestration的方式来实现的，举个列子如下图：
Orchestration (1).png
Choreography.png
- Orchestration，在图中Customers API在创建Customer的过程中，直接调用了Account API进行了账号的创建，在返回体中包含了一个hypermedia link，允许consumer通过这个链接获取到Account的信息。
- Choreography，在图中Customers API并没有试图直接创建账号，而是抛出一个“CustomerCreated”的事件到queue或者stream里面，然后就将用户的数据反馈给消费者了，之后，相应的事件订阅者，比如Accounts API就被通知了，或者主动去拉取“CustomerCreated”事件，获取到事件后，执行相应的操作，创建了Account并抛出了“AccountCreated”事件，然后Customer API作为这个事件的订阅者，被通知，进行了相应的关联操作，因此，当consumer获取customer的时候，Account的信息已经被内联到customer数据结构了。
