单体应用 vs 微服务

单体还是微服务？这不是非此即彼的选择，而是演进过程中的阶段性决策。

1. 单体架构

所有功能模块打包为单个应用，共享代码库与数据库。

类型演进

简单单体 → 模块化单体 → 分布式单体（伪微服务）
   ↑              ↑               ↑
  起步阶段      团队扩大        反模式

单体优势

单体痛点

• 代码耦合严重，任何改动都需全量回归
• 技术栈锁死，难以渐进式引入新技术
• 部署粒度粗，小改动也需全量发布
• 团队并行开发困难，合并冲突频发

模块化单体

渐进式改良：在单体内部划分清晰模块，为未来拆分做准备。

// 通过包结构体现模块边界
com.example.order
  ├─ application
  ├─ domain
  ├─ infrastructure
  └─ api

com.example.inventory
  ├─ application
  ├─ domain
  ├─ infrastructure
  └─ api // 仅暴露接口，不依赖 order 内部

2. 微服务架构

将应用拆分为多个独立部署的服务，每个服务围绕业务能力构建。

微服务特征

拆分策略

┌──────────────────────────────────────────┐
│             按业务能力拆分（推荐）          │
│  Order Service | Inventory Service | ...  │
├──────────────────────────────────────────┤
│             按子域拆分（DDD）              │
│  Core Domain | Supporting | Generic       │
├──────────────────────────────────────────┤
│             按团队边界拆分（康威定律）      │
│  Team A → Service A | Team B → Service B  │
├──────────────────────────────────────────┤
│             按数据变更频率拆分             │
│  高频数据独立服务 | 低频数据共享服务        │
└──────────────────────────────────────────┘

3. 康威定律

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

—— Melvin Conway, 1968

系统设计受限于沟通结构。反过来说：想实现什么架构，先构建对应的组织。

逆康威定律

主动调整组织结构以匹配期望的架构：

期望架构              组织结构
─────────           ─────────
Order Service    ←→ Order Team
Payment Service  ←→ Payment Team
User Service     ←→ User Team
(微服务)             (自治小队)

团队拓扑

4. 演进路径

不要一次到位，遵循演进式拆分策略：

Step 1: 单体（启动验证）
    ↓ 业务验证成功，团队扩张
Step 2: 模块化单体（清晰边界）
    ↓ 某模块独立发布需求强烈
Step 3: 提取独立服务（逐个拆分）
    ↓ 持续演进
Step 4: 微服务集群（按需扩展）

绞杀者模式（Strangler Fig）

渐进替换遗留系统：

┌──────────────┐
│  单体应用     │
└──────────────┘
      ↓
┌──────────────────────────┐
│  API Gateway              │
│    ├─ /api/v2/orders  →  Order Service（新）
│    └─ /api/v1/*       →  单体（遗留）
└──────────────────────────┘

5. 何时拆分微服务

6. 微服务挑战

总结

建议：系统早期从单体开始，业务发展后再渐进式拆分。微服务不是目标，而是解决组织与规模问题的手段。