微服务架构
1. 微服务概述#
1.1 什么是微服务#
微服务是一种将应用拆分为一组小型、独立部署的服务的架构风格。
1.2 与单体架构对比#
| 对比项 | 单体架构 | 微服务架构 |
|---|
| 部署 | 整体部署 | 独立部署 |
| 技术栈 | 统一 | 异构 |
| 扩展 | 整体扩展 | 按需扩展 |
| 故障 | 全局影响 | 局部影响 |
| 团队 | 集中 | 分散 |
| 复杂度 | 代码复杂 | 运维复杂 |
1.3 何时使用微服务#
| 场景 | 推荐 |
|---|
| 小团队/初创 | 单体 |
| 大型复杂系统 | 微服务 |
| 快速验证 | 单体 |
| 高并发/多团队 | 微服务 |
2. 服务拆分策略#
2.1 拆分原则#
| 原则 | 描述 |
|---|
| 单一职责 | 每个服务一个业务能力 |
| 高内聚 | 相关功能放在一起 |
| 松耦合 | 服务间依赖最小化 |
| 独立部署 | 可独立发布 |
| 数据自治 | 每个服务有自己的数据库 |
2.2 拆分方法#
| 方法 | 描述 |
|---|
| 按业务能力 | 围绕业务功能拆分 |
| 按子域 | DDD 限界上下文 |
| 按用例 | 围绕用户场景 |
| 按数据 | 围绕数据所有权 |
2.3 DDD 限界上下文#
flowchart TD
subgraph O[订单上下文]
OS[OrderService] OD[OrderDB]
end
subgraph I[库存上下文]
IS[InventorySvc] ID[InventoryDB]
end
subgraph P[支付上下文]
PS[PaymentService] PD[PaymentDB]
end
3. 服务通信#
3.1 同步通信#
| 方式 | 协议 | 特点 |
|---|
| REST | HTTP/JSON | 简单、通用 |
| gRPC | HTTP2/Protobuf | 高性能、强类型 |
| GraphQL | HTTP/JSON | 灵活查询 |
3.2 异步通信#
| 方式 | 协议 | 特点 |
|---|
| 消息队列 | AMQP | 解耦、削峰 |
| 事件驱动 | Kafka | 高吞吐、持久化 |
| 事件总线 | Redis Streams | 轻量级 |
3.3 通信模式#
| 模式 | 描述 | 适用场景 |
|---|
| 请求-响应 | 同步调用 | 查询类 |
| 事件通知 | 异步通知 | 状态变更 |
| 事件溯源 | 存储所有事件 | 审计、回放 |
| CQRS | 读写分离 | 复杂查询 |
3.4 Saga 模式#
跨服务分布式事务的主流解法：把事务拆成一系列本地事务，每步都有对应
的补偿操作，失败时反向补偿（而不是回滚数据库）。
编舞式（Choreography，无中心）：服务通过事件互相触发，谁也不指挥谁：
OrderService → 事件 OrderCreated → InventoryService 预留库存
→ 事件 InventoryReserved → PaymentService 扣款
↓ 任一步失败
发布补偿事件：CancelOrder ← RefundPayment
编排式（Orchestration，有中心）：由协调器（或订单服务自身）顺序
调用各参与方，失败时由协调器执行补偿命令：
Saga 协调器 → 调用 ReserveInventory → 调用 ProcessPayment
↓ 失败
协调器 → RefundPayment → CancelOrder
| 形态 | 优点 | 缺点 |
|---|
| 编舞式 | 松耦合、无单点 | 流程散落在事件里，难追踪全局 |
| 编排式 | 流程集中可见、易加步骤 | 协调器可能成为瓶颈/单点 |
简单流程（2-3 步）用编舞式，复杂长流程（步骤多、需监控）用编排式。
4. 数据管理#
4.1 数据库每服务一个#
每个服务独占自己的数据库
服务间禁止直接访问对方的数据库（只能走 API 或事件）
跨服务查询通过 API 组合或数据复制实现
这条是微服务数据架构的红线：一旦 A 服务直连 B 服务的库，B 的 schema
变更就会破坏 A，两个服务事实上被焊死——「独立部署」从此名存实亡。
4.2 数据一致性#
| 策略 | 描述 |
|---|
| 强一致性 | 2PC（不推荐） |
| 最终一致性 | Saga + 事件 |
| 补偿事务 | 失败时回滚 |
4.3 API 组合#
API Gateway → 聚合多个服务的数据 → 返回给客户端
GET /order-details/123
→ OrderService: 订单信息
→ InventoryService: 库存状态
→ PaymentService: 支付状态
→ 组合返回
5. 服务治理#
5.1 服务发现#
| 方式 | 描述 |
|---|
| 客户端发现 | 客户端查询注册中心 |
| 服务端发现 | 负载均衡器查询注册中心 |
5.2 负载均衡#
| 策略 | 描述 |
|---|
| 轮询 | 依次分配 |
| 随机 | 随机分配 |
| 加权 | 按权重分配 |
| 最少连接 | 分配给连接最少的 |
5.3 熔断器#
// 熔断器状态机
CLOSED → (错误率超阈值) → OPEN
OPEN → (超时后) → HALF_OPEN
HALF_OPEN → (探测成功) → CLOSED
HALF_OPEN → (探测失败) → OPEN
5.4 限流#
| 算法 | 描述 |
|---|
| 固定窗口 | 固定时间窗口计数 |
| 滑动窗口 | 平滑计数 |
| 令牌桶 | 匀速生成令牌 |
| 漏桶 | 匀速消费请求 |
6. 微服务最佳实践#
| 实践 | 描述 |
|---|
| API 版本化 | /api/v1/resource |
| 幂等设计 | 重复请求结果一致 |
| 健康检查 | /health 端点 |
| 优雅降级 | 依赖失败时的备选方案 |
| 配置外部化 | 环境变量/配置中心 |
| 可观测性 | 日志+指标+追踪 |
| 契约测试 | 消费者驱动契约 |
| CI/CD | 每个服务独立流水线 |
- 初学者要点：微服务的本质代价是「代码复杂度换运维复杂度」，小团队与
快速验证场景先单体；拆分按业务能力/DDD 限界上下文，不做技术分层拆分；
数据库每服务一个、禁止跨库直连；跨服务事务用 Saga 而不是 2PC。
- 进阶注意：同步调用链会把延迟与故障串联，优先考虑事件驱动；通信只允许
走 API/事件这条「红线」决定了架构能否长期演进；可观测性（追踪 + 拓扑）
是微服务排错的生命线（见
170-Observability）；服务网格与 API 网关
的治理能力扩展见 160-ServiceMesh；从单体演进微服务时，「先按限界
上下文拆模块（逻辑拆分），再按需拆部署（物理拆分）」是风险最低的路径。