云架构设计

6 min高级2026/9/12

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

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） 是微服务拆分的核心方法论：

flowchart LR
    subgraph BC[限界上下文 Bounded Context]
        O[订单上下文<br/>Aggregate Order]
        P[支付上下文<br/>Aggregate Payment]
        S[库存上下文<br/>Aggregate Stock]
    end

拆分原则：

单一职责：每个服务聚焦一个业务能力
独立部署：服务可独立发布，不影响其他服务
数据自治：每个服务拥有自己的数据存储
接口契约：服务间通过明确定义的 API 交互

2.2 服务通信模式

同步通信：

协议	适用场景	特点
REST/HTTP	CRUD 操作	简单通用，但开销大
gRPC	服务间高频调用	高性能，强类型，流式
GraphQL	前端聚合查询	按需获取，减少过度获取

异步通信：

模式	适用场景	代表技术
点对点	任务分发	RabbitMQ、SQS
发布/订阅	事件通知	Kafka、SNS
事件溯源	审计追踪	EventStoreDB

2.3 服务网格（Service Mesh）

服务网格将通信逻辑从应用代码中抽离到基础设施层：

flowchart LR
    subgraph Mesh[Service Mesh]
        A[Service A<br/>Sidecar] <--> B[Service B<br/>Sidecar]
        CP[Control Plane<br/>Pilot / Citadel / Galley]
    end

核心能力：流量管理、安全通信（mTLS）、可观测性、故障注入。

3. 事件驱动架构

3.1 事件驱动核心概念

flowchart LR
    Prod[事件生产者] -->|事件| Router[事件路由器] -->|事件| Cons[事件消费者]
    Router --> Store[事件存储<br/>可选，用于事件回放]

事件 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）：

flowchart LR
    W[Write Side API] -->|Command| CM[Command Model OLTP] -->|Event| QM[Query Model OLAP]
    R[Read Side API] <-->|Query| QM

优势：读写模型独立优化，读侧可水平扩展；代价：最终一致性、复杂度增加。

4. 无服务器架构

4.1 Serverless 核心理念

Serverless 不是没有服务器，而是无需管理服务器：

FaaS（Function as a Service）：按请求执行代码
BaaS（Backend as a Service）：托管后端服务（数据库、认证、存储）

4.2 FaaS 执行模型

flowchart LR
    A[请求到达] --> B[冷启动] --> C[初始化运行时] --> D[执行函数] --> E[返回结果] --> F[实例保活] --> G[超时回收]
    G -.->|下次请求，若实例已回收| B

冷启动时间参考：

运行时	冷启动时间	备注
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 高可用层级

flowchart TD
    GLB[全球负载均衡 DNS/CDN]
    subgraph RA[区域 A]
        ALB1[ALB 多 AZ]
        AZ1[AZ1] AZ2[AZ2] AZ3[AZ3]
        DB1[数据库主]
    end
    subgraph RB[区域 B]
        ALB2[ALB 多 AZ]
        BZ1[AZ1] BZ2[AZ2] BZ3[AZ3]
        DB2[数据库从]
    end
    GLB --> ALB1
    GLB --> ALB2

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

小结

初学者要点：架构设计的起点是 Well-Architected 六支柱的权衡，不是技术选型；微服务拆分跟着业务边界（限界上下文）走，而不是跟着团队人数或技术潮流走；灾备先定 RPO/RTO 再选策略，预算决定形态。
进阶注意：Serverless 的冷启动与常驻成本模型要用真实流量回放验证；多区域架构从「备份恢复 → 预置备用 → 温备 → 多活」逐级演进，直接上多活是最常见的过度设计；重要决策沉淀为 ADR，半年后没人记得”当时为什么这么选”。

云架构设计

1. 云架构设计原则#

1.1 Well-Architected Framework#

1.2 云原生设计原则#

1.3 设计权衡#

2. 微服务架构#

2.1 微服务拆分策略#

2.2 服务通信模式#

2.3 服务网格（Service Mesh）#

3. 事件驱动架构#

3.1 事件驱动核心概念#

3.2 事件溯源（Event Sourcing）#

3.3 CQRS 模式#

4. 无服务器架构#

4.1 Serverless 核心理念#

4.2 FaaS 执行模型#

4.3 Serverless 适用场景#

4.4 Serverless 成本模型#

5. 多区域高可用架构#

5.1 高可用层级#

5.2 RPO 与 RTO#

5.3 灾备策略#

6. 架构评审#

6.1 架构决策记录（ADR）#

6.2 架构评审检查清单#

小结#