2. Amazon EventBridge入门

Amazon EventBridge 的核心价值在于把“谁产生了什么事件”与“谁需要对这个事件做出反应”解耦。要真正用好它，需要理解四个基本构件：事件总线（Event Bus）负责接收事件，规则（Rule）负责筛选与分发，事件模式（Event Pattern）定义匹配条件，目标（Target）决定事件最终被投递到哪里。这四者串起来，就构成了 EventBridge 的路由机制。

事件总线：事件的入口与隔离边界

事件总线是一个接收事件的通道。每个 AWS 账户默认有一个默认事件总线（default bus），AWS 服务（如 EC2 状态变化、S3 对象创建、CloudTrail API 调用）产生的事件会自动发送到默认总线。除此之外，还可以创建自定义事件总线（custom bus），用于接收来自自有应用、SaaS 集成或跨账户转发的事件。

事件总线的关键作用是隔离。例如，生产环境与测试环境各自使用独立的自定义总线，规则只作用于本总线上的事件，避免测试流量误触发生产逻辑。跨账户场景下，也可以把事件从账户 A 的总线转发到账户 B 的总线，再在 B 中配置规则，实现集中式事件处理。

向总线发送事件的方式主要有两种：一是 AWS 服务自动投递；二是通过 PutEvents API 主动写入。一个 PutEvents 请求最多可包含 10 条事件，单条事件最大 256 KB。事件体是一个 JSON 对象，典型结构如下：

{
  "Source": "com.myapp.orders",
  "DetailType": "OrderCreated",
  "Detail": "{\"orderId\":\"A1001\",\"amount\":199.00,\"region\":\"cn-north-1\"}",
  "EventBusName": "orders-bus"
}

其中 Source、DetailType、Detail 是自定义事件最常用的字段，它们会直接参与后续的事件模式匹配。

规则与事件模式：筛选逻辑的核心

规则绑定在某个事件总线上，它由两部分组成：事件模式（匹配什么事件）和目标列表（匹配后做什么）。一条规则可以配置多个目标，最多 5 个；一个事件总线可以有多条规则，同一条事件可以同时匹配多条规则，从而触发多个下游动作。

事件模式是一个 JSON 结构，采用“字段名匹配字段值”的方式。它支持精确匹配、前缀匹配、数值范围匹配、数组匹配以及 anything-but 等操作符。下面这条模式表示：只匹配来源为 com.myapp.orders、类型为 OrderCreated，且金额大于 100 的订单事件：

{
  "source": ["com.myapp.orders"],
  "detail-type": ["OrderCreated"],
  "detail": {
    "amount": [{ "numeric": [">", 100] }]
  }
}

需要注意：事件模式中的字段名是大小写敏感的，且 source、detail-type 是 EventBridge 的顶层字段，而业务字段（如 amount）位于 detail 内部。如果模式中写了 detail.amount 却把 amount 放在顶层，就不会匹配成功。这是初学者最常见的排障点之一。

目标：事件最终去向

规则匹配成功后，事件会被投递到一个或多个目标。常见目标包括：Lambda 函数、SQS 队列、SNS 主题、Kinesis Data Streams、Step Functions 状态机、ECS 任务、API Gateway、以及另一条事件总线。每个目标可以配置输入转换器（Input Transformer）或输入路径（Input Path），把原始事件裁剪或重组成下游更容易消费的格式。

例如，Lambda 目标通常只需要事件中的 orderId 和 amount，可以用输入路径 {"orderId":"$.detail.orderId","amount":"$.detail.amount"} 只传递这两个字段，减少下游解析负担。目标还支持死信队列（DLQ）和重试策略：当目标不可用或调用失败时，EventBridge 会按重试策略重试，仍失败则把事件送入 DLQ，便于后续排查。

路由机制全景

把上述构件连起来看，EventBridge 的路由过程是：事件进入总线 → 规则用事件模式逐条匹配 → 匹配成功的规则把事件投递给目标 → 目标执行具体动作。下图展示了这一完整链路，并标出了事件模式匹配、输入转换和失败重试三个关键环节。

一个可落地的配置示例

假设订单服务在创建订单后向自定义总线 orders-bus 写入事件，希望金额大于 100 的订单触发 Lambda 做风控检查，同时所有订单都进入 SQS 做异步归档。可以这样组织：

1. 创建自定义事件总线 orders-bus。
2. 创建规则 high-value-rule，事件模式使用上面的数值匹配，目标为风控 Lambda。
3. 创建规则 archive-rule，事件模式只匹配 source 和 detail-type，目标为归档 SQS 队列。
4. 为两条规则分别配置 DLQ，并给 Lambda 目标设置输入路径，只传递 orderId 与 amount。

验证时，用 PutEvents 写入一条 amount=199 的事件，应同时触发风控 Lambda 和归档 SQS；再写入一条 amount=50 的事件，则只进入归档 SQS，不触发风控。通过 CloudWatch 指标 Invocations、FailedInvocations 以及 Lambda 日志，可以判断规则是否按预期匹配和投递。

理解总线、规则、事件模式与目标之间的关系后，EventBridge 就不再是一个黑盒：事件从哪来、被谁匹配、去了哪里、失败怎么办，都可以沿着这条链路逐段定位。这也是后续学习事件驱动架构、跨账户事件共享和事件治理的基础。