本文探讨了微服务的实际应用与局限性。作者指出，负载均衡、熔断等概念在微服务出现前已存在，且微服务与MQ、Redis等技术关联有限。微服务旨在解决“一荣俱荣，一损俱损”的问题，并通过独立伸缩、升级和管理大量开发人员来提供优势。然而，实际中服务常“一崩全崩”，解耦未能有效解决人员耦合问题。此外，微服务增加了代码量和隐性成本，并将复杂度转移到基础建设，许多公司难以消化。作者预测，在AI辅助编程提升效率的2025年，单体应用有望重回主流。
💡 微服务概念并非全新，负载均衡、熔断等技术早于微服务出现，且其与MQ、Redis等技术关联有限，并非核心依赖。
🚀 微服务旨在解决服务间的“一荣俱荣，一损俱损”问题，并提供独立伸缩、独立升级以及更好管理大型开发团队的能力，但实际应用中服务常出现“一崩全崩”的情况，且服务解耦未能有效解决人员的耦合问题。
💰 微服务架构带来了显著的成本增加，包括代码量翻倍以及难以消化的基础设施复杂性转移，其本质是管理开发人员而非代码，解耦复杂社会关系才是其精髓，但现实中服务数量常远超人员数量。
📈 随着AI辅助编程在2025年极大提升开发效率，微服务的必要性降低，文章预测单体应用将有机会重回主流，因为其基础建设成本相对较低，且99%的项目并不需要微服务提供的独立伸缩和升级能力。
- 单体不是单机，不是单模块
2. 负载均衡、熔断、降级在微服务出世前早存在了
3. 微服务和 MQ 、Redis 顶多只有半毛钱关系，微服务怎么用单体就怎么用
微服务尝试解决什么问题？
保障多个 p0 服务不会一崩全崩。然而实际上大多数微服务就是一崩全崩。
将服务独立，减少耦合。如果不同服务由不同部门/人员负责这是好的，实际上大多数使用情况是服务解耦人没有解耦。
微服务实际只解决了三个问题：
1. 服务独立伸缩
2. 服务独立升级
3. 管理大量开发人员
单体无法单独伸缩其中一个服务，只能全部一起水平扩容，这是确实存在的缺点，但 99%的项目并不需要该特性，基础建设很贵，机器很便宜。
单体无法单独升级一个服务，但这特性只是理论上听起来不错，微服务中的一个服务依赖其他服务，实际使用中很难单独只升级一个，需要上下游一起升级。
微服务不是管理代码的架构，而是管理开发人员的架构。解耦服务没有实际上的收益与意义，解耦复杂的社会关系才是其精华所在。然而现实中多少项目服务比人还多呢。
复杂度不会消失只会转移，微服务将复杂度转移到基础建设中，而大多数公司无法消化。微服务有成本，首先代码量就先翻个倍，除此之外还有更多隐形成本。
现在是泡沫破裂的 2025 年，AI 辅助编程让开发人员效率极大提升，往后应该是单体重登王座的时代。
