什么是 Serverless

什么是 Serverless

Serverless 是一种云计算服务模型，允许开发者构建和运行应用程序，而无需关心底层服务器的管理。

在 Serverless 架构中，应用程序由事件触发的小型函数组成，这些函数由云服务提供商动态地管理和扩展。

Serverless 解决了什么问题

• 运维复杂性：传统的服务器管理涉及到配置、维护和监控，而 Serverless 将这些任务交给云服务提供商，开发者无需关注。

• 弹性扩展：Serverless 提供弹性伸缩，按需自动调整资源，无需手动调整服务器规模，从而更好地适应应用的变化。

• 成本优化：通过按使用量计费，Serverless 让开发者只需支付实际使用的计算资源，而无需预先购买和维护庞大的服务器群。

• 快速部署：Serverless 允许开发者快速部署应用，而无需关心服务器的配置和环境问题。

Serverless 的特点和优势

• 事件驱动：Serverless 应用通常是事件驱动的，函数在特定事件发生时被触发执行，如 HTTP 请求、文件上传等。

• 无服务器架构：开发者不需要关心服务器的配置、维护和扩展，只需编写函数代码，云服务商负责处理底层基础设施。

• 按需计费：Serverless 模型按照实际使用的资源进行计费，开发者只需支付实际消耗的计算资源，而不需要预先购买。

• 自动扩展：Serverless 提供自动伸缩能力，根据请求负载自动调整资源，确保应用在高负载时能够保持响应。

• 多语言支持：支持多种编程语言，开发者可以根据项目需求选择最适合的语言来编写函数。

• 无状态函数：Serverless 函数通常是无状态的，每个函数都是独立的，不保留上下文信息，使得水平扩展更容易实现。

• 快速部署：Serverless 应用可以更快速地部署和更新，无需关心底层基础设施的变化。

Serverless 的应用场景

• Web 应用前端：用于构建静态网站、单页应用、SSR、NodeJS 应用等前端应用。

• API 和后端服务：构建 RESTful API、后端服务、微服务等，使开发者能够快速部署和扩展。

• 数据处理：适用于数据处理、转换、清洗、分析等场景，例如处理实时日志、图像处理等。

• 实时通知：Serverless 可以用于构建实时通知系统，例如推送通知、即时聊天等。

• 定时任务：用于执行定时触发的任务，如定时备份、数据清理等。

• IoT 应用：处理大量传感器数据，进行实时分析和响应，适用于物联网应用。

• 事件驱动的处理：使用 Serverless 构建事件驱动的处理系统，例如处理队列消息、数据库变更通知等。函数可以根据事件动态触发，响应不同的事件类型。

• 自动化工作流：Serverless 可以用于构建自动化工作流，例如自动化部署、自动化测试、自动化数据流程等。函数可以作为工作流的各个步骤。

半中心化前端架构部署方案

这套AWS + Cloudflare 混合云架构 (opens new window)要做到对其中的每个模块都很熟悉。

Cloudflare Waiting Room

Cloudflare Waiting Room (opens new window) 是 Cloudflare 提供的一种流量排队管理服务，用于在网站流量激增时保护源服务器，防止因过载而崩溃。

它的核心原理是，当访问者数量超过你设定的阈值时，多余的用户会被引导到一个虚拟等候室页面，按顺序等待进入网站，而不是直接收到 502/503 错误。

相比自建排队系统，Cloudflare Waiting Room 的优势在于：流量在到达源服务器之前就被拦截在 Cloudflare 边缘节点，源站完全不承受超载压力，且无需修改任何后端代码，配置几分钟即可生效。

使用 Cloudflare Waiting Room 可以实现等冷启动完毕后再把流量切过去。利用 Queue All 模式：

1. 部署前 → 手动开启 "Queue All"（所有用户强制排队）

2. 服务冷启动、预热完毕

3. 手动关闭 "Queue All" → 流量正常放行

这样用户会看到等候页面，冷启动期间零流量打到源站。

Cloudflare Pages

Cloudflare Pages (opens new window) 是 Cloudflare 提供的静态网站 & 全栈应用托管平台，类似 Vercel / Netlify，但依托 Cloudflare 全球边缘网络。

代码推送 → 自动构建 → 部署到全球 300+ 边缘节点 → 用户就近访问

部署 & 构建

• 连接 GitHub / GitLab，push 代码自动触发构建

• 支持主流框架：Next.js、Nuxt、SvelteKit、Astro、React、Vue 等

• 每个 PR 自动生成预览链接（Preview Deployments）

• 支持回滚到任意历史版本

网络 & 性能

• 静态资源部署在 Cloudflare CDN 边缘，全球低延迟

• 免费自定义域名 + 自动 HTTPS

• HTTP/3、Brotli 压缩开箱即用

全栈能力（Pages Functions）

• 在 Pages 项目里写 /functions 目录即可添加服务端逻辑

• 底层是 Cloudflare Workers，运行在边缘节点

• 支持中间件、动态路由

免费套餐限制

项目	免费额度
每月构建次数	500 次
并发构建	1 个
自定义域名	无限
带宽	无限
请求数	无限
Pages Functions 请求	10 万次/天

Cloudflare Workers

Cloudflare Workers (opens new window) 是 Cloudflare 的边缘计算平台，让你在全球 300+ 个数据中心的边缘节点上运行代码，而不是在某个固定的中心化服务器上。

运行时特点

Workers 不是 Node.js，也不是容器，而是基于 V8 Isolate：

特性	说明
运行时	V8 Isolate（Chrome 同款 JS 引擎）
启动时间	< 5ms，几乎无冷启动
内存限制	128MB
CPU 时间	免费版 10ms，付费版 30s
支持语言	JS / TS / Rust / C / C++（编译为 WASM）
兼容性	部分 Node.js API + Web Standard API

能做什么

请求处理 & 代理

• 修改 Request / Response（改 Header、重写 URL）

• A/B 测试、灰度发布

• 鉴权拦截（JWT 验证、IP 白名单）

• 反向代理、请求路由

动态内容生成

• 服务端渲染（SSR）

• 动态 HTML 注入（HTMLRewriter）

• 生成 OG 图片、PDF、验证码

什么是 OG 图片

OG 图片是 Open Graph 图片，是网页在社交媒体分享时显示的预览缩略图。

API 服务

• REST / GraphQL API

• Webhook 处理

• 定时任务（Cron Triggers）

免费套餐

项目	免费额度
请求数	10 万次/天
CPU 时间	10ms / 请求
KV 读取	10 万次/天
D1 查询	500 万行读/天
R2 存储	10 GB

什么是 CPU 时间

要区分两个概念：

CPU 时间：Worker 代码真正占用 CPU 运算的时间；实际时间（Wall time）：请求从开始到结束的总耗时。

请求进来
├─ 执行 JS 逻辑 ← 计入 CPU 时间
├─ 等待 fetch() 响应 ← 不计入 CPU 时间
├─ 执行 JS 处理响应 ← 计入 CPU 时间
└─ 返回响应

所以即使你的 Worker 要等一个外部 API 响应 2 秒，这 2 秒的等待不算在 CPU 时间里，真正消耗的 CPU 时间往往只有几毫秒。

• 免费版 10ms 对绝大多数场景完全够用，比如请求转发、鉴权、路由、简单计算

