事件源触发：API Gateway、SQS与EventBridge

可视化演示

演示API Gateway同步请求、SQS消息队列消费、EventBridge事件总线路由三种事件源触发Lambda的流程，可切换模式观察同步与异步语义。

事件驱动本质

在“幸福小馆”里，什么叫“一个订单”？不是顾客走进门那一刻，而是“某件事发生了变化”——比如顾客点了一份红烧肉、外卖箱里多了一张订单条、广播里说缺了青椒。这些变化本身，加上变化携带的信息，合在一起就是一个事件。事件不是一个动作，而是“已经发生了某个事实”的记录。

在 Serverless 世界里，事件驱动模型正是这样运转的：某个系统或服务发生状态变化，产生一条事件，事件被送到触发器，触发器再把事件转交给函数去处理。事件可以来自 HTTP 请求、数据库变更、文件上传、定时器，甚至是另一个函数。而 FaaS（函数即服务） 的核心机制，就是“无事不调用”——没有事件，函数就安静地待着；一旦事件到达，平台立刻拉起函数实例处理。

回到小馆：前台喊“红烧肉一份”，如果只喊菜名不带桌号，后厨就不知道该送给谁。事件也一样，变化和数据缺一不可。理解这一点，你就踏进了事件驱动世界的大门——后面所有触发器的故事，都是从这条等式开始的。

网关触发

前台点单是“幸福小馆”最直观的接单方式：顾客走到前台，报出菜名，师傅当场开火，做好后端上桌，顾客拿到菜才算完事。这种“一问一答、立刻见分晓”的模式，就是 API Gateway 触发 Lambda 的写照。

API Gateway（API 网关）是云上的一道正门：它接收 HTTP 请求（比如 POST /orders），把请求转换成事件，同步调用你的 Lambda 函数，然后把函数的返回值转换成 HTTP 响应交还给客户端。整个过程是同步调用——客户端发起请求后，必须等待函数执行完毕拿到结果。这个模型适合在线交互场景，比如用户登录、下单、查询余额，这些都需要“立刻知道答案”。

既然是同步等待，我们就得关心一个关键问题：要支撑多少并发？如果每秒进来大量请求，函数能不能接得住？

前台点单的好处是响应快、逻辑简单，但代价是后厨必须“随叫随到”。如果顾客下单太猛，师傅就得不停加灶台——对应到 Serverless 里就是并发数飙升、成本上升。所以，API Gateway 适合那些真的需要即时回答的业务，而“不需要立刻吃上饭”的订单，放进外卖箱更合适。

队列触发

“幸福小馆”门口挂着一个大外卖箱。顾客把写好的订单条丢进去就走了，师傅不急着去拿，而是等手头这波堂食忙完，再去箱子里一把抓出几张订单条，集中做。这就是 SQS（简单队列服务） 的节奏。

SQS 是一个托管消息队列。生产者（Producer）把消息放进队列，队列把消息暂时存起来；Lambda 作为消费者（Consumer）定期从队列里“捞”消息。因为有队列这个缓冲层，生产者和消费者彼此解耦——即使消息突然暴增，队列会先攒着，消费者量力而行，不会把系统冲垮。

SQS 触发 Lambda 时，平台采用“拉取—批处理—调用”的模式。你可以配置两个重要参数：BatchSize（每批最多几条消息）和 MaximumBatchingWindow（最多等多久凑一批）。比如设置每批 10 条、最多等 5 秒，那么队列里哪怕只有 2 条，也会在 5 秒后被取走处理。

外卖箱模式之所以好用，在于“缓冲”二字——它天然扛得住流量洪峰，消费者可以按自己的节奏批量处理。代价是延迟增加了：顾客点完外卖不能立刻拿到餐。但很多业务（如发通知、处理日志、数据清洗）根本不需要秒级响应，把它们放进 SQS，就是给系统装了一个“压力缓震器”。

事件路由

“幸福小馆”装了一套广播系统。店长对着麦克风喊：“红烧肉的葱不够了，谁补一下！”，听到的档口会自己判断“这关我事不关我事”——备菜间去补葱，收银台不会跑去做菜。这就是 EventBridge（事件总线） 的工作方式。

