云架构设计
00:00
云架构设计原则、微服务架构、事件驱动架构、无服务器架构、多区域高可用、灾备策略与架构评审。
1. 云架构设计原则
1.1 Well-Architected Framework
AWS Well-Architected Framework 定义了六大支柱：
| 支柱 | 核心关注 | 关键实践 |
|---|---|---|
| 卓越运营 | 运维自动化、事件响应 | IaC、可观测性、Runbook |
| 安全性 | 数据保护、身份认证 | 最小权限、加密、审计 |
| 可靠性 | 故障恢复、弹性伸缩 | 多 AZ、自动恢复、混沌工程 |
| 性能效率 | 资源选型、高效利用 | 按需选型、缓存、压缩 |
| 成本优化 | 消除浪费、合理定价 | Reserved Instance、Right-sizing |
| 可持续性 | 资源效率、碳足迹 | Graviton、Spot、弹性调度 |
1.2 云原生设计原则
- 不可变基础设施：服务器不手动修改，通过替换实现变更
- 声明式 API：描述期望状态，系统自动收敛
- 自服务：开发团队自助获取资源，无需审批瓶颈
- 松耦合：服务间通过 API 通信，独立部署与扩展
- 可观测：指标、日志、链路追踪三位一体
1.3 设计权衡
架构设计本质是权衡，常见决策点：
2. 微服务架构
2.1 微服务拆分策略
领域驱动设计（DDD） 是微服务拆分的核心方法论：
┌─────────────────────────────────────────────────┐
│ 限界上下文（Bounded Context） │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ 订单上下文 │ │ 支付上下文 │ │ 库存上下文 │ │
│ │ │ │ │ │ │ │
│ │ Aggregate │ │ Aggregate │ │ Aggregate │ │
│ │ Order │ │ Payment │ │ Stock │ │
│ └───────────┘ └───────────┘ └───────────┘ │
└─────────────────────────────────────────────────┘拆分原则：
- 单一职责：每个服务聚焦一个业务能力
- 独立部署：服务可独立发布，不影响其他服务
- 数据自治：每个服务拥有自己的数据存储
- 接口契约：服务间通过明确定义的 API 交互
2.2 服务通信模式
同步通信：
| 协议 | 适用场景 | 特点 |
|---|---|---|
| REST/HTTP | CRUD 操作 | 简单通用，但开销大 |
| gRPC | 服务间高频调用 | 高性能，强类型，流式 |
| GraphQL | 前端聚合查询 | 按需获取，减少过度获取 |
异步通信：
| 模式 | 适用场景 | 代表技术 |
|---|---|---|
| 点对点 | 任务分发 | RabbitMQ、SQS |
| 发布/订阅 | 事件通知 | Kafka、SNS |
| 事件溯源 | 审计追踪 | EventStoreDB |
2.3 服务网格（Service Mesh）
服务网格将通信逻辑从应用代码中抽离到基础设施层：
┌──────────────────────────────────────────┐
│ Service Mesh │
│ │
│ ┌─────────┐ ┌─────────┐ │
│ │ Service A│ │Service B│ │
│ │ ┌─────┐│ │┌─────┐ │ │
│ │ │Sidecar│◄───►│Sidecar│ │ │
│ │ └─────┘│ │└─────┘ │ │
│ └─────────┘ └─────────┘ │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ Control Plane │ │
│ │ (Pilot / Citadel / Galley) │ │
│ └─────────────────────────────────────┘ │
└──────────────────────────────────────────┘核心能力：流量管理、安全通信（mTLS）、可观测性、故障注入。
3. 事件驱动架构
3.1 事件驱动核心概念
事件生产者 ──(事件)──> 事件路由器 ──(事件)──> 事件消费者
│
┌─────┴─────┐
│ 事件存储 │ ← 可选，用于事件回放
└───────────┘事件 vs 命令 vs 查询：
| 类型 | 意图 | 响应期望 | 示例 |
|---|---|---|---|
| 命令 | 请求执行操作 | 期望成功/失败 | CreateOrder |
| 事件 | 通知已发生事实 | 无期望 | OrderCreated |
| 查询 | 请求信息 | 期望返回数据 | GetOrderStatus |
3.2 事件溯源（Event Sourcing）
不存储当前状态，而是存储所有状态变更事件：
传统方式： Order { id: 1, status: "shipped", total: 99.9 }
事件溯源： OrderCreated { id: 1, items: [...], total: 99.9 }
OrderPaid { id: 1, paymentId: "pay_123" }
OrderShipped { id: 1, trackingNo: "SF123456" }当前状态通过重放事件获得：
为避免每次全量重放，使用快照（Snapshot）：
3.3 CQRS 模式
命令查询职责分离（Command Query Responsibility Segregation）：
┌──────────────┐ Command ┌──────────────┐
│ Write Side │ ──────────────> │ Command Model│
│ (API) │ │ (OLTP) │
└──────────────┘ └──────┬───────┘
│ Event
▼
┌──────────────┐ Query ┌──────────────┐
│ Read Side │ <────────────── │ Query Model │
│ (API) │ │ (OLAP) │
└──────────────┘ └──────────────┘优势：读写模型独立优化，读侧可水平扩展；代价：最终一致性、复杂度增加。
4. 无服务器架构
4.1 Serverless 核心理念
Serverless 不是没有服务器，而是无需管理服务器：
- FaaS（Function as a Service）：按请求执行代码
- BaaS（Backend as a Service）：托管后端服务（数据库、认证、存储）
4.2 FaaS 执行模型
请求到达 → 冷启动 → 初始化运行时 → 执行函数 → 返回结果 → 实例保活 → 超时回收
↑ │
└──────── 下次请求（若实例已回收）──────────┘冷启动时间参考：
| 运行时 | 冷启动时间 | 备注 |
|---|---|---|
| Node.js | 100-300ms | 较快 |
| Python | 200-500ms | 中等 |
| Java | 1-3s | JVM 启动开销 |
| Go | 50-200ms | 编译型，启动快 |
| Rust | 50-150ms | 编译型，启动快 |
| .NET | 500ms-2s | CLR 初始化 |
4.3 Serverless 适用场景
适合：
- 事件驱动型工作负载（Webhook、定时任务）
- 流量波动大的 API
- 数据处理管道（ETL）
- 实时文件处理（图片/视频转码）
不适合：
- 长时间运行任务（>15min）
- 低延迟要求（冷启动不可控）
- 需要持久连接（WebSocket、gRPC 流）
- 高频小请求（调用费用累积）
4.4 Serverless 成本模型
与传统方案的成本交叉点：
5. 多区域高可用架构
5.1 高可用层级
┌─────────────────────────────────────────────────────┐
│ 全球负载均衡 (DNS/CDN) │
├──────────────────────┬──────────────────────────────┤
│ 区域 A │ 区域 B │
│ ┌────────────────┐ │ ┌────────────────┐ │
│ │ ALB (多 AZ) │ │ │ ALB (多 AZ) │ │
│ ├────┬────┬──────┤ │ ├────┬────┬──────┤ │
│ │AZ1 │AZ2 │AZ3 │ │ │AZ1 │AZ2 │AZ3 │ │
│ │ │ │ │ │ │ │ │ │ │
│ └────┴────┴──────┘ │ └────┴────┴──────┘ │
│ 数据库主 │ 数据库从 │
└──────────────────────┴──────────────────────────────┘5.2 RPO 与 RTO
| 指标 | 含义 | 典型值 |
|---|---|---|
| RPO（恢复点目标） | 可容忍的最大数据丢失量 | 0（同步复制）- 数小时 |
| RTO（恢复时间目标） | 可容忍的最大服务中断时间 | 秒级 - 数小时 |
其中 MTBF 为平均故障间隔时间，MTTR 为平均恢复时间。
5.3 灾备策略
| 策略 | RPO | RTO | 成本 | 实现方式 |
|---|---|---|---|---|
| 备份与恢复 | 小时级 | 小时级 | 低 | 定期备份到对象存储 |
| 预置备用 | 分钟级 | 分钟级 | 中 | 备用区域保持最小容量 |
| 温备用 | 秒级 | 分钟级 | 中高 | 备用区域持续运行但流量低 |
| 多活 | 接近零 | 接近零 | 高 | 多区域同时服务 |
6. 架构评审
6.1 架构决策记录（ADR）
每个重要架构决策应记录：
ADR-001: 选择事件驱动架构处理订单流程
状态: 已接受
背景:
订单系统需要与支付、库存、物流等多个系统交互，
同步调用导致级联故障风险和响应延迟增加。
决策:
采用事件驱动架构，订单服务发布领域事件，
下游服务异步订阅处理。
后果:
正面: 松耦合、弹性提升、可独立扩展
负面: 最终一致性、调试复杂度增加、需要事件排序机制6.2 架构评审检查清单
可靠性：
- 单点故障是否消除
- 是否有自动故障转移机制
- 是否有重试与熔断策略
- 是否有混沌工程验证
安全性：
- 数据是否加密（传输中 + 静态）
- 身份认证与授权是否完备
- 是否有网络分段与隔离
- 是否有安全扫描与审计
可扩展性：
- 是否支持水平扩展
- 是否有自动伸缩策略
- 是否有缓存策略
- 数据库是否有分片方案
可观测性：
- 是否有指标监控
- 是否有分布式追踪
- 是否有结构化日志
- 是否有告警与 Runbook