• 超出限制会直接返回 CPU time limit exceeded 错误

• 需要超出 10ms 的场景：大量字符串处理、图片处理、复杂加密运算等，这时需要付费版的 30s 上限

Cloudflare Workers 和 AWS Lambda@Edge 的区别

• Workers：轻量、极速、生态完整，适合从零构建边缘应用

• Lambda@Edge：深度绑定 AWS，适合在现有 CloudFront 架构上做扩展，灵活性受限较多

维度	Cloudflare Workers	AWS Lambda@Edge
运行时	V8 Isolate	Node.js / Python / 容器
冷启动	< 5ms	100ms ~ 1s+
部署节点数	300+ 全球边缘节点	仅限 CloudFront 节点（约 13 个区域）
环境变量	✅ 支持	❌ 不支持
部署 Region	任意	必须 us-east-1
是否能独立使用	可独立部署任意	必须配合 CloudFront
触发方式	HTTP 请求、Cron、Queue、Durable Objects	仅限 CloudFront 的四个事件（Viewer Request/Response、Origin Request/Response）
CPU 时间上限	免费 10ms，付费 30s	Viewer 事件 1s，Origin 事件 30s
内存上限	128MB	128MB ~ 10GB（可配置）
包体积上限	1MB（免费）/ 10MB（付费）	1MB（Viewer）/ 50MB（Origin）
支持语言	JS / TS / Rust / C / C++（编译为 WASM）	Node.js / Python（Lambda@Edge 限制较多）
原生存储绑定	KV、D1、R2、Durable Objects、Queues、Vectorize	无原生绑定，需额外调用 AWS SDK 访问 S3、DynamoDB 等
免费额度	10 万次请求/天	100 万次请求/月（12 个月试用期后收费）
收费模式	按请求数 + CPU 时间计费，$5/月起	按请求数 + 执行时长计费，价格高于普通 Lambda
部署复杂度	低，wrangler CLI 一条命令部署	高，需配合 CloudFront、IAM 权限、Lambda 版本管理
调试 & 本地开发	Miniflare 本地模拟，体验接近生产环境	本地模拟较复杂，通常依赖 SAM CLI 或真实环境
适合场景	独立边缘应用、API、鉴权、SSR、全栈项目	已有 AWS 技术栈，需在 CloudFront 层做请求/响应改写
不适合场景	重计算任务、依赖完整 Node.js API 的项目	独立部署的边缘应用、对冷启动敏感的场景

AWS Lambda

AWS Lambda (opens new window) 是亚马逊提供的无服务器计算服务，让你只需上传代码，无需管理任何服务器，AWS 负责所有底层基础设施的运维和扩容。

它是按需运行的函数，事件来了就跑，跑完就停，无需关心服务器，是 AWS 无服务器架构的核心计算单元。

运行机制

事件触发  
  └─ Lambda 分配执行环境（容器）  
       └─ 加载运行时 + 你的代码  
            └─ 执行函数  
                 └─ 返回结果 → 容器保留一段时间（应对下次请求）  
                              → 长时间无请求则销毁（冷启动来源）

支持的运行时

语言	版本
Node.js	18.x / 20.x
Python	3.11 / 3.12
Java	11 / 17 / 21
Go	1.x
Ruby	3.2
.NET	6 / 8
自定义运行时	任意语言（通过 Runtime API）

触发方式（事件源）

Lambda 本身不主动运行，必须由事件触发：

触发源	场景
API Gateway / Function URL	HTTP 接口
S3	文件上传后处理
DynamoDB Streams	数据变更监听
SQS / SNS	消息队列消费
EventBridge	定时任务、事件总线
CloudFront（Lambda@Edge）	边缘请求处理
Cognito	用户认证钩子
直接调用（Invoke API）	服务间调用

关键配置参数

参数	范围	说明
内存	128MB ~ 10GB	同时决定 CPU 算力（内存越大 CPU 越强）
超时时间	1s ~ 15min	超时强制终止
并发数	默认 1000（可申请提升）	同时运行的实例上限
包大小	50MB（压缩）/ 250MB（解压）	超出需用 Lambda Layer 或容器镜像
临时存储	512MB ~ 10GB（/tmp 目录）	函数执行期间可用
Layer 数量	最多 5 个	所有 Layer 解压后与函数代码合计不超过 250MB

冷启动

这是 Lambda 最常被讨论的问题：

冷启动 = 容器初始化 + 运行时加载 + 代码初始化

• Node.js 冷启动：100ms ~ 500ms

• Java 冷启动：500ms ~ 3s+（最严重）

• Python 冷启动：100ms ~ 300ms

优化方案：

• Provisioned Concurrency (opens new window)：预热指定数量的实例，彻底消除冷启动，额外收费

• SnapStart (opens new window)（Java、Python、.NET）：快照预热实例，冷启动降低 90%

• 减小包体积：用 esbuild / tree-shaking 去掉无用依赖

• 把重操作放到 handler 外：比如建立数据库连接，利用容器复用来避免每次请求重复执行

定价模型

计费项	免费额度（每月）	超出后单价
请求次数	100 万次	$0.20 / 百万次
执行时长	40 万 GB·秒	$0.0000166667 / GB·秒

示例

函数内存 512MB，执行时间 200ms，调用 100 万次

计费时长 = 0.5GB × 0.2s × 100万 = 10万 GB·秒

费用 ≈ $1.67

适合 / 不适合的场景

适合：

• 流量波动大、需要弹性伸缩

• 事件驱动的异步任务（文件处理、消息消费）

• API 后端，尤其是低频或中频接口

• 定时任务（替代 Cron Job）

• 微服务架构中的单一职责函数

不适合：

• 长时间运行任务（超过 15 分钟）

• 对冷启动极度敏感的实时场景

• 需要持久化本地状态的应用

• 高频小任务（费用可能高于常驻服务器）

• WebSocket 长连接服务（需配合 API Gateway，架构复杂）

AWS Lambda@Edge

Lambda@Edge (opens new window) 是 AWS 在 CloudFront 边缘节点上运行 Lambda 函数的能力，让你在离用户最近的地方处理 HTTP 请求和响应，而不是把请求转发回中心化的服务器。

四个触发时机

这是 Lambda@Edge 最核心的概念，函数可以挂载在 CloudFront 请求生命周期的四个位置：

用户
 │
 ▼
[1] Viewer Request      ← 用户请求刚到达 CloudFront，还没查缓存
 │
 ▼
CloudFront 缓存检查
 │
 ▼
[2] Origin Request      ← 缓存未命中，即将转发给源站
 │
 ▼
源站（S3 / ALB / EC2）
 │
 ▼
[3] Origin Response     ← 源站返回响应，即将写入缓存
 │
 ▼
CloudFront 缓存写入
 │
 ▼
[4] Viewer Response     ← 即将返回给用户
 │
 ▼
用户

Viewer 事件  = 用户 ↔ CloudFront 之间的请求/响应
Origin 事件  = CloudFront ↔ 源站 之间的请求/响应

触发点	典型用途
Viewer Request	鉴权、URL 重写、AB 测试
Origin Request	修改转发给源站的请求、自定义缓存 key
Origin Response	修改响应头、错误页替换
Viewer Response	添加安全响应头、日志记录

