微服务踩过的坑：那些年我们一起追过的架构

十年前，微服务是技术圈最热门的话题。所有人都在谈论"拆分"、"解耦"、"独立部署"。好像只要把单体应用拆成微服务，所有问题都会迎风而解。

十年后，很多公司开始反思：我们是不是拆得太早了？拆得太碎了？

这不是说微服务不好，而是说微服务被过度神话了。它是一个有力的工具，但不是万能药。

微服务的本质

微服务的核心思想是把一个大的应用拆分成多个小的服务，每个服务独立开发、独立部署、独立扩展。服务之间通过 API 通信，各自拥有自己的数据库。

这个思想的好处是显而易见的。每个服务由一个小团队负责，团队之间可以独立迭代。一个服务的变更不需要重新部署整个系统。不同的服务可以用不同的技术栈。单个服务的故障不会导致整个系统崩溃。

但这些好处是有代价的。

坑一：过早微服务化

最常见的错误是过早地把应用拆分成微服务。

一个只有几个开发者、业务还在快速变化的初创公司，把应用拆成二十个微服务，每个服务有自己的代码仓库、CI/CD 流水线、监控告警。开发者的时间大部分花在了服务间通信、分布式调试、数据一致性上，而不是业务功能上。

单体应用在这个阶段是更合理的选择。一个代码仓库、一个部署单元、一个数据库，开发效率最高。当业务稳定了、团队规模大了、单体应用的维护成本超过微服务的维护成本时，再考虑拆分也不迟。

过早优化是万恶之源，过早微服务化是过早优化的一种形式。

坑二：拆分粒度太细

有些团队走向了另一个极端：把服务拆得太细。一个简单的业务流程可能需要调用十几个服务，任何一个服务出问题都会影响整个流程。

服务间的网络调用有延迟和不可靠性。单体应用中的一个函数调用是纳秒级的、100% 可靠的。微服务间的一次 API 调用是毫秒级的、可能失败的。当你把一个函数调用变成一次网络调用，你就引入了延迟、超时、重试、熔断等一系列复杂性。

拆分粒度应该基于业务边界，而不是技术边界。一个"用户服务"应该包含所有和用户相关的功能，而不是把"用户注册"、"用户登录"、"用户信息管理"拆成三个服务。

坑三：分布式数据一致性

单体应用中，数据一致性是简单的。一个数据库事务可以保证多个操作要么全部成功，要么全部失败。

微服务架构中，每个服务有自己的数据库。跨服务的数据一致性需要使用分布式事务或者最终一致性的方案。分布式事务（比如两阶段提交）性能差、可用性低。最终一致性方案（比如 Saga 模式）实现复杂、调试困难。

很多团队在拆分服务时没有充分考虑数据一致性的问题，结果发现某些业务操作在拆分后无法保证一致性，不得不重新设计架构。

我的建议是：在拆分服务前，先画出业务的数据流图，识别哪些操作需要强一致性，哪些可以接受最终一致性。强一致性的操作应该在同一个服务内完成。

坑四：运维复杂性

微服务的运维复杂性远超单体应用。

单体应用只需要监控一个服务，微服务需要监控几十甚至几百个服务。一个请求可能经过十几个服务，排查问题需要查看多个服务的日志。服务间的依赖关系复杂，一个服务的变更可能影响多个下游服务。

分布式追踪、集中日志、服务网格这些工具可以缓解运维复杂性，但它们本身也需要学习、部署和维护。工具的复杂性叠加在架构的复杂性之上，形成了"复杂性套娃"。

没有足够的运维能力就贸然采用微服务，结果可能是：开发者花在运维上的时间比写代码还多。

坑五：团队组织不匹配

微服务架构不只是技术架构，也是组织架构。

康威定律说：系统的设计反映了组织的沟通结构。微服务架构要求每个服务由一个小团队端到端负责（开发、测试、部署、运维）。如果组织结构不匹配，微服务的优势就发挥不出来。

如果你的团队仍然是按职能划分（前端组、后端组、测试组、运维组），而不是按服务划分，那微服务只会增加跨团队协调的成本。

Conway 的逆定律也成立：如果你想要微服务架构，先调整组织结构。

什么时候该用微服务

微服务不是不好，是要在合适的时候用。

适合微服务的场景：团队规模大（几十人以上），需要独立迭代和独立部署；业务边界清晰，服务间的耦合度低；有足够的运维能力和基础设施支持。

不适合微服务的场景：团队规模小（几个人），业务还在快速探索，没有专业的运维团队。

一个务实的策略是"从单体开始，按需拆分"。先用单体应用快速验证业务，当单体应用的某个模块需要独立扩展或者独立迭代时，再把它拆分成独立的服务。这种渐进式的演进比一步到位的微服务化更安全。

我的判断

微服务是大型系统的合理架构选择，但它不是所有系统的合理架构选择。

技术社区有一个不好的倾向：把成功公司的架构当作"最佳实践"，然后不加思考地模仿。Netflix 用微服务成功了，不代表你的创业公司也需要微服务。Netflix 有几千个工程师，你可能只有几个。

架构决策应该基于实际的问题和约束，而不是基于技术时尚。如果你的单体应用运行良好、团队高效、业务增长，那就没有理由拆分成微服务。

最无聊的架构往往是最好的架构。它不炫技、不追新，但稳定、可维护、团队熟悉。在生产环境中，可靠比先进更重要。