C2-11-消息、事件、应用集成与开发工具-本章目标与同步调用的问题-为什么要异步化？
与Amazon-SQS与Standard-Queue-与-FIFO-Queue与Dead-Letter-Queue（DLQ）与Amazon-SNS与Amazon-EventBridge与AWS-Step-Functions与Amazon-API-Gateway与Amazon-SES与开发工具-从代码到部署与GlobalShop-事件驱动架构与高频四服务对比与本章最后要形成的判断方式与与后续章节的关系
本篇是《C2-11-消息、事件、应用集成与开发工具》的第1个分篇，主要包含：本章目标、同步调用的问题-为什么要异步化？
Amazon-SQS、Standard-Queue-与-FIFO-Queue、Dead-Letter-Queue（DLQ）、Amazon-SNS、Amazon-EventBridge、AWS-Step-Functions、Amazon-API-Gateway、Amazon-SES、开发工具-从代码到部署、GlobalShop-事件驱动架构、高频四服务对比、本章最后要形成的判断方式、与后续章节的关系。
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-高频四服务对比
| 服务 | 核心模型 |
|---|---|
| SQS | Queue / Buffer / Decouple |
| SNS | Topic / Pub-Sub / Fanout |
| EventBridge | Event Bus / Rule / Event Routing |
| Step Functions | Workflow / State Machine / Orchestration |
14-本章最后要形成的判断方式
不要把本章记成一串 AWS 产品名，而要形成下面的思考路径：
业务需求是什么？
↓
它属于哪一层问题？
↓
需要什么技术能力？
↓
哪些 AWS 服务提供这类能力？
↓
为什么某一个更贴合场景？
↓
其他相似服务为什么不合适？
真正稳定的考试能力不是“看到关键词就背答案”，而是能够从业务要求推导到技术能力，再从技术能力推导到 AWS 服务。
15-与后续章节的关系
C2 负责建立技术体系本身。
完整业务架构组合会在 C3 中继续展开。
719 道题的逐题选项解析放在 C4。
频率排名与强化学习放在 C5。
考前压缩复习放在 C6。
本篇概述
- 本篇梳理了本章目标相关的核心知识、适用场景与判断要点。
- 本篇梳理了同步调用的问题-为什么要异步化？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了Amazon-SQS相关的核心知识、适用场景与判断要点。
- 本篇梳理了Standard-Queue-与-FIFO-Queue相关的核心知识、适用场景与判断要点。
- 本篇梳理了Dead-Letter-Queue（DLQ）相关的核心知识、适用场景与判断要点。
- 本篇梳理了Amazon-SNS相关的核心知识、适用场景与判断要点。
- 本篇梳理了Amazon-EventBridge相关的核心知识、适用场景与判断要点。
- 本篇梳理了AWS-Step-Functions相关的核心知识、适用场景与判断要点。
- 本篇梳理了Amazon-API-Gateway相关的核心知识、适用场景与判断要点。
- 本篇梳理了Amazon-SES相关的核心知识、适用场景与判断要点。
- 本篇梳理了开发工具-从代码到部署相关的核心知识、适用场景与判断要点。
- 本篇梳理了GlobalShop-事件驱动架构相关的核心知识、适用场景与判断要点。
- 本篇梳理了高频四服务对比相关的核心知识、适用场景与判断要点。
- 本篇梳理了本章最后要形成的判断方式相关的核心知识、适用场景与判断要点。
- 本篇梳理了与后续章节的关系相关的核心知识、适用场景与判断要点。