限制参数

Lambda@Edge 不支持环境变量，配置只能硬编码或从外部服务（如 SSM Parameter Store）读取。

参数	Viewer 事件	Origin 事件
CPU 时间	1s	30s
内存	128MB	128MB ~ 10GB
包大小（压缩）	1MB	50MB
响应体大小	40KB	1MB
网络访问	✅	✅
环境变量	❌	❌

部署限制

• 函数必须部署在 us-east-1（北弗吉尼亚），CloudFront 会自动将其复制到全球边缘节点

• 只支持 Node.js 和 Python 运行时

• 不支持 Lambda URL、容器镜像部署

• 不能绑定 VPC

典型使用场景

1. 鉴权 & 访问控制

• JWT / Cookie 验证，拦截非法请求

• IP 白名单、地理封锁

2. URL 处理

• 路径重写（/old-path → /new-path）

• 多语言内容根据 Accept-Language 自动路由

• A/B 测试流量分配

3. 响应处理

• 统一注入安全响应头（CSP、HSTS）

• 动态修改 HTML 内容

• 替换源站返回的错误页

4. 性能优化

• 自定义缓存 Key（去掉无关查询参数）

• 图片格式协商（根据 Accept 返回 WebP 或 JPEG）

AWS WAF

AWS WAF (opens new window)（Web Application Firewall）是 AWS 提供的 Web 应用防火墙，用于过滤和监控进入你应用的 HTTP/HTTPS 流量，拦截恶意请求，保护应用安全。

核心原理

用户请求
  └─ 经过 WAF 检查
       ├─ 匹配到规则 → Allow / Block / Count / CAPTCHA
       └─ 未匹配规则 → 走默认动作（Allow 或 Block）
            └─ 转发到后端（CloudFront / ALB / API Gateway）

可以防御什么

1. OWASP Top10 (opens new window) 中的注入攻击

• SQL 注入（SQLi）—— 恶意数据注入 SQL 查询

• 跨站脚本（XSS）—— 恶意脚本注入 HTML 页面

• 命令注入 —— 恶意数据注入系统命令

• 路径遍历 —— 恶意路径注入文件系统访问

2. 应用层攻击

• HTTP Flood（七层 DDoS）

• 爬虫 / 恶意 Bot

• 凭证填充（Credential Stuffing）

• 账号枚举暴力破解

3. 业务层防护

• 限制特定 IP 的请求频率

• 封锁特定国家 / 地区的流量

• 拦截特定 User-Agent

核心概念

1. Web ACL

WAF 的顶层资源，包含一组有序规则，每条规则按顺序匹配，第一个命中的规则决定处理动作。

Web ACL
  ├─ 规则 1：封锁已知恶意 IP 列表         → Block
  ├─ 规则 2：允许来自办公室 IP 的请求      → Allow
  ├─ 规则 3：SQL 注入检测                → Block
  ├─ 规则 4：单 IP 每分钟超过 100 次请求   → Block
  └─ 默认动作                           → Allow

2. Rule（规则）

每条规则由两部分组成：

• 条件（Statement）：匹配什么（IP、Header、Body、URI 等）

• 动作（Action）：匹配后做什么

动作	说明
Allow	放行请求
Block	返回 403，拦截请求
Count	只计数，不拦截（用于测试规则）
CAPTCHA	返回验证码挑战
Challenge	静默 JS 挑战（验证是否真实浏览器）

3. Rule Group（规则组）

多条规则打包成一组，可复用到多个 Web ACL，分三种来源：

• AWS 托管规则：AWS 官方维护，开箱即用

• 第三方托管规则：来自 Marketplace，如 CrowdStrike、F5

• 自定义规则：自己编写

AWS 托管规则（免费附带）

规则组名	防御内容
AWSManagedRulesCommonRuleSet	OWASP Top 10 通用规则
AWSManagedRulesSQLiRuleSet	SQL 注入专项
AWSManagedRulesKnownBadInputsRuleSet	已知恶意输入模式
AWSManagedRulesBotControlRuleSet	Bot 识别与管理（额外收费）
AWSManagedRulesATPRuleSet	账号接管防护（额外收费）
AWSManagedRulesACFPRuleSet	账号欺诈防护（额外收费）

可部署在哪里

WAF 作为一层附加在以下服务前面：

CloudFront          ← 全球边缘防护
Application LB      ← 区域级防护
API Gateway         ← API 接口防护
AppSync             ← GraphQL 防护
Cognito User Pool   ← 登录接口防护
App Runner          ← 容器应用防护

速率限制（Rate Limiting）

WAF 内置请求频率限制，可以精细控制：

示例规则：
  条件：同一 IP，5 分钟内请求 /api/login 超过 20 次
  动作：Block，持续 5 分钟

可以按以下维度限速：

• IP 地址

• IP + URI 路径组合

• HTTP Header 中的某个值（如 User-Agent）

• 地理位置

日志 & 可观测性

• 所有请求日志可以投递到 S3 / CloudWatch Logs / Kinesis Firehose

• 日志包含：匹配规则、请求来源 IP、URI、Header、处理动作等

• 可配合 AWS Security Hub 做统一安全事件管理

• WAF Dashboard 提供实时流量图、Top IP、Top 规则命中等

定价模型

计费项	单价
Web ACL	$5 / 月
每条规则	$1 / 月
每 100 万次请求	$0.60
Bot Control（基础）	额外 $10 / 月 + $0.60 / 百万请求
Bot Control（高级）	额外 $30 / 月 + $1.50 / 百万请求

托管规则组本身不额外收费（Bot Control、ATP、ACFP 除外），但 Web ACL 和规则条数计费。

AWS WAF 和 AWS Shield 的关系

AWS 有两层 DDoS 防护，经常一起提：

	AWS WAF	AWS Shield
防护层	七层（应用层）	三四层（网络层）+ 七层
防御对象	SQL 注入、XSS、CC 攻击等	网络层 DDoS 洪水攻击
Shield Standard	不包含 WAF	免费，自动启用
Shield Advanced	需单独购买 WAF	$3000/月，包含 WAF 免费额度

实际生产环境通常组合使用：Shield 挡网络层洪水，WAF 挡应用层攻击。

AWS Shield

AWS Shield (opens new window) 是 AWS 提供的 DDoS 防护服务，专门抵御针对网络层和传输层的分布式拒绝服务攻击，保护运行在 AWS 上的应用不因流量洪泛而瘫痪。

Shield 的两个版本

1. Shield Standard（免费）

• 所有 AWS 用户自动启用，无需配置，无需付费

• 防御最常见的三、四层 DDoS 攻击

• 保护对象：CloudFront、Route 53、Global Accelerator

• 提供基础流量异常检测，自动缓解攻击

• 没有通知、没有报告、没有人工介入

2. Shield Advanced（付费）

• $3000 / 月，按年订阅（最少 1 年）

• 在 Standard 基础上全面增强，覆盖更多服务和更复杂的攻击

什么是 DDoS 攻击

DDoS（Distributed Denial of Service，分布式拒绝服务）攻击的目标只有一个：让你的服务无法正常响应合法用户的请求。

DDoS = 用海量流量或请求把你的服务淹死，让正常用户无法访问。攻击来自全球分布的肉鸡，靠封 IP 无法解决，需要专门的流量清洗和防护设备来应对。

