微服务架构被滥用的情况不少，结合几个项目经验聊聊常见陷阱。\n\n常见问题：\n\n1. 按技术层拆分（API/Service/DAO）导致分布式单体。服务数量上去了，但代码改动还是需要同步修改多个服务，部署依然要一起进行，运维成本上升却没拿到微服务的收益。\n\n2. 服务粒度太小，运维复杂度反而上升。每个服务都要 CI/CD、监控、日志、链路追踪，团队规模和工具链跟不上时，几个人的小团队维护几十个服务效率远不如单体。\n\n3. 数据归属不清晰，分布式事务泛滥。订单、库存、支付等服务互相依赖，跨服务的数据一致性需求导致大量补偿、对账逻辑，代码复杂度爆炸。\n\n4. 跨服务调用链路过长，排查问题困难。一个请求经过 8-10 个服务，任何一个慢都会拖垮整体响应时间，定位问题需要完善的链路追踪工具支持。\n\n你们团队在微服务拆分上有哪些经验教训？怎么判断一个服务该不该拆？