单体 vs 微服务故障域

故障域（Failure Domain） 是一次故障影响的 最大范围。Blast radius 越小，系统越 resilient。CodeRoadMap 当前是 宝塔单机单体；理解对比后，再决定是否值得拆服务。

学习目标

• 比较单体与微服务的故障传播路径
• 理解部署单元与 blast radius
• 对照 sc-intro 与 /roadmaps/spring-boot monolith 节点

单体故障域

┌──────────────────────────────────────┐
│  VPS（宝塔）                          │
│  ┌─────────┐  ┌─────────┐           │
│  │ platform│  │ backend │  ← 一 jar  │
│  │ :3000   │  │ :8080   │           │
│  └────┬────┘  └────┬────┘           │
│       └──────┬─────┘                │
│              ▼                       │
│         MySQL :3306                  │
└──────────────────────────────────────┘
  任一进程 OOM → 可能整站不可用
  优点：无网络级联；调试简单

微服务故障域

[Gateway] ──┬── user-svc    ✓
            ├── course-svc  ✗ OPEN
            └── progress-svc ✓

course-svc 挂 → 仅课程相关 API 降级
              → 但 fan-out 网络故障增多

每服务独立进程 缩小功能域，但引入 注册中心、网络、分布式追踪 等新故障点（sc-observability）。

对比表

维度	单体（CodeRoadMap 现况）	微服务
部署	一个 jar，宝塔一键重启	多容器/多进程
故障传播	进程内异常、共享连接池	网络超时、级联（rel-cascade）
扩容	垂直升配 VPS	水平扩单个服务
复杂度	低	需熔断、追踪、配置中心

何时不必拆

• 团队小、流量可控、边界清晰
• 可靠性瓶颈在 DB、磁盘、无超时——拆服务不解决根因

何时考虑拆

• 模块 独立扩缩 需求明显
• 团队 并行发布 冲突频繁
• 已有成熟 可观测与容错 基建

反模式见 ip-anti。

练习

• 画 CodeRoadMap 单体 blast radius 图
• 假设拆出 progress-service，多出一个什么新故障点？
• 列举两个「拆服务也解决不了」的可靠性问题

小结

单体故障域大但简单；微服务域小但链路复杂。 下一课：SLO 与错误预算。