"肉鸡" 是指被黑客入侵并控制的普通人的电脑、路由器、摄像头等设备，它们组成僵尸网络（Botnet），统一听从攻击者指挥。

可以防御什么

Shield 和 WAF 防护的层级不同：

七层（应用层）   HTTP Flood、CC 攻击、SQL 注入     ← WAF 负责
四层（传输层）   TCP SYN Flood、UDP Flood        ← Shield 负责
三层（网络层）   ICMP Flood、IP 碎片攻击          ← Shield 负责

攻击类型	原理	Shield 应对方式
SYN Flood	海量 TCP SYN 包耗尽服务器连接表	检测异常 SYN/ACK 比例，丢弃恶意包
UDP Flood	大量 UDP 包打满带宽	流量清洗，过滤异常 UDP 流量
ICMP Flood	大量 Ping 请求耗尽资源	速率限制，丢弃超额 ICMP 包
IP 碎片攻击	发送大量畸形 IP 分片包耗尽重组资源	检测异常分片特征，丢弃恶意分片
DNS 放大攻击	伪造源 IP 向 DNS 服务器发请求，让响应流量打向受害者	Route 53 层自动识别并缓解
NTP 放大攻击	利用 NTP 协议的响应放大效果淹没目标	流量清洗，过滤放大流量
Smurf 攻击	伪造 ICMP 广播包，让网络内所有设备回包给受害者	识别广播特征，过滤异常 ICMP

攻击类型	原理	Shield Advanced 应对方式
HTTP Flood（CC 攻击）	海量 HTTP 请求压垮应用服务器	配合 WAF 联动，自动生成拦截规则
SSL 滥用攻击	大量 SSL 握手请求耗尽服务器 CPU	在 CloudFront 层卸载 SSL，分散压力
慢速攻击（Slowloris）	保持大量半开连接不释放，耗尽连接池	检测异常连接保持时间，强制断开
大规模容量耗尽攻击	超大流量直接打满带宽	AWS 骨干网吸收，DRT 团队人工介入

适合开启 Shield Advanced 的场景

• 金融、电商、游戏等高价值目标，DDoS 风险高

• 有明确的业务连续性要求（SLA 严格）

• 已经遭受过 DDoS 攻击

• 希望有 AWS 专家团队兜底

AWS AppSync

AWS AppSync (opens new window) 是亚马逊云服务提供的一种全托管 GraphQL 服务，让开发者可以轻松构建可扩展的 API，实现应用与各种数据源的安全连接与实时数据同步。

核心概念

1. GraphQL API

AppSync 以 GraphQL 作为 API 层，客户端通过 Query（查询）、Mutation（变更）、Subscription（订阅）三种操作与数据交互，只获取所需字段，避免过度请求。

2. 数据源（Data Sources）

AppSync 支持多种后端数据源直连：

数据源	说明
Amazon DynamoDB	最常用，NoSQL 数据库
AWS Lambda	自定义逻辑，任意后端
Amazon RDS (Aurora Serverless)	关系型数据库
Amazon OpenSearch	搜索与分析
HTTP Endpoint	任意第三方 REST API
EventBridge	事件驱动架构集成
None	本地解析（纯前端逻辑）

3. Resolver（解析器）

Resolver 是连接 GraphQL 字段与数据源的桥梁，分为两种：

• VTL Resolver：使用 Apache Velocity 模板语言，性能高，无冷启动

• JavaScript Resolver（推荐）：使用 JS 编写，更易维护，AppSync Functions 支持复用

4. 实时订阅

基于 WebSocket，客户端可以订阅数据变更，AppSync 自动推送更新，无需自建 WebSocket 服务器。

5. 认证方式

认证方式	适用场景
Amazon Cognito User Pools	用户登录认证（最常见）
API Key	开发/测试，或公开 API
IAM	服务间调用、后端访问
Lambda Authorizer	自定义认证逻辑
OpenID Connect	第三方身份提供商

典型架构

客户端（Web/Mobile）
      │
      │ GraphQL (HTTPS / WebSocket)
      ▼
  AWS AppSync
      │
  ┌───┴────────────────────┐
  │                        │
DynamoDB              AWS Lambda
                           │
                      其他服务/DB

主要优势

• 无服务器：全托管，自动扩缩容，无需管理基础设施

• 实时能力：内置 WebSocket 订阅，开箱即用

• 离线支持：配合 AWS Amplify，支持客户端数据缓存与冲突解决

• 细粒度授权：字段级别的权限控制

• 多数据源合并：一个 GraphQL 请求可聚合多个数据源的结果

常见使用场景

• 聊天/协作应用 — 利用实时订阅推送消息

• 移动应用后端 — 灵活查询，减少流量消耗

• 数据聚合网关 — 统一多个微服务的数据接口

• IoT 数据推送 — 设备状态实时同步到前端

GraphQL

GraphQL (opens new window) 是由 Facebook（现 Meta）于 2012 年内部开发、2015 年开源的一种 API 查询语言，同时也是执行这些查询的运行时。它并非数据库查询语言，而是定义客户端与服务端如何通信的一套规范。

核心思想

传统 REST API 由服务端决定返回什么数据；GraphQL 则反过来，由客户端精确声明需要什么字段，服务端按需返回，不多不少。

三种操作类型

操作	关键字	作用	类比 REST
查询	query	读取数据	GET
变更	mutation	写入/修改/删除数据	POST / PUT / DELETE
订阅	subscription	实时监听数据变化	WebSocket

Schema —— GraphQL 的核心契约

Schema 是用 SDL（Schema Definition Language）描述的类型系统，是前后端之间的唯一契约。

Resolver —— 真正执行数据获取的地方

每个字段背后都有一个 Resolver 函数，负责从数据库/微服务/缓存取数据：

const resolvers = {
  Query: {
    user: (parent, { id }, context) => {
      return context.db.findUser(id);
    },
  },
  User: {
    posts: (user, args, context) => {
      return context.db.getPostsByUser(user.id);
    },
  },
};

N+1 问题与 DataLoader

GraphQL 的嵌套查询容易触发 N+1 数据库查询（查 1 个列表 + 每条记录再查 1 次关联数据）。标准解法是 DataLoader，将多次请求合并为一次批量查询：

const userLoader = new DataLoader(async (ids) => {
  return db.getUsersByIds(ids); // 一次查所有
});

GraphQL 和 REST 的区别

维度	GraphQL	REST
请求方式	单端点，按需取字段	多端点，固定返回结构
实时推送	原生支持 Subscription	需额外集成 WebSocket
数据聚合	单次请求多数据源	通常需多次请求
学习曲线	需了解 GraphQL	相对熟悉
适用场景	复杂数据关系、实时应用	简单 CRUD、公开 API

生态系统

类别	工具
服务端框架	Apollo Server、GraphQL Yoga、Pothos、Nexus
客户端	Apollo Client、urql、React Query + graphql-request
代码生成	GraphQL Code Generator
Schema 管理	Apollo Studio、GraphQL Inspector
云服务	AWS AppSync、Hasura、Fauna
IDE 工具	GraphiQL、Apollo Sandbox、Insomnia

适合/不适合 GraphQL 的场景

1. 适合：

• 前端多样（Web/iOS/Android），数据需求各不相同

