跳到主要内容

C2-11-消息、事件、应用集成与开发工具

资料口径说明：本章延续当前 AWS CLF-C02 学习项目既有规则，主要依据用户提供的 719 题题库、chatGPT会话1.md、chatGPT会话2.md、cmd1.md 与前序 C2 章节的结构整理。题库中的答案与评论用于识别高频考点、业务场景和易混项，不自动视为当前 AWS 官方结论。涉及会随时间变化的产品状态、考试范围与 Support 体系时，本章只沿用项目资料中已经明确记录的状态；正式考试前仍应再对照 AWS 当前官方页面。

1-本章目标​

单体应用内部一个函数调用另一个函数很简单；分布式系统则会遇到：订单服务挂了，邮件服务要不要跟着失败？、一个事件如何通知多个系统？、突发流量如何削峰？、工作流多个步骤如何编排？、外部客户端如何调用 Serverless API？、代码如何持续构建和发布？项目资料把当前核心 Application Integration 主线整理为：

Queue      → SQS
Pub/Sub    → SNS
Event Bus  → EventBridge
Workflow   → Step Functions

2-同步调用的问题：为什么要异步化？​

如果下单请求串行执行：

Create Order
   ↓
Deduct Inventory
   ↓
Send Email
   ↓
Update Points
   ↓
Notify Logistics

任何一步变慢都会拖慢用户响应。异步与解耦的核心思想：

Producer
   │
   ▼
Message / Event
   │
   ▼
Consumer

Producer 不需要在同一个同步调用链中等待所有 Consumer 完成。

3-★★★★★-Amazon-SQS​

正式名称： Amazon Simple Queue Service；；；中文： Amazon 简单队列服务

3.1-为什么需要它​

生产者与消费者速度不同，或者消费者暂时故障时，需要一个可靠缓冲区保存消息，避免系统强耦合。

3.2-它是什么​

SQS 是托管 Message Queue。Producer 把 Message 放入 Queue，Consumer 以自己的速度拉取并处理。

3.3-GlobalShop-场景​

GlobalShop 下单成功后把“生成发票”任务写入 SQS，发票 Worker 可以慢慢处理，即使临时重启也不会让下单接口同步失败。

3.4-常见组合​

Application/Lambda → SQS → Lambda/EC2/ECS Consumer；SNS → multiple SQS queues。

3.5-容易混淆​

SQS ≠ SNS：SQS 是 Queue 缓冲；SNS 是 Pub/Sub 推送扇出。

3.6-题库通常怎么考​

decouple、buffer、queue、asynchronous processing、spike smoothing → SQS。

4-Standard-Queue-与-FIFO-Queue​

4.1-Standard​

目标是高吞吐、at-least-once delivery 语义，需要应用能够处理重复消息可能性，顺序也不是严格全局保证。

4.2-FIFO​

FIFO = First-In-First-Out。强调顺序和去重语义，适合需要严格消息顺序的一类业务。考试不要把“消息队列”自动等于 FIFO，只有场景明确强调顺序/重复控制才重点考虑 FIFO。

5-★★★-Dead-Letter-Queue（DLQ）​

重复处理仍失败的消息可以进入 DLQ，以便隔离和排查。

Main Queue
   │ retry failed
   ▼
Dead-Letter Queue

6-★★★★★-Amazon-SNS​

正式名称： Amazon Simple Notification Service；；；中文： Amazon 简单通知服务

6.1-为什么需要它​

同一个事件往往需要同时通知多个系统或人，例如订单完成后通知库存、物流、分析、Email/SMS。

6.2-它是什么​

SNS 是托管 Pub/Sub 通知服务。Publisher 发布到 Topic，多个 Subscriber 可以接收通知。

6.3-GlobalShop-场景​

GlobalShop 的 OrderCreated 发布到 SNS Topic，再扇出到多个 SQS Queue、Lambda 或通知终端。

6.4-常见组合​

SNS Topic → SQS/Lambda/HTTP(S)/Email/SMS 等订阅目标。

6.5-容易混淆​

SNS ≠ SQS：SNS 负责一对多扇出；SQS 负责缓冲与消费者拉取处理。实际经常组合 SNS → SQS。

6.6-题库通常怎么考​

fanout、publish/subscribe、send notification to many subscribers、SMS/email → SNS。

7-★★★★-Amazon-EventBridge​

正式名称： Amazon EventBridge；；；中文： 事件总线服务

7.1-为什么需要它​

现代系统有很多 AWS 服务、SaaS 和业务事件，需要按事件内容进行路由，而不是所有组件直接互相调用。

7.2-它是什么​

EventBridge 是事件总线服务，通过 Event Bus 与 Rule 根据事件模式把 Event 路由到 Target。

7.3-GlobalShop-场景​

