RocketMQ 事件驱动：云时代的事件驱动有啥不同？

前言：

从初代开源消息队列崛起，到 PC 互联网、移动互联网爆发式发展，再到如今 IoT、云计算、云原生引领了新的技术趋势，消息中间件的发展已经走过了 30 多个年头。

目前，消息中间件在国内许多行业的关键应用中扮演着至关重要的角色。随着数字化转型的深入，客户在使用消息技术的过程中往往同时涉及交叉场景，比如同时进行物联网消息、微服务消息的处理，同时进行应用集成、数据集成、实时分析等，企业需要为此维护多套消息系统，付出更多的资源成本和学习成本。

在这样的背景下，2022 年，RocketMQ 5.0 正式发布，相对于 RocketMQ 4.0，架构走向云原生化，并且覆盖了更多的业务场景。

1. 背景

事件驱动是一个经典的概念，这篇文章主要探讨云时代的事件驱动和传统的事件驱动相比有哪些不同？第一部分从技术理念的层面了解一下事件驱动的概念，第二部分会介绍 RocketMQ 5.0 面向云时代的事件驱动架构推出的子产品 EventBridge，最后再结合几个具体的案例帮助大家了解云时代的事件驱动的常见场景和最佳实践。

2. 事件驱动架构

2.1 事件驱动架构定义

先从事件驱动的定义来看，事件驱动本质上是一种软件设计模式，它能够最大化降低不同模块以及不同系统之间的耦合度。

这里有一个典型的事件驱动架构图，首先是事件生产者发送事件到 EventBroker，然后 EventBroker 会把事件路由到对应的消费者进行事件处理。事件处理能够灵活扩展，随时增减事件消费者，事件生产者对此透明。

为什么说事件驱动是个很经典的设计模式呢？因为早在几十年前，就出现过多种事件驱动的技术，比如桌面客户端编程框架，点击按钮就可以触发 onclick 事件，开发者编写业务逻辑响应事件。在编程语言上，也经常会采用事件驱动的代码模式，比如 callback、handler 这类的函数。进入分布式系统的时代，系统之间的通信协同也会采用事件驱动的方式。

阅读过《RocketMQ 5.0 架构解析：如何基于云原生架构支撑多元化场景》一文的读者可能会发现，这里的图和之前 RocketMQ 的消息应用解耦图很像。没错，无论是消息的发布订阅，还是事件的生产消费，都是为了进行代码解耦、系统解耦。消息队列更偏技术实现，大部分的 EventBroker 都是基于消息队列实现的，而事件驱动则更偏向于架构理念。

2.2 事件的特征

从技术角度来看，消息队列是和 RPC 对应的，一个是同步通信，一个是异步通信。消息队列并不会规定消息的内容，只负责传输二进制内容。如果从技术实现来看，的确，EDA 需要的核心技术就是消息队列的技术。事件驱动跟消息驱动最大的区别就是：事件是一种特殊的消息&