事件驱动

在云原生技术体系下，微服务架构是一种必然的趋势，一个微服务的架构是需要一个系统来支持服务和服务之间的通信，从而把微服务合理的组织在一起提供服务。自然，事件驱动的微服务架构就是一种非常好的选择。所以对于大多数应用，让微服务工作并且管理好分布式数据的方式就是采用事件驱动架构。

事件驱动架构是一种用于设计应用的软件架构和模型。对于事件驱动系统而言，事件的捕获、通信、处理和持久化保留是解决方案的核心。这与传统的请求驱动模型有很大的不同。

事情驱动是一种松耦合的架构，订阅者无需主动关注事件的产生，只要被动接受事件生产者产生的消息并进行处理，这种架构下，能够帮助提升系统的整体复用性、交互性和可扩展性。

事件驱动的架构促使了一个完全去中心化平台的发展，服务不必再同一个系统或是数据中心中，并且可以不属于同一个组织。

在事件驱动的体系结构中，当服务执行其他服务可能感兴趣的某些工作时，该服务将生成一个事件—执行操作的记录。其他服务使用这些事件，以便它们能够执行由于该事件而需要的任何自己的任务。事件成为了可以被消费的对象，而不仅仅是在函数间传递的临时参数，从而可以同时被多个服务消费。其它服务不需要直接和生成事件的服务进行交互，而可以通过监听事件，触发其对应的操作，从而降低了服务内部的复杂度。事件驱动架构提供了以下优点：

• 异步——基于事件的架构是异步的，没有阻塞。这使得资源可以在他们的工作单元完成后自由地转移到下一个任务，而不用担心之前发生了什么或者接下来会发生什么。它们还允许对事件进行排队或缓冲，从而防止使用者向生产者施加压力或阻塞它们。
• 松耦合——服务不需要(也不应该)知道或依赖于其他服务。在使用事件时，服务独立运行，不了解其他服务，包括其实现细节和传输协议。事件模型下的服务可以独立地、更容易地更新、测试和部署。
• 易于扩展——由于服务在事件驱动的体系结构下解耦，而且服务通常只执行一项任务，因此跟踪特定服务的瓶颈，并对该服务(且仅对该服务)进行扩展变得很容易。
• 恢复支持——带有队列的事件驱动架构可以通过“重播”过去的事件来恢复丢失的工作。当用户需要恢复时，这对于防止数据丢失非常有用