EventBridge 的核心是事件总线：各种事件源（如云服务、自定义应用、定时器）把事件发送到总线，总线根据规则把事件路由到合适的目标（比如 Lambda 函数、SQS 队列、HTTP 端点）。和 SNS 那种“广播给所有人”不同，EventBridge 的规则可以做精细的字段匹配——比如“只把金额大于 1000 的订单事件发给风控函数”。

一个事件带上 source（来源）、detail-type（事件类型）、detail（具体数据）等字段。规则就像一连串筛子，逐层过滤事件。命中规则的事件，才会被投递给目标；没命中的，就静悄悄地在总线上消失。

广播模式最迷人的地方是解耦：事件生产者根本不需要知道谁在听。小馆的店长喊完广播，不用挨个通知备菜间、收银台——谁关心谁响应。这种“发布—订阅”思想，让系统里各个模块像乐队各声部一样，各自独立又彼此合拍。

触发模式对比

三种接单方式各有脾气。前台点单快但费人力，外卖箱能扛量但慢，广播灵活但需要大家自觉听。选择哪种，本质上是在问：这个业务更在乎什么？

API Gateway 同步触发的显著特点是低延迟、强一致——客户端立刻拿到结果，适合用户在线交互。SQS 异步触发的特点是高吞吐、强缓冲——流量再猛也有队列顶着，适合批量处理、削峰填谷。EventBridge 事件路由的特点是高灵活、强解耦——它不关心“谁发起”，只关心“规则是否匹配”，适合系统内部事件广播和复杂路由。

延迟上，API Gateway 最快（几百毫秒级）；SQS 因为有轮询间隔，通常有几秒延迟；EventBridge 介于两者之间。吞吐上，SQS 凭借批量处理能力，可以吸收极高的消息量；API Gateway 的吞吐受函数并发限制；EventBridge 在匹配后把事件推给目标，吞吐很高但受目标自身约束。

选型时，可以用一个简单的加权评分模型：

这就好比小馆选外卖策略：高端餐厅追求体验，必须前台现做现吃（同步）；快餐店追求出单量，多接外卖单（异步）；连锁店要协调多家分店，则靠总部的广播调度（事件路由）。没有最好的触发器，只有最合适的组合。

语义保证

“幸福小馆”对顾客有个朴素的承诺：你的订单绝不会丢，但有可能多做一份。这不是偷懒，而是分布式系统的现实——当 SQS 把消息投递给 Lambda 函数后，如果函数执行中途超时或崩溃，SQS 不会知道消息是否处理成功，于是会把消息重新放回队列，再次投递。这就是至少一次语义：每条消息保证会被处理，但不保证只处理一次。

正因为消息可能重复，函数必须设计成幂等——同一个事件处理一次和处理十次，结果完全一样。比如处理订单时，不是盲目给用户加积分，而是先检查“这个订单号是否已经加过积分”，加过就直接返回成功。幂等性是 Serverless 事件的“防重复保险丝”。

另一个关键设计是重试。当函数执行失败时，平台会按配置自动重试。SQS 触发器默认启用重试，一条消息最多被接收多少次可在队列的 maxReceiveCount 中配置。超过最大接收次数，消息就会进入死信队列（DLQ）——一个专门存放“怎么也处理不好”的消息的隔离区。

这个诚实承诺，让开发者在设计系统时多了一根弦：宁可重复做，不可漏做。就像餐厅宁可多炒一份菜放着，也不敢让客人饿肚子。理解“至少一次”，也就理解了为什么幂等设计不是锦上添花，而是 Serverless 应用的生存底线。

编排与容错

当“幸福小馆”同时运营堂食、外卖、团餐三条业务线时，单靠一个师傅就不够了——需要有人统筹调度、有人盯着异常、有人处理客诉。Serverless 里的多源编排，就是让多个事件源协同工作，共同完成一个复杂业务流。

