反模式

集成模式能解决分布式协作问题，但 误用 会带来 分布式单体、调试地狱、运维爆炸。本课列出常见坑，帮你在拆服务与上 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 单体** 是正确默认；模式是为 真实瓶颈 准备。

自检清单

• 服务能否 且不破坏他人？