事件驱动架构是一种常见的软件架构设计方法，对事件驱动系统而言，事件的产生、通信、捕获、处理和持久保留是解决方案的核心结构。事件驱动架构不受具体编程语言的限制，可以最大程度的降低耦合度，因此在现在分布式架构中应用广泛。

案例

比如电商中的订单系统关于订单的状态变化，新建，支付，发货，取件等，如果由订单系统去调用其他系统，会给订单系统带来非常高的成本，理想的方式是所有的订单状态变化都发送一个消息，感兴趣的业务下游消费此消息进行业务逻辑处理。

如下图，理论上订单系统只需要写一份消息，如果有新的业务需要使用订单消息进行消费即可，可以写一份新的代码而不用修改任何老代码。

常见事件驱动架构模型

这是一种基于事件流订阅的消息传递基础架构。对于该模型而言，在事件发生或公布之后，系统会将相应的消息发送给需要通知的订阅用户。

借助事件流模型，事件将被写入日志，事件使用者无需订阅事件流。相反，它们可以从流的任何部分读取并随时加入流。

事件流有几种不同的类型：

事件流处理使用诸如 Apache Kafka 等数据流平台来提取事件并处理或转换事件流。事件流处理可用于检测事件流中有用的模式。

简单事件处理是指事件立即在事件使用者中触发操作。

复杂事件处理则需要事件使用者处理一系列事件以检测模式。

异步：内部的组件不需要知道之前发生了什么，接下来发生什么，只需要关注处理各自的事件即可。

松耦合，服务不需要(也不应该)知道或依赖于其他服务。

易扩展：

扩展现有服务：由于服务在事件驱动的体系结构下解耦，而且服务通常只执行一项任务，因此跟踪特定服务的进行扩展变得很容易。

扩展新服务：只需要新增一个消费者即可，可随时自由的添加

恢复支持：带有队列的事件驱动架构可以通过“重播”过去的事件来恢复丢失的工作。当用户需要恢复时，这对于防止数据丢失非常有用。

考虑事件模型一些注意事项

事件太多：消息量过大的话，可能一些小服务无法消费完，从而堆积甚至被消息打挂掉。

通用事件：过于通用的东西一般相当于没有这个东西，最好还是定义事件的规范，不同的事件要进行区分。

业务量级：当应用体量还比较小的时候，可以考虑传统的模式即可，如果直接引入事件驱动架构会增加复杂度，增加成本。

当扩展现有服务的时候，由于各自模块是解耦的，彼此不直接感知，因此对现有的服务直接进行扩容很简单。

当增加新的服务的时候，无需考虑其他服务和系统，只需要关注新服务逻辑以及事件本身即可，没有依赖，因此可以直接使用。