• 数据关系复杂，需要嵌套查询

• 需要实时推送（聊天、通知、协作）

• 快速迭代，前端不想等后端改接口

2. 不适合：

• 简单的 CRUD，REST 足够

• 文件上传为主的场景

• 对 HTTP 缓存依赖很强的公开 API

学习资源

• 官方文档 (opens new window)

• GraphQL 学习路线图 (opens new window)

• How to GraphQL (opens new window)

• Hasura Learn (opens new window)

Amazon CloudWatch

Amazon CloudWatch (opens new window) 是 AWS 提供的全托管监控与可观测性服务，覆盖指标收集、日志管理、告警通知、仪表盘可视化以及自动化响应，是 AWS 生态中运维与 DevOps 的核心基础设施。

核心组成模块

CloudWatch 并非单一功能，而是一套完整的可观测性平台，由以下几个子系统构成：

1. Metrics（指标）

自动收集 AWS 服务产生的性能数据（如 EC2 的 CPU 使用率、Lambda 的调用次数），也支持推送自定义指标。

• 默认保留期：15 个月

• 分辨率：标准 1 分钟，高精度可达 1 秒

• 支持 Metric Math：对多个指标做数学运算，生成派生指标

2. Logs（日志）

集中收集、存储、检索来自各 AWS 服务或自定义应用的日志。核心概念如下：

概念	说明
Log Group	日志组，按应用/服务划分，设置保留策略
Log Stream	日志流，同一来源的连续日志序列
Log Event	单条日志记录（时间戳 + 消息体）
Insights	用 SQL-like 语法交互式查询日志
Live Tail	实时流式查看日志，类似 tail -f

3. Alarms（告警）

基于指标阈值或异常检测自动触发动作。

告警状态	含义
OK	指标在正常范围内
ALARM	指标超出阈值，触发动作
INSUFFICIENT_DATA	数据不足，无法判断

告警可触发的动作：发送 SNS 通知、执行 Auto Scaling、调用 Lambda、创建 OpsItem 等。

4. Dashboards（仪表盘）

跨 Region、跨账号的可视化监控面板，支持折线图、数值、告警状态、日志查询结果等多种组件，可共享给团队。

5. CloudWatch Logs Insights

用结构化查询语言分析海量日志：

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

6. CloudWatch Container Insights

专为容器化工作负载设计，自动采集 ECS、EKS、Kubernetes 的 CPU、内存、网络、磁盘指标，并提供预置仪表盘。

7. CloudWatch Application Signals

2024 年 GA，基于 OpenTelemetry 自动检测应用，提供服务级别的健康度视图（SLO/SLI），无需手动埋点。

数据采集方式

方式	适用场景
原生集成	EC2、Lambda、RDS 等 AWS 服务自动上报
CloudWatch Agent	安装在 EC2 / 本地服务器，采集系统指标和自定义日志
PutMetricData API	代码中推送自定义业务指标
Embedded Metric Format (EMF)	日志中嵌入结构化指标，自动提取为 Metric
AWS X-Ray 集成	分布式链路追踪数据关联到 CloudWatch
Kinesis Data Firehose	大规模日志流式传输到 CloudWatch

告警与通知架构

CloudWatch Metric
      │
      │ 超出阈值
      ▼
  CloudWatch Alarm
      │
  ┌───┴──────────────────────────┐
  │              │               │
Amazon SNS   Auto Scaling    AWS Lambda
  │
 ┌┴──────────────┐
Email / Slack / PagerDuty / SMS

可观测性三支柱

现代可观测性由三个支柱组成，CloudWatch 全部覆盖：

支柱	CloudWatch 对应功能	说明
Metrics（指标）	CloudWatch Metrics	数值型时序数据，反映系统状态
Logs（日志）	CloudWatch Logs	离散事件记录，用于排查问题
Traces（链路追踪）	AWS X-Ray + CloudWatch	请求在分布式系统中的完整路径

与其他 AWS 服务的集成

AWS 服务	集成方式
EC2	自动上报 CPU/网络/磁盘指标，Agent 采集内存和进程
Lambda	自动记录调用次数、错误率、执行时长、并发数
RDS / Aurora	数据库性能指标、慢查询日志
ECS / EKS	Container Insights 容器级指标
API Gateway	请求量、延迟、4xx/5xx 错误率
CloudTrail	审计日志可发送到 CloudWatch Logs
EventBridge	CloudWatch Alarm 状态变化触发事件
Systems Manager	OpsCenter 接收 CloudWatch 告警创建的 OpsItem

Amazon S3

Amazon S3 (opens new window)（Simple Storage Service）是 AWS 提供的对象存储服务，于 2006 年上线，是 AWS 最早也是最核心的服务之一。它提供近乎无限的存储容量、高达 99.999999999%（11个9）的数据持久性，广泛用于备份、静态网站托管、数据湖、CDN 源站等场景。

核心概念

1. Bucket（桶）

存储对象的顶级容器，名称全球唯一，创建时绑定 Region。一个账号最多 100 个 Bucket（可申请提高）。

2. Object（对象）

S3 存储的基本单元，由以下部分组成：

组成部分	说明
Key	对象的唯一标识符，即"路径"（如 images/logo.png）
Value	实际数据内容，最大 5 TB
Metadata	键值对形式的描述信息（系统元数据 + 用户自定义）
Version ID	开启版本控制后自动生成
ETag	对象内容的 MD5 哈希，用于完整性校验

3. 前缀与 "目录"

S3 本质上是扁平的键值存储，没有真正的目录结构。images/2024/logo.png 中的 / 只是 Key 的一部分，控制台会模拟成目录显示。

存储类型

存储类型	适用场景	可用性	最短存储期
S3 Standard	频繁访问的热数据	99.99%	无
S3 Intelligent-Tiering	访问模式不可预测	99.9%	无
S3 Standard-IA	不频繁访问，但需快速取回	99.9%	30 天
S3 One Zone-IA	不频繁访问，可接受单 AZ 风险	99.5%	30 天
S3 Glacier Instant Retrieval	归档，毫秒级取回	99.9%	90 天
S3 Glacier Flexible Retrieval	归档，分钟到小时级取回	99.99%	90 天
S3 Glacier Deep Archive	长期冷归档，12 小时内取回	99.99%	180 天

数据管理功能

1. 生命周期规则（Lifecycle Rules）

自动按时间将对象转换存储类型或删除，常见配置：

上传 → Standard
  ↓ 30天后
Standard-IA
  ↓ 90天后
Glacier Flexible Retrieval
  ↓ 365天后
永久删除

2. 版本控制（Versioning）

开启后每次上传同名对象会生成新版本，删除操作只添加 "删除标记" 而非真正删除，可随时恢复历史版本。

3. 复制（Replication）

• CRR（Cross-Region Replication）：跨区域复制，用于灾备、合规、就近访问

• SRR（Same-Region Replication）：同区域复制，用于日志聚合、测试环境同步

4. Object Lock

基于 WORM（Write Once Read Many）模型，防止对象被删除或覆盖，满足合规要求。

访问控制

