事件驱动理论（深析事件驱动架构模式）

　　事件驱动理论（深析事件驱动架构模式）Event-driven architecture(EDA) is asoftware architectureparadigm promoting the production, detection, consumption of, and reaction toevents.
　　Thisarchitectural patternmay be applied by the design and implementation of applications and systems that transmit events amongloosely coupled software componentsandservices.
　　--https://en.wikipedia.org/wiki/Event-driven_architecture
　　通过维基百科我们可以看出：
　　事件驱动架构是一种软件架构范式，可促进事件的产生，检测，使用等。该架构模式是通过松耦合等方式在应用间传输数据。
　　事件驱动架构是怎么工作的？
　　在事件驱动的体系结构中，当微服务执行其他微服务可能感兴趣的操作时，它将事件发布到事件代理（Broker）。该微服务称为生产者。系统中的其他微服务称为消费者，可以处理事件。
　　消息模式有两种类型：消息队列和发布订阅。两者区别是：消息队列只能有一个消费者处理事件，而发布订阅模式可以有多个消费者，而且消费者可以订阅自己感兴趣的事件。
　　一旦消费者成功处理一个事件后，它们会发送一个ACK给事件代理者（Broker）。事件代理就是生产者和消费者之间的一个中介，这样生产者就不用关心有哪些消费者在消费，反之亦然。
　　事件驱动架构的好处
　　松耦合
　　生产者和消费者彼此不用知道对方是谁，这就会使得服务非常松耦合，非常易于修改，测试和部署。
　　易伸缩
　　通过水平扩展生产者和消费者就可以快速达到伸缩能力（而不用重新设计系统），而且还允许生产者和消费者之间的速率不匹配，从而实现较小的增量缩放改进。
　　容错能力强
　　假如一个消费者在处理事件过程中出现异常而停止工作，没有给事件代理者发送ACK，那么这个事件不会丢失，其他消费者实例会重新消费这个消息或者等待这个消费者自己恢复后再重新消费。
　　易扩展
　　因为生产的数据可以被多个消费者消费，所以存在1对多的关系，只需要添加一个额外的消费者，就可以将事件用于新功能。
　　数据重放
　　可以消费过去的数据（一般用于数据恢复使用）。事件驱动架构的挑战
　　不易推理
　　上面说了，事件驱动架构是松耦合的，生产者和消费者之间彼此不知道对方是谁，所以很难一眼看出数据都被谁消费了，或数据有谁来生产的。
　　事件不易设计
　　因为一个事件可以被任意的消费者订阅消费，因此它必须是可重用的，而不是针对一个消费者定制的。
　　改变事件很困难
　　系统会随着时间而变化，意味着事件也会随着变化，以便促进系统的新行为。在不影响其他微服务的情况下改变事件会很困难，尤其是在上了规模的系统中，当团队无法跟踪谁在消费它们的数据时，这一点尤其如此。当事件被持久化和回放时，系统还需要能够解析事件的所有历史版本，随着时间的流逝，这可能导致巨大的复杂性。
　　同步的事件流
　　从上面的说明可以看出，事件驱动架构原生具体异步特性，如果想用这种架构体系做同步事件流可能就不太合适，可以使用其他模式来做这件事，比如：REST（request-response)。
　　中心化
　　上面我们说了，事件代理者是生产者和消费者之间的中介，是连接其他所有组件的组件，所以非常重要。一旦事件代理挂了，其他所有相关模块都会停止，所以必须维护好事件代理，做到高可用。
　　总结
　　本文介绍了事件驱动架构的定义，以及它是怎么工作的。更深入分析了这种架构的好处和挑战，希望对大家有所帮助。