1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

被骂的"单体"，其实是"没设计的单体"——大泥球：

  - 所有代码堆在一个工程里
  - 模块间任意互相调用（没有边界）
  - 数据库一张大表谁都能读写
  - 改一处怕牵连全身
  - 发布必须整体一起发

  这些问题，根因不是"单体"，是"没有边界"。
  把同样的代码拆成 20 个微服务，边界还是乱的，
  只是把"一个大泥球"变成了"20 个小泥球 + 网络"。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

单体（即使不模块化）天然拥有的好东西：

  ✓ 一个进程内调用，没有网络开销
      → 性能天花板高，调试简单

  ✓ 强一致性"免费"
      → 一个数据库事务搞定，不用 Saga、不用最终一致

  ✓ 部署简单
      → 一个二进制 / 一个镜像，没有编排地狱

  ✓ 开发体验好
      → 一个 IDE 打开全栈，重构随便改，编译器帮你查

  ✓ 监控简单
      → 一个进程的日志、指标，不用分布式追踪

  ✓ 没有"分布式税"
      → 不用服务发现、配置中心、链路追踪、熔断……

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

单体扛不住的信号（出现这些，才考虑拆）：

  1. 团队规模超过 8~10 人，互相踩脚
     → 多人改同一个工程，合并冲突、发布互相阻塞

  2. 局部需要独立扩容
     → 只有"秒杀"模块要 100 倍算力，整体扩太浪费

  3. 局部需要独立的技术栈 / 发布节奏
     → AI 推理要用 Python，核心交易用 .NET，没法塞一起

  4. 故障爆炸半径太大
     → 一个小 bug 拖垮整个进程，影响所有功能

  注意：上面任何一条单独出现，都不一定非要上微服务。
       先看能不能用"模块化单体 + 进程内隔离"解决。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

┌─────────────────────────────────────────────┐
│              单体应用（一个进程）              │
│                                              │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐     │
│  │ 订单模块  │ │ 用户模块  │ │ 商品模块  │     │
│  │ Order    │ │ User     │ │ Product  │     │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘     │
│       │  只通过模块的公开接口调用  │           │
│       └──────────┬──────────────┘           │
│              ┌───┴────┐                      │
│              │ 共享内核 │                      │
│              └────────┘                      │
└─────────────────────────────────────────────┘

  规则：
    - 模块之间不直接 new 对方的内部类
    - 只调用对方 module 暴露的 Service / 接口
    - 理想情况下，每个模块有自己独立的表（Schema 隔离）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

1. 按业务能力划分模块（不是按技术分层）
   订单、用户、商品、支付…… 而不是 Controller/Service/Dao

2. 模块对外只暴露少量接口（公开 API）
   内部实现细节对其他模块不可见

3. 数据归属清晰
   订单表只有订单模块写，别人要数据走订单模块的接口
   （这条最难，也最关键——下一节展开）

4. 工程结构上做硬隔离
   - .NET：每个模块一个 Project，依赖方向单向
   - 用 InternalsVisibleTo / 架构测试（如 NetArchTest）强制约束
   - 谁违规了编译/测试就挂

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

模块化单体 vs 微服务：

  模块化单体：先在进程内把边界画对
    - 边界画错了？重构成本 = 改代码（小时级）
    - 跑通了再决定要不要物理拆开

  直接上微服务：在网络上画边界
    - 边界画错了？重构成本 = 跨服务迁移数据和流量（周/月级）
    - 而且多了网络、一致性、运维一堆税

  结论：先用模块化单体验证边界，再考虑物理拆分。
       这是最稳的演进路径。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

错误做法：
  订单模块为了"方便"，直接 JOIN 用户表、商品表
  → 表结构耦合，用户表一改，订单模块崩
  → 边界形同虚设，又退回大泥球

正确做法：
  - 每个模块"拥有"自己的表（schema 或表前缀划分）
  - 别的模块要数据，调模块的接口，不直接读表
  - 共享库可以，但读写权限按模块隔离

  这一步做不好，模块化就是假的。
  数据边界，才是真正的边界。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

- Stack Overflow：几个单体应用撑住全球 Top 50 的流量
    几百台服务器，没用微服务，靠的就是模块化 + 极致优化

- Shopify：早期巨型 Rails 单体，逐步模块化
    到很大规模才开始"模块化单体 → 组件化"演进

- Basecamp（37signals）：长期单体 + 模块化
    明确反对过早微服务化

  共同点：先榨干单体的价值，确认边界，再按需拆。
  没有一上来就微服务的。