机制	说明	推荐程度
Bucket Policy	JSON 格式的资源策略，控制谁能访问	⭐⭐⭐⭐⭐ 首选
IAM Policy	附加到用户/角色，控制能访问什么	⭐⭐⭐⭐⭐ 首选
ACL（访问控制列表）	对象/桶级别的传统权限，已不推荐	⭐⭐ 遗留用途
Block Public Access	桶/账号级别的公开访问开关，默认全部开启	必须了解
Presigned URL	临时授权 URL，可在有效期内让任何人访问私有对象	常用

数据加密

默认情况下，所有新对象会自动启用 SSE-S3 加密（2023 年起强制默认开启）。

加密方式	说明
SSE-S3	AWS 托管密钥，自动加密，零配置
SSE-KMS	使用 AWS KMS 密钥，支持审计和自定义密钥策略
SSE-C	客户自带密钥，AWS 不存储密钥
客户端加密	数据上传前在客户端加密，AWS 只存储密文

事件通知与集成

S3 支持在对象创建、删除、复制等事件发生时触发通知：

目标服务	典型用途
AWS Lambda	图片压缩、文件解析、ETL 触发
Amazon SQS	异步任务队列
Amazon SNS	告警通知
Amazon EventBridge	复杂事件路由，支持更多目标

性能特性

• 请求速率：每个前缀每秒支持 3,500 次 PUT/COPY/POST/DELETE 和 5,500 次 GET/HEAD

• 多部分上传（Multipart Upload）：文件 > 100 MB 推荐使用，支持并行上传、断点续传

• S3 Transfer Acceleration：通过 CloudFront 边缘节点加速跨地域上传

• 强一致性：2020 年起所有 GET/PUT/DELETE 操作均为强一致性（最终一致性已成历史）

静态网站托管

S3 可以直接托管静态网站，配置极简：

1. 开启 Bucket 的静态网站托管

2. 设置索引文档（index.html）和错误文档

3. 配置公开读取 Bucket Policy

4. 可选：绑定 CloudFront + Route 53 + ACM 实现自定义域名 + HTTPS

AWS ElastiCache

AWS ElastiCache (opens new window) 是 AWS 提供的全托管内存缓存服务，让开发者无需自行搭建和维护缓存基础设施，直接使用高性能的内存数据库来加速应用响应速度、降低后端数据库压力。

支持的缓存引擎

ElastiCache 目前支持两种主流缓存引擎：

维度	Redis	Memcached
定位	功能丰富的内存数据结构存储	简单高效的纯缓存
数据结构	String、Hash、List、Set、Sorted Set、Stream 等	仅 String
持久化	支持 RDB 快照 + AOF 日志	不支持
高可用	支持主从复制 + 自动故障转移	不支持复制
集群模式	支持分片集群（最多 500 个节点）	支持多节点水平扩展
发布/订阅	支持 Pub/Sub	不支持
事务	支持	不支持
Lua 脚本	支持	不支持
多线程	Redis 6+ 支持 I/O 多线程	原生多线程
适合场景	功能复杂、需持久化或高可用，比如缓存、会话管理、排行榜、消息队列、实时分析	简单缓存、极致性能、多线程扩展，纯粹的对象缓存，无需持久化或复杂数据结构

实际项目中 Redis 是绝大多数团队的首选，Memcached 只在极少数追求极简的场景下使用。

核心架构概念

1. 节点（Node）

ElastiCache 的基本计算单元，即一个运行缓存引擎的实例，有多种规格（从 cache.t4g.micro 到 cache.r7g.16xlarge）。

2. 集群（Cluster）

一组节点的集合。Redis 集群与 Memcached 集群结构不同：

• Redis 集群模式（Cluster Mode Enabled）：数据按 Key 哈希分布在多个 Shard，每个 Shard 有一个 Primary 和若干 Replica。

• Redis 非集群模式（单 Shard）：适合数据量不大但需要高可用的场景。

3. 副本组（Replication Group）

Redis 特有，包含一个 Primary 节点和最多 5 个 Read Replica，提供读写分离和自动故障转移（Multi-AZ）。

高可用与故障转移

功能	说明
Multi-AZ	Primary 和 Replica 分布在不同可用区，Primary 故障时自动提升 Replica
自动故障转移	Primary 不可用时，ElastiCache 自动将 Replica 提升为新 Primary，通常在 1 分钟内完成
读写分离	写操作走 Primary，读操作可分发到 Read Replica，提升读吞吐
Global Datastore	Redis 支持跨 Region 的全局复制，实现异地灾备和就近读取

数据持久化（Redis）

方式	说明	适用场景
RDB（快照）	定时将内存数据快照写入磁盘	可接受少量数据丢失的场景
AOF（追加日志）	每次写操作都追加到日志文件	数据可靠性要求高的场景
不持久化	纯内存，重启后数据丢失	纯缓存，数据可从数据库重建

安全机制

机制	说明
VPC 隔离	ElastiCache 部署在 VPC 内，不暴露公网
安全组	控制哪些 EC2/Lambda 可以访问缓存节点
传输加密（TLS）	客户端与节点之间的数据传输加密
静态加密	数据在磁盘上加密存储（持久化数据）
AUTH / RBAC	Redis 支持密码认证和基于角色的访问控制

ElastiCache Serverless

2023 年推出的新模式，与传统节点模式的区别：

维度	传统节点模式	Serverless 模式
容量规划	需预选节点规格	无需规划，自动扩缩
扩容方式	手动或定时扩容	秒级自动扩缩
计费方式	按节点小时数	按 ECU 和数据存储量
适用场景	流量稳定、成本可预测	流量波动大、不想管容量

Amazon Aurora

Amazon Aurora (opens new window) 是 AWS 自研的云原生关系型数据库，兼容 MySQL 和 PostgreSQL 协议，在保持与这两种数据库高度兼容的同时，在性能、可用性和扩展性上做了大幅提升。

核心特性

1. 性能

• 相比标准 MySQL 最高提升 5 倍性能

• 相比标准 PostgreSQL 最高提升 3 倍性能

• 底层存储与计算分离，I/O 路径经过深度优化

2. 持久性

• 数据自动跨 3 个可用区（AZ） 存储 6 份副本

• 可容忍 2 个副本故障仍能正常写入，3 个副本故障仍能正常读取

• 持久性达 99.999999999%（11 个 9）

3. 高可用

• 主节点故障后通常在 30 秒内完成自动故障转移

• 支持最多 15 个 Read Replica（MySQL RDS 只支持 5 个）

存储架构（与传统 RDS 的核心区别）

这是 Aurora 最与众不同的设计：

传统 RDS：
  计算层（数据库引擎）
       ↕ 完整数据页
  存储层（EBS 卷）

Aurora：
  计算层（数据库引擎）
       ↕ 只传 Redo Log（日志）
  分布式存储层（Aurora Storage）
  ↙    ↓    ↘    ↙    ↓   ↘
 AZ1  AZ1  AZ2  AZ2  AZ3  AZ3
（6 份副本，跨 3 个 AZ）

Aurora 的计算层只向存储层发送 Redo Log，而不是完整的数据页，大幅减少了网络 I/O，这是其性能提升的核心原因。

Aurora MySQL 和 Aurora PostgreSQL 的区别

维度	Aurora MySQL	Aurora PostgreSQL
兼容版本	MySQL 5.7 / 8.0	PostgreSQL 13 / 14 / 15 / 16
迁移难度	低，大多数应用无需改代码	低，语法高度兼容
适用场景	Web 应用、CMS、电商	复杂查询、GIS、金融系统
全文搜索	支持	支持（更强大）
JSON 支持	支持	支持（更原生）