一个典型的编排例子：用户下单后，API Gateway（在线点单）同步创建订单并返回成功；订单创建事件发给 EventBridge，由规则路由到两个目标——SQS 队列（通知物流服务异步处理）和另一个 Lambda（风控审查）。整个过程里，不同事件源各司其职，像一条流水线上的不同工序。

错误处理是编排的重中之重。每个环节都可能失败：函数超时、下游服务不可用、消息格式错误。应对策略包括：配置合理的重试次数、设置超时阈值、将多次重试仍失败的消息送入 DLQ，由专门的消费者函数定期分析排障。监控告警则让一切透明化——通过 CloudWatch 指标观察函数调用次数、错误率、并发数、队列深度，设置告警阈值，比如“队列积压超过 1000 条时触发告警”。

回到小馆，一个好的店长不会等到客人投诉了才发现问题，而是通过“后厨出菜速度”“外卖箱积压量”这些指标提前预判。编排与容错的意义，就是让系统在复杂多变的环境里，不仅能跑得快，更能跑得稳——出了问题能发现、能定位、能恢复。

AI 应用场景

Python 演示

"""模拟 Serverless 三类事件源触发：API Gateway 同步调用、SQS 批处理消费、EventBridge 规则匹配路由。"""import randomimport timeimport uuid  class LambdaFunction:    """模拟一个 Serverless 函数，记录处理结果，支持失败重试"""     def __init__(self, name: str) -> None:        self.name = name        self.success_count = 0        self.failure_count = 0     def invoke(self, event: dict) -> bool:        """执行一次调用，约 20% 概率失败，模拟不稳定下游"""        time.sleep(0.01)        if random.random() < 0.2:            self.failure_count += 1            return False        self.success_count += 1        return True     def report(self) -> dict:        """返回统计信息"""        return {            "name": self.name,            "success": self.success_count,            "failure": self.failure_count        }  def api_gateway_invoke(fn: LambdaFunction, payload: dict) -> str:    """API Gateway 同步调用：请求-响应直达结果"""    ok = fn.invoke({"source": "api", "payload": payload})    return "200 OK" if ok else "502 Bad Gateway"  def sqs_batch_invoke(fn: LambdaFunction, queue: list, batch_size: int = 3) -> list:    """SQS 批处理触发：从队列中取一批消息交给函数"""    results = []    batch = queue[:batch_size]    for msg in batch:        ok = fn.invoke({"source": "sqs", "body": msg})        results.append("success" if ok else "retry")    return results  def eventbridge_route(fn: LambdaFunction, event: dict) -> str:    """EventBridge 规则匹配：命中 detail-type 才触发函数"""    if event.get("detail-type") == "order.created":        fn.invoke({"source": "eventbridge", "detail-type": event["detail-type"]})        return "matched"    return "skipped"  if __name__ == "__main__":    fn = LambdaFunction("订单处理函数")     # 场景一：API Gateway 收到下单请求，同步返回结果    print(api_gateway_invoke(fn, {"action": "create_order"}))     # 场景二：SQS 队列有 5 条消息，按批处理一次取 3 条    queue = [{"order_id": str(uuid.uuid4())} for _ in range(5)]    print(sqs_batch_invoke(fn, queue, batch_size=3))     # 场景三：EventBridge 广播订单事件，仅匹配的触发    print(eventbridge_route(fn, {"detail-type": "order.created", "detail": {"amount": 88}}))     # 输出函数运行统计    print(fn.report())

1. class LambdaFunction:定义函数容器，统计成功/失败次数，模拟真实 FaaS 中函数被反复调用的场景。
2. def invoke(self, event: dict) -> bool:模拟函数执行过程，用随机数制造 20% 的失败率，模拟不稳定下游。
3. ok = fn.invoke({"source": "api", "payload": payload})API Gateway 同步调用，直接等待函数执行结果。
4. batch = queue[:batch_size]SQS 触发器按批次取消息，而不是逐条调用，这是高吞吐的关键。
5. if event.get("detail-type") == "order.created":EventBridge 通过规则字段匹配决定是否触发函数。
6. print(fn.report())输出函数累计处理情况，便于验证不同事件源模式下函数的行为差异。

常见误区

面试题