云架构设计

9 minAdvanced2026/6/14

云架构设计原则、微服务架构、事件驱动架构、无服务器架构、多区域高可用、灾备策略与架构评审。

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 设计权衡

架构设计本质是权衡，常见决策点：

\text{CAP} \Rightarrow \text{一致性 vs 可用性 vs 分区容错}

\text{延迟 vs 一致性} \Rightarrow \text{强一致（同步复制） vs 最终一致（异步复制）}

\text{成本 vs 可靠性} \Rightarrow \text{单区域 vs 多区域}

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" }

当前状态通过重放事件获得：

\text{State}_{current} = \text{Apply}(\text{Event}_1, \text{Event}_2, \ldots, \text{Event}_n)

为避免每次全量重放，使用快照（Snapshot）：

\text{State}_{current} = \text{Apply}(\text{Snapshot}_k, \text{Event}_{k+1}, \ldots, \text{Event}_n)

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 成本模型

\text{月成本} = \text{请求数} \times \text{单价/百万请求} + \sum_{i} (\text{执行时间}_i \times \text{内存}_i \times \text{单价/GB·s})

与传统方案的成本交叉点：

\text{当 } \frac{\text{请求量} \times \text{平均执行时间}}{\text{时间窗口}} < \text{服务器利用率阈值} \text{ 时，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（恢复时间目标）	可容忍的最大服务中断时间	秒级 - 数小时

\text{可用性} = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}} = 1 - \frac{\text{MTTR}}{\text{MTBF} + \text{MTTR}}

其中 MTBF 为平均故障间隔时间，MTTR 为平均恢复时间。

5.3 灾备策略

策略	RPO	RTO	成本	实现方式
备份与恢复	小时级	小时级	低	定期备份到对象存储
预置备用	分钟级	分钟级	中	备用区域保持最小容量
温备用	秒级	分钟级	中高	备用区域持续运行但流量低
多活	接近零	接近零	高	多区域同时服务

6. 架构评审

6.1 架构决策记录（ADR）

每个重要架构决策应记录：

ADR-001: 选择事件驱动架构处理订单流程

状态: 已接受

背景:
  订单系统需要与支付、库存、物流等多个系统交互，
  同步调用导致级联故障风险和响应延迟增加。

决策:
  采用事件驱动架构，订单服务发布领域事件，
  下游服务异步订阅处理。

后果:
  正面: 松耦合、弹性提升、可独立扩展
  负面: 最终一致性、调试复杂度增加、需要事件排序机制

6.2 架构评审检查清单

可靠性：

单点故障是否消除
是否有自动故障转移机制
是否有重试与熔断策略
是否有混沌工程验证

安全性：

数据是否加密（传输中 + 静态）
身份认证与授权是否完备
是否有网络分段与隔离
是否有安全扫描与审计

可扩展性：

是否支持水平扩展
是否有自动伸缩策略
是否有缓存策略
数据库是否有分片方案

可观测性：

是否有指标监控
是否有分布式追踪
是否有结构化日志
是否有告警与 Runbook