Amazon RDS

Amazon RDS (opens new window)（Relational Database Service）是 AWS 提供的全托管关系型数据库服务，让你无需自己在 EC2 上安装、配置、维护数据库，AWS 负责底层的硬件、操作系统、数据库软件的安装与打补丁、备份、故障检测等运维工作。

支持的数据库引擎

引擎	说明
MySQL	最流行的开源关系型数据库
PostgreSQL	功能最强大的开源关系型数据库
MariaDB	MySQL 的社区分支，兼容性高
Oracle	企业级商业数据库，需自带许可或按小时付费
SQL Server	微软商业数据库，支持多个版本（Express/Standard/Enterprise）
Amazon Aurora	AWS 自研，属于同一家族，单独介绍

核心功能

1. Multi-AZ 部署（高可用）

RDS 的高可用方案，Primary 实例和 Standby 实例分布在不同可用区，数据同步复制。Primary 故障时自动切换到 Standby，通常在 1–2 分钟内完成。

        应用层
          │
          │（单一 DNS 端点，故障时自动切换）
          ▼
    Primary 实例 (AZ-A)
          │ 同步复制
          ▼
    Standby 实例 (AZ-B)
    （不对外提供读服务，纯备用）

Standby 实例不能用来分担读请求，仅作故障转移用。这是 RDS Multi-AZ 和 Aurora Read Replica 的重要区别。

2. Read Replica（读副本）

用于分担读压力，异步复制，最多支持 5 个 Read Replica，可跨 Region 部署。

        应用层
       ↙    ↘
   写请求    读请求
     ↓         ↓
   Primary   Read Replica × 5

3. 自动备份与 PITR

• 每天自动备份，保留 0–35 天

• 支持时间点恢复（PITR），可恢复到保留期内任意时间点

• 事务日志每 5 分钟上传一次到 S3

4. 参数组（Parameter Groups）

数据库引擎的配置文件，控制连接数、缓冲区大小、日志级别等参数，类似于 my.cnf / postgresql.conf。

5. 维护窗口

RDS 会在你指定的时间窗口内进行软件补丁、版本升级等维护操作，避免在业务高峰期影响服务。

RDS 和 Aurora 的核心区别

维度	RDS（MySQL/PostgreSQL 等）	Aurora
底层架构	标准开源数据库引擎 + EBS 存储	AWS 自研存储层，计算与存储分离
存储副本数	单 AZ 单份（Multi-AZ 才有跨 AZ 副本）	自动跨 3 个 AZ 存 6 份副本
存储上限	最高 64 TB	自动扩展，最高 128 TB
性能	原生引擎性能	MySQL 最高 5x，PostgreSQL 最高 3x
Read Replica 数量	最多 5 个	最多 15 个
故障转移时间	Multi-AZ 约 1–2 分钟	约 30 秒
Standby 可读	❌ Multi-AZ Standby 不可读	✅ 所有 Replica 均可读
Serverless	❌	✅（v2）
跨 Region 复制	需手动配置 Read Replica	原生 Global Database
回溯功能	❌	✅（Aurora MySQL）
克隆	❌	✅（写时复制，近乎即时）
价格	较低	略高（实例约贵 20%，存储也略贵）
引擎选择	MySQL / PostgreSQL / MariaDB / Oracle / SQL Server	仅 MySQL 兼容 / PostgreSQL 兼容
适用场景	预算有限、Oracle/SQL Server 迁移、简单业务	高可用要求高、流量大、需要 Serverless

如何选择

需要 Oracle 或 SQL Server？
  └─ 是 → RDS（Aurora 不支持这两种引擎）

只用 MySQL / PostgreSQL？
  ├─ 预算有限 / 流量小 / 简单业务 → RDS
  └─ 高可用要求高 / 流量大 / 需要 Serverless → Aurora

Amazon SQS

Amazon SQS (opens new window)（Simple Queue Service）是 AWS 提供的全托管消息队列服务，于 2006 年上线，是 AWS 最早的服务之一。它允许不同系统组件之间通过队列异步传递消息，实现解耦、削峰填谷和容错。

消息队列解决什么问题

没有队列时，服务之间直接调用：

用户下单 → 订单服务 → 直接调用库存服务
                 → 直接调用物流服务
                 → 直接调用通知服务

任何一个下游服务挂掉，整个链路就断了。

引入 SQS 后：

用户下单 → 订单服务 → SQS 队列 → 库存服务（独立消费）
                            → 物流服务（独立消费）
                            → 通知服务（独立消费）

订单服务只管把消息扔进队列，下游服务各自按节奏消费，互不影响。

两种队列类型

这是 SQS 最重要的基础概念：

维度	标准队列（Standard）	FIFO 队列
消息顺序	尽力而为，不保证严格顺序	严格先进先出（First-In-First-Out）
消息投递	至少一次（可能重复）	恰好一次（不会重复）
吞吐量	近乎无限	最高 3,000 条/秒（开启批处理）
去重	需消费者自行处理幂等	内置 5 分钟去重窗口
适用场景	高吞吐、对顺序和重复不敏感	金融交易、订单处理、严格顺序业务
价格	较低	略高

核心参数

理解这些参数是用好 SQS 的关键：

参数	说明	默认值	最大值
消息保留期	消息在队列中最长存活时间，超时自动删除	4 天	14 天
可见性超时	消息被取走后对其他消费者隐藏的时长，防止重复处理	30 秒	12 小时
消息大小	单条消息的最大体积	—	256 KB
延迟投递	消息发送后延迟多久才对消费者可见	0 秒	15 分钟
长轮询等待时间	消费者轮询时最长等待时间，减少空请求	0 秒（短轮询）	20 秒

死信队列

消息处理失败超过一定次数后，自动转移到死信队列（Dead Letter Queue，DLQ），避免 "毒消息" 反复阻塞主队列：

主队列
  │
  │ 消费失败，重试
  │ 达到最大接收次数（maxReceiveCount）
  ▼
死信队列（DLQ）← 人工排查 / 告警

DLQ 本身也是一个普通的 SQS 队列，Standard 队列的 DLQ 必须也是 Standard，FIFO 的 DLQ 必须也是 FIFO。

短轮询 vs 长轮询

消费者从 SQS 取消息有两种方式：

方式	行为	问题
短轮询（Short Polling）	立即返回，队列为空也返回空响应	大量空请求，浪费费用
长轮询（Long Polling）	队列为空时等待最多 20 秒再返回	减少空请求，降低费用，推荐

实际使用中应始终开启长轮询（WaitTimeSeconds 设为 20）。

与其他 AWS 服务的集成

集成服务	典型用途
AWS Lambda	Lambda 直接以 SQS 为触发器，自动拉取并处理消息（Event Source Mapping）
Amazon SNS	SNS 广播消息到多个 SQS 队列（Fan-out 模式）
Amazon S3	S3 事件通知发送到 SQS，触发后续处理
Amazon EC2 / ECS	消费者跑在 EC2/容器上，轮询 SQS 处理任务
AWS EventBridge	EventBridge 规则将事件路由到 SQS
Amazon CloudWatch	监控队列深度，深度过高时触发 Auto Scaling

