微服务常见反模式

用途：评审架构方案时对照检查

结构性反模式

反模式	症状	后果	修正
分布式单体	服务必须一起发布、一起测试；跨服务事务与强同步调用	承担分布式的代价却拿不到独立交付的收益	重划边界，消除跨服务共享状态与同步等待
纳米服务	服务数量远超团队数，单服务只有几个接口	运维与联调成本爆炸	合并到能独立交付与运维的粒度
按技术分层拆服务	Controller 服务、Service 服务、DAO 服务	一个需求要改三个服务并发布三次	按业务能力/限界上下文拆
共享数据库	多服务读写同一库表	事实上的耦合中心	数据所有权归一，接口或事件交换
网关变上帝对象	业务规则写进网关/BFF	网关成为发布瓶颈与耦合点	网关只做路由、鉴权、聚合

过程性反模式

反模式	症状	修正
先拆再说	以“微服务”为目标而非以交付效率为目标	用发布冲突、故障隔离、扩容需求论证
基础设施缺位先拆	没有 CI/CD、集中日志、指标、追踪、契约测试	先补平台能力，或先做模块化单体
无人负责的服务	服务无 owner、无值班、无 SLA	每个服务有端到端负责团队
契约自由演化	接口随意破坏，下游频繁救火	版本策略 + 兼容性规则 + 契约测试
用微服务解决组织问题	团队沟通不畅却指望拆服务改善	先调整团队与职责（康威定律）

数据与一致性反模式

• 跨服务长事务：一个用例串行调用四五个服务并要求全部成功 → 改 Saga 或重划边界。
• 循环依赖：A 调 B、B 调 A（或事件环） → 引入事件驱动或提取共享能力到第三方。
• 查询侧串行拉取：列表页为拼字段循环调用 N 个服务 → 投影表、宽表或搜索引擎。
• 只有最终一致没有对账：不一致无法被发现 → 任何异步方案都配对账。

可观测与运维反模式

• 只有 CPU 内存看板，没有 RED 指标与业务量。
• 日志无 TraceId，异步链路断链。
• 无灰度与快速回滚能力，一次发布全量。
• 告警按原因（CPU 高）而非症状（错误率）触发，且无处置手册。

自检清单

1. 一个需求从提出到上线，需要几个团队协同？（>2 说明边界错）
2. 任一服务能否独立发布？（不能即分布式单体）
3. 每张表是否只有一个写入方？
4. 同步调用链最大深度是多少？（>3 需审视）
5. 是否有服务级 SLA、值班与容量负责人？
6. 新服务上线是否自带指标、日志、追踪与告警？

延伸阅读

• Sam Newman《Building Microservices》第 2 版
• Chris Richardson《微服务架构设计模式》
• Martin Fowler 相关词条：Distributed Monolith、Strangler Application