反模式
分布式单体、过度消息化。
25 分钟
反模式
集成模式能解决分布式协作问题,但 误用 会带来 分布式单体、调试地狱、运维爆炸。本课列出常见坑,帮你在拆服务与上 MQ 前 踩刹车。
学习目标
- 识别分布式单体与过度消息化
- 评估「为模式而模式」的成本
- 回顾本 track 各模式的适用边界
分布式单体(Distributed Monolith)
order-svc ──同步 Feign──► inventory-svc
▲ │
└────── 同步 Feign ─────────┘
(必须一起部署、一起扩缩、改一处牵全身)
表面多个 jar,实质:
- 同步链 环状依赖,任一变更需全链路回归
- 共享数据库 或多服务写同一表
- 无法独立发布
对策:真拆 业务边界 + 数据所有权;跨边界用 ip-event-driven 或清晰 API,见 sc-architecture 拆分原则。
过度消息化
| 症状 | 问题 |
|---|---|
| 查用户名也走 Kafka | 延迟、运维 > 收益 |
| 无 Outbox 直接发 MQ | 库与消息不一致 |
| 无 ip-idempotency | 重复消费出事故 |
该同步仍同步:用户等结果的扣库存用 Feign(ip-sync-async)。MQ 用于 解耦、削峰、广播,不是万能 RPC。
胖 BFF / 胖 Gateway
BFF 堆满领域规则 → 新单体(ip-bff)。Gateway 做业务聚合 → 难测试。
Gateway:路由、鉴权、限流(sc-gateway);业务编排在 BFF 或组合服务。
忽略可观测性
事件链比 Feign 难查:必须有 correlationId、统一日志、Consumer lag 监控(kafka-monitor、rmq-monitor)。没有追踪就勿拆。
选型过度
- 三行 CRUD 上 Saga + CQRS + Kafka
- 全站 GraphQL 而读多写少、缓存简单(gql-rest 已说明 REST 理由)
CodeRoadMap ** deliberately 单体** 是正确默认;模式是为 真实瓶颈 准备。
自检清单
- 服务能否 且不破坏他人?