3、事件驱动架构基础：事件源、事件总线、触发器、函数计算的关系

好，咱们进入第三章。这一章我打算聊聊事件驱动架构的核心组件。说实话，很多新手刚接触 Serverless 时，会被「事件源」、「事件总线」、「触发器」、「函数计算」这几个词绕晕。我当年也踩过这个坑，总觉得它们是一团乱麻。

其实说白了，它们之间的关系非常清晰。你想想看，就像一条流水线：事件源是原材料入口，事件总线是传送带，触发器是机械臂的感应开关，函数计算就是那个执行动作的机械臂。嗯，咱们一个一个拆开讲。

3.1 事件源：谁在产生事件？

事件源，就是事件的「生产者」。它负责在特定条件满足时，向外发出一个信号。这个信号可以是任何东西：一个文件上传了、一条消息入队了、一个定时器到点了、甚至是一个用户点击了按钮。

我个人习惯把事件源分为两大类：

• 云服务事件源：比如 OSS 对象存储、MNS 消息队列、SLS 日志服务、CDN 回源等。这些服务内部已经集成了事件发送能力，你只需要配置一下就行。
• 自定义事件源：比如你自己的应用代码、IoT 设备上报、第三方 Webhook 等。这些需要你手动将事件投递到事件总线中。

我在项目中遇到过最典型的场景：用户上传了一个 CSV 文件到 OSS，这个上传动作本身就是一个事件。OSS 作为事件源，会把这个事件「喊」出来：「嘿，有人传了个文件！」

3.2 事件总线：事件的「高速公路」

事件总线，你可以把它想象成一个智能路由器。它接收来自各个事件源的事件，然后根据你设定的规则，把事件路由到正确的目标。

为什么要多一个事件总线？直接让事件源调用函数不行吗？

嗯，这里有个设计上的考量。如果没有事件总线，事件源和函数就是点对点耦合的。一旦你想增加新的消费者、或者改变路由逻辑，就得改事件源的代码。这在微服务架构里简直是灾难。

事件总线解决了三个核心问题：

• 解耦：事件源不需要知道谁在消费事件，消费者也不需要知道事件从哪来。
• 过滤与转换：你可以只订阅感兴趣的事件，甚至对事件内容做格式转换。
• 可靠投递：事件总线通常会提供重试、死信队列等机制，确保事件不丢失。

我记得有一次，客户需要把 OSS 上传事件同时发给三个不同的函数：一个做图片压缩、一个做日志记录、一个做消息通知。如果没有事件总线，就得在 OSS 那边配置三个触发器，维护起来特别麻烦。用了事件总线后，一条规则搞定所有路由。

3.3 触发器：事件与函数的「连接器」

触发器，是连接事件总线和函数计算的桥梁。它负责监听事件总线上的特定事件，当匹配的事件到达时，自动触发函数执行。

你可能会问：「触发器和事件总线有什么区别？感觉功能重叠啊。」

其实，触发器的职责更单一。它只做两件事：

1. 监听：在事件总线上注册一个监听器，等待特定类型的事件。
2. 调用：当事件到达时，把事件数据作为参数传给函数，并启动函数实例。

我曾经犯过一个错误：在配置触发器时，没有设置好事件过滤规则。结果函数被大量无关事件频繁触发，不仅浪费了计算资源，还导致下游数据库压力暴增。后来我学乖了，每次配置触发器都会加上精确的过滤条件，比如只监听特定前缀的 OSS 文件上传事件。

3.4 函数计算：事件的「消费者」

函数计算，就是最终执行具体业务逻辑的地方。它接收触发器传递过来的事件数据，然后运行你的代码，处理完就销毁。

函数计算有几个特点：

• 无状态：每次调用都是独立的，不保留上下文。所以别指望在函数里缓存数据，除非你用外部存储。
• 按需启动：有事件来才启动，没事件就休眠。这也是 Serverless 省钱的核心原因。
• 自动扩缩：事件量大的时候，平台会自动拉起多个函数实例并行处理。你不需要关心服务器够不够用。

我习惯把函数计算比作「临时工」：有活就干，干完就走，不占编制。你想想看，如果公司里全是正式员工（长期运行的服务器），那没活的时候也得发工资。但用临时工（函数计算），有活才付钱，多划算。

3.5 四者的协作关系

现在咱们把四个角色串起来，看看它们是怎么协作的：

角色	职责	类比
事件源	产生事件	原材料入口
事件总线	路由事件	传送带 + 分拣员
触发器	监听并调用函数	机械臂的感应开关
函数计算	执行业务逻辑	机械臂本身

一个完整的流程是这样的：

1. 用户上传文件到 OSS（事件源产生事件）。
2. OSS 将事件发送到 EventBridge（事件总线）。
3. EventBridge 根据规则，将事件路由到对应的触发器。
4. 触发器接收到事件，调用函数计算实例。
5. 函数计算执行代码，处理文件内容。

嗯，这一章的内容就到这里。下一章咱们会深入实战，用代码演示如何搭建一个完整的事件驱动离线数据处理流水线。到时候你会看到，这些概念是如何落地到具体项目中的。