GlobalShop 把 OrderCreated、PaymentFailed、ProductUpdated 等事件送入 EventBridge，由规则分别触发 Lambda、Step Functions、SQS 等。

7.4-常见组合​

AWS Services/SaaS/App → EventBridge → Lambda/SQS/SNS/Step Functions。

7.5-容易混淆​

EventBridge 与 SNS 都可做一对多事件分发，但 EventBridge 更强调事件路由、事件模式、事件总线与 SaaS/AWS 事件集成。

7.6-题库通常怎么考​

event bus、event pattern、route events from AWS services/SaaS → EventBridge。

8-★★★★-AWS-Step-Functions​

正式名称： AWS Step Functions；；；中文： Serverless 工作流编排服务

8.1-为什么需要它​

复杂业务需要把多个 Lambda、服务调用和人工/自动步骤按顺序、条件、重试、并行逻辑组织起来。

8.2-它是什么​

Step Functions 使用 State Machine 描述工作流状态与转换，负责编排任务执行。

8.3-GlobalShop-场景​

GlobalShop 退款流程：校验订单 → 调支付退款 → 回补库存 → 发通知；失败时按状态重试或进入补偿流程。

8.4-常见组合​

Step Functions → Lambda/ECS/API/AWS SDK integrations；EventBridge → Step Functions。

8.5-容易混淆​

Step Functions ≠ SQS。SQS 是消息队列；Step Functions 是工作流 orchestration。

8.6-题库通常怎么考​

workflow、state machine、coordinate multiple serverless steps、visual workflow → Step Functions。

9-★★★★-Amazon-API-Gateway​

正式名称： Amazon API Gateway；；；中文： API 网关托管服务

9.1-为什么需要它​

移动端、Web 前端和合作伙伴需要一个统一 HTTP API 入口，还需要路由、认证、限流、阶段管理等 API 管理能力。

9.2-它是什么​

API Gateway 用于创建、发布、维护、监控和保护 API，常作为 Lambda Serverless 后端入口。

9.3-GlobalShop-场景​

GlobalShop Mobile App 调用 /orders，API Gateway 接收请求并触发 Lambda。

9.4-常见组合​

Client → API Gateway → Lambda；API Gateway + Cognito/WAF。

9.5-容易混淆​

API Gateway ≠ Internet Gateway/NAT Gateway。它是应用 API 管理服务，而不是 VPC 网络网关。

9.6-题库通常怎么考​

REST/HTTP API、serverless API front door、throttling、API management → API Gateway。

10-★★★-Amazon-SES​

SES = Simple Email Service。用于大规模发送和接收 Email 的托管服务。SNS 也能发送某些通知邮件，但如果题目重点是 transactional email、marketing email、大规模邮件投递平台，SES 更贴合。

11-开发工具：从代码到部署​

C2 的重点不是教你写 CI/CD YAML，而是理解流水线角色。

11.1-★★★-AWS-CodeBuild​

托管 Build 服务：编译、测试、生成 Artifact。

11.2-★★★-AWS-CodePipeline​

持续交付 Pipeline 编排，把 Source → Build → Test → Deploy 阶段串起来。

Source
  │
  ▼
CodePipeline
  │
  ├── Build → CodeBuild
  ├── Test
  └── Deploy

项目资料已明确：某些旧开发工具在当前考试范围可能变化，因此此处以理解“CI/CD 与服务角色”为主，当前考试范围应以官方最新 In-Scope 清单复核。

12-GlobalShop-事件驱动架构​

User places order
      │
      ▼
 Order Service
      │
      ├── SQS ─────────→ Invoice Worker
      │
      ├── SNS ─────────→ Email / SMS / SQS consumers
      │
      └── EventBridge
             │
             ├── Inventory Lambda
             ├── Analytics Pipeline
             └── Step Functions Refund/Workflow

External Client
      │
      ▼
 API Gateway
      │
      ▼
    Lambda

13-高频四服务对比​

服务核心模型
SQSQueue / Buffer / Decouple
SNSTopic / Pub-Sub / Fanout
EventBridgeEvent Bus / Rule / Event Routing
Step FunctionsWorkflow / State Machine / Orchestration

14-本章最后要形成的判断方式​

不要把本章记成一串 AWS 产品名，而要形成下面的思考路径：

业务需求是什么？
        ↓
它属于哪一层问题？
        ↓
需要什么技术能力？
        ↓
哪些 AWS 服务提供这类能力？
        ↓
为什么某一个更贴合场景？
        ↓
其他相似服务为什么不合适？

真正稳定的考试能力不是“看到关键词就背答案”，而是能够从业务要求推导到技术能力，再从技术能力推导到 AWS 服务。

15-与后续章节的关系​

C2 负责建立技术体系本身；完整业务架构组合会在 C3 中继续展开；719 道题的逐题选项解析放在 C4；频率排名与强化学习放在 C5；考前压缩复习放在 C6。