微服务拆分的反思：我们过度拆分了
Microservices Regret: We Over-Split Our Services
| Kevin | 2026-09-02T11:27:48
两年前把单体应用拆成了 12 个微服务，现在回头看至少有一半是不必要的拆分。分享一下教训。
Split our monolith into 12 microservices two years ago. In hindsight, at least half were unnecessary. Sharing the lessons learned.
两年前我们把一个运行良好的单体应用拆成了 12 个微服务，理由是"微服务是趋势"。现在回过头来看，这可能是我们做过最亏的一次技术决策。 拆分之后的代价 运维成本翻倍 原来一个应用一个数据库一套部署，现在 12 个服务各有自己的： 12 套 CI/CD 流水线 12 个容器编排配置 8 个独立数据库（有些服务共用了） 服务发现、配置中心、链路追踪、日志聚合… 光是维护这些基础设施就够一个人忙的了，而我们团队一共才 8 个人。 分布式事务的噩梦 原来一个 @Transactional 就搞定的事，拆分之后变成了 Saga 模式或者 TCC。代码复杂度至少翻了 3 倍，而且一旦出问题排查成本极高。 联调效率低下 改一个功能可能涉及 3-4 个服务的改动，需要同时启动多个服务才能联调。本地跑完整环境的电脑内存都不够用了。 什么时候该拆 现在我的判断标准是： 团队规模：超过 20 人再考虑拆。小团队搞微服务就是给自己找罪受 独立发布需求：某个模块确实需要独立于其他模块发布 技术异构：某个模块确实需要用不同的技术栈 性能隔离：某个模块的负载特征完全不同，需要独立扩缩容 如果以上条件都不满足，单体 + 好的模块化就够了。 我们的回退方案 没有全部合回单体，而是合并成了 3 个服务：核心业务、数据分析、消息推送。这三个确实有独立的扩缩容需求和发布节奏。其他 9 个"微服务"合并到核心业务服务里了。 教训 架构选型要基于实际痛点而不是技术趋势。"微服务"这三个字本身不会让你的系统变好，但一定会让你的运维变复杂。先做好模块化，等真正感受到单体的痛再考虑拆分。
Split a well-functioning monolith into 12 microservices because "microservices are the trend." Biggest regret in tech decisions. The Cost 12 CI/CD pipelines, 8 databases, distributed transaction nightmares (Saga/TCC), and cross-service debugging for an 8-person team. When to Split Only when: 20+ developers, genuine independent release needs, technology heterogeneity requirements, or distinct scaling patterns. Our Rollback Consolidated from 12 to 3 services (core business, analytics, messaging). The other 9 merged back into the core service. Lesson: Architecture should follow actual pain points, not trends. Good modularization inside a monolith solves most problems.