Fan-out 模式（SNS + SQS 组合）

SQS 单独使用时，一条消息只能被一个消费者处理。如果需要同一条消息被多个服务处理，需要结合 SNS：

        生产者
           │
           ▼
       Amazon SNS
      ↙    ↓    ↘
  SQS-A  SQS-B  SQS-C
    │      │      │
  服务A   服务B   服务C

每个 SQS 队列独立消费同一条消息，互不影响，这是 AWS 上最经典的消息分发架构。

SQS 扩展消息（超过 256 KB）

单条消息限制 256 KB，如果消息体更大，有两种方案：

• S3 + SQS：把消息内容存到 S3，队列里只传 S3 对象的引用

• SQS Extended Client Library：AWS 官方提供的 Java/Python SDK 扩展，自动处理大消息的 S3 存储与引用

安全机制

机制	说明
IAM 策略	控制谁可以发送/接收/删除消息
队列访问策略（Resource Policy）	允许其他账号或 AWS 服务访问队列
传输加密	HTTPS 端点，传输层加密
静态加密（SSE）	使用 AWS KMS 或 SQS 托管密钥加密消息内容
VPC 端点	通过 PrivateLink 在 VPC 内部访问 SQS，不经公网

与同类服务对比

维度	Amazon SQS	Amazon SNS	Amazon EventBridge	Kafka（MSK）
类型	消息队列（点对点）	发布订阅（广播）	事件总线（路由）	流式消息平台
消息持久化	✅（最多 14 天）	❌（推送失败即丢）	❌	✅（可长期保留）
消费模式	拉取（Pull）	推送（Push）	推送（Push）	拉取（Pull）
消息回放	❌	❌	❌	✅
吞吐量	极高	极高	高	极高
适用场景	异步任务、削峰填谷	通知广播、Fan-out	服务间事件路由	日志流、实时数据管道

Amazon ECS

Amazon ECS (opens new window)（Elastic Container Service）是 AWS 提供的全托管容器编排服务，让你可以在 AWS 上运行、管理和扩展 Docker 容器，无需自己搭建和维护 Kubernetes 或其他编排系统。

核心概念

ECS 有一套自己的概念体系，理清这些是理解 ECS 的基础：

Cluster（集群）
  └── Service（服务）
        └── Task（任务）
              └── Container（容器）× N

概念	类比	说明
Cluster	机房	ECS 的顶层资源边界，一个或多个服务跑在同一个集群内
Task Definition	配方 / Dockerfile	描述容器如何运行的模板：镜像、CPU/内存、环境变量、端口映射等
Task	一次运行实例	Task Definition 的一次具体运行，包含一个或多个容器
Service	进程守护	确保指定数量的 Task 持续运行，负责滚动更新、故障重启、负载均衡注册
Container	容器	实际运行的 Docker 容器，一个 Task 可包含多个 Container

两种启动类型

这是 ECS 最重要的选择，决定你的容器跑在什么基础设施上：

维度	Fargate（推荐）	EC2
基础设施	AWS 全托管，无需管理服务器	你管理 EC2 实例
容量规划	无需规划，按 Task 分配 CPU/内存	需要规划实例数量和类型
扩缩容	按 Task 数量扩缩	需同时扩缩 EC2 和 Task
运维成本	极低	需维护 EC2 系统补丁、ECS Agent 等
计费方式	按 Task 实际使用的 vCPU 和内存	按 EC2 实例小时数
成本	略高	可通过 Reserved/Spot 节省更多
适用场景	大多数场景，快速上手	需要 GPU、特定实例类型、极致成本优化
容器密度	AWS 控制	可在单机上运行更多容器，提升资源利用率

实际项目中 Fargate 是绝大多数团队的首选，EC2 启动类型主要用于有特殊硬件需求或极致成本优化的场景。

Task Definition

Task Definition 是 ECS 的核心配置文件，类似 docker-compose.yml，主要定义：

{
  "family": "my-web-app",
  "cpu": "512",
  "memory": "1024",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "nginx:latest",
      "portMappings": [{ "containerPort": 80 }],
      "environment": [
        { "name": "ENV", "value": "production" }
      ],
      "secrets": [
        { "name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:..." }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": { "awslogs-group": "/ecs/my-app" }
      }
    }
  ]
}

Task Definition 是版本化的，每次修改都会生成新的版本号（revision），旧版本继续存在，方便回滚。

Service 的核心能力

1. 滚动更新（Rolling Update）

更新 Task Definition 版本时，ECS Service 自动按比例逐步替换旧 Task，保证服务不中断。

2. 自动扩缩容（Auto Scaling）

基于 CloudWatch 指标（CPU 使用率、内存、请求数等）自动调整 Task 数量。

3. 负载均衡集成

Service 可自动将 Task 注册到 ALB/NLB 目标组，Task 启动时自动注册，停止时自动注销。

网络模式

模式	说明	适用场景
awsvpc（推荐）	每个 Task 分配独立 ENI 和私有 IP，与 EC2 实例完全隔离	Fargate 必须使用；EC2 推荐
bridge	Docker 默认网桥网络，通过端口映射暴露服务	EC2 启动类型，旧应用迁移
host	容器直接使用宿主机网络，无端口映射	极致网络性能场景
none	无网络，容器完全隔离	离线批处理任务

日志与监控

功能	说明
awslogs 日志驱动	容器标准输出自动发送到 CloudWatch Logs
Container Insights	自动采集 Task/容器级别的 CPU、内存、网络指标，提供预置仪表盘
AWS X-Ray	在容器内集成 X-Ray SDK，实现分布式链路追踪
ECS Exec	直接进入运行中的容器内部排查问题（类似 kubectl exec）

安全机制

机制	说明
Task IAM Role	每个 Task 分配独立 IAM Role，容器内代码以该角色身份调用 AWS API，无需硬编码密钥
Task Execution Role	ECS Agent 用来拉取镜像、写日志、读取 Secrets 的角色
Secrets Manager / SSM 集成	敏感配置从 Secrets Manager 或 Parameter Store 注入容器，不写死在环境变量里
VPC 安全组	awsvpc 模式下，每个 Task 可绑定独立安全组，精细控制网络访问
ECR 镜像扫描	配合 Amazon ECR 对容器镜像做漏洞扫描

与 EKS 的对比

ECS 和 EKS（托管 Kubernetes）是 AWS 上最常见的容器编排选择：

维度	Amazon ECS	Amazon EKS
编排系统	AWS 自研	Kubernetes（标准）
学习成本	低，概念简单	高，需要了解 K8s 生态
运维复杂度	低	中（托管 Control Plane，但 Worker Node 仍需管理）
生态系统	AWS 原生	开源 K8s 生态，可移植
跨云迁移	困难（AWS 专有）	容易（K8s 标准）
Fargate 支持	✅	✅（但配置更复杂）
适用场景	AWS 原生应用，团队 K8s 经验少	已有 K8s 经验，需要跨云，复杂编排需求
价格	仅计算资源费用	额外收取 Control Plane 费用（约 $0.10/小时）

没有特别理由优先选 ECS，上手更快，AWS 原生集成更顺畅。如果团队已有 K8s 经验或有跨云需求，选 EKS。