事件总线 + 函数计算构建云上最佳事件驱动架构应用

关于 RocketMQ 的更多实战避坑指南，可访问「RocketMQ 中文社区」查看领域专家QA实录👨‍💻

距离阿里云事件总线（EventBridge）和 Serverless 函数计算（Function Compute，FC）宣布全面深度集成已经过去一年，站在系统元数据互通，产品深度集成的肩膀上，这一年我们又走过了哪些历程？从事件总线到事件流，从基于 CloudEvents 的事件总线触发到更具个性化的事件流触发，函数计算已成为事件总线生态不可或缺的重要组成部分，承载了 EventBridge 系统架构中越来越多的角色，事件流基础架构的函数 Transform，基于函数计算的多种下游 Sink Connector 投递目标支持，函数作为 EventBridge 端点 API Destination；基于事件总线统一，标准的事件通道能力，和基于函数计算敏捷、轻量、弹性的计算能力，我们将又一次起航探索云上事件驱动架构的最佳实践。

今天的主题围绕事件总线+函数计算，构建云上最佳事件驱动架构应用。希望通过今天的分享，能够帮助大家深入理解 Serverless 函数计算、EventBridge 事件总线对于构建云上事件驱动架构应用的价值和背后的逻辑、 为什么函数计算是云上事件驱动服务最佳实践？为什么我们如此需要事件总线服务？伴随着这些谜题的解开，最后，让我们一起了解应用于实际生产的一些 Serverless 事件驱动客户案例。

事件驱动架构的本质

Back to the Nature of Event-Driven

大家可能会疑惑，事件驱动家喻户晓，为什么我们又要重新讨论事件驱动呢？我想这也正是我们需要讨论它的原因，回归本质，重新起航；事件驱动可能是一个比较宽泛的概念，而本文聚焦事件驱动架构的讨论，事件驱动架构作为一种软件设计模式，的确不是一个新的概念，伴随着计算机软件架构的演进，它已经存在了一段很久的时间，大家对它的讨论也从未停止过，当我们需要重新讨论一个已经存在的概念的时候，我想我们有必要重新回到它最开始的定义，一起探索那些本质的东西，重新认识它。

上面的这些内容是我从相关的一些资料上摘录的关于事件驱动的一些描述，“abstract”，“simple”，“asynchronous”，“message-driven”这些具有代表性的词汇很好的给予事件驱动一个宏观的描述；从事件驱动的抽象概念，到它简洁的架构，以及事件驱动架构要达成的目的，和它在实际的系统架构中所展现的形态。

事件驱动架构基本概念及形态

在了解了关于事件驱动架构的一些基本描述之后，我们需要进一步明确事件驱动架构所涉及的一些基本概念和架构形态。根据维基百科描述，事件驱动架构涉及的核心概念如下所示：

围绕事件的流转，根据事件驱动架构的概念和基本形态，主要涉及以下四个核心部分：

• Event Producer：负责产生事件，并将产生的事件投递到事件通道；
• Event Channel：负责接收事件，并将接收的事件持久化存储，投递给订阅该事件的后端处理引擎；
• Event Processing Engine：负责对于订阅的事件做出响应和处理，根据事件更新系统状态；
• Downst