最糟糕的微服务结果是**"分布式单体"**：服务在物理上是分离的，但耦合度如此之高，以至于必须一起部署——你获得了分布式的所有成本，但没有任何独立性。
✗ Changing one service forces redeploying several others
✗ Services share a database / shared schema
✗ A single request fans out through many synchronous hops
✗ Releases must be coordinated across teams
→ you pay network + ops cost but lost independent deployability
| 反模式 | 问题 |
|---|
| 共享数据库 | 重新耦合服务；无法独立更改 schema |
| 过度通信的服务 | 每个请求有许多同步调用 → 延迟、脆弱性 |
| 纳米服务 | 粒度过细；开销远大于逻辑 |
| 无 API 版本控制 | 一个改动会破坏每个消费者 |
| 同步链 | 延迟和故障沿着 A→B→C→D 倍增 |
| 上帝服务 | 一个所有人都依赖的服务（新的单体） |
通常是错误的边界划分。按技术层或实体（而非业务能力）拆分的服务最终会过度通信和相互依赖。
bad: User-svc, Product-svc, Cart-svc all called for one checkout
good: Checkout owns the capability end to end
分布式单体严格来说比真正的单体更差——更慢、更难调试、更难操作，但仍然无法独立部署。
大多数反模式都源于边界和共享数据库，因此正确确定 bounded context 和数据所有权是区分有益微服务和有害微服务的关键。