微服务拆完后效率更低：服务边界、依赖治理与合并决策指南

问题现象：拆分带来的复杂度超过收益

微服务不是架构成熟度勋章。团队规模较小、业务边界不稳定时，过早拆分会增加网络调用、数据一致性、部署、监控和协作成本。一个需求需要修改多个仓库并协调多次发布，说明服务边界可能切在了技术层而不是业务能力上。

边界应围绕变化原因

把用户、订单、库存等业务能力作为候选边界，观察它们是否由不同团队负责、是否独立扩缩容、是否有不同可靠性要求。不要把控制器、服务层和数据访问层分别做成远程服务。高频互相调用、共享同一张表和必须同时发布的服务，通常缺乏真正独立性。

依赖方向必须清晰

建立服务目录，记录负责人、接口、数据所有权、上下游和可靠性目标。同步调用链不宜过长，非实时流程可通过事件解耦，但不能用消息掩盖不清晰的业务关系。公共库只放稳定、无业务语义的能力，避免一个共享包升级导致全公司同时发布。

什么时候应该合并

如果两个服务长期由同一团队维护、总是一起变化、数据强耦合且没有独立容量需求，合并可能降低总成本。合并不是架构倒退，而是根据真实变化重新调整边界。可以先建立模块化单体，用代码边界和测试保证隔离，待团队和业务成熟后再拆。

用指标评价架构

观察需求交付时间、跨团队协调次数、发布失败率、调用故障率和基础设施成本。问：服务多大才合适？答：没有统一行数标准，关键是能否独立拥有和独立变化。问：是否要一步回到单体？答：可从最痛的耦合链路开始，逐步合并或重构，避免再次进行大爆炸式改造。