^__^ • 11 / 07
过去十年，几乎所有架构演进的故事，都指向微服务，微服务几乎成了现代架构的代名词，单体被骂成毒瘤。 直到近几年，业界开始反思：微服务是不是新的毒瘤？ 越来越多团队发现，微服务带来的问题不比它解决的少。复杂的部署链路、无穷无尽的接口治理、跨团队协调的噩梦——这些都让拆分变成了新的枷锁。于是，单体重新被提起。曾经被视为落后的它，如今又被不少工程师视作理性回归。 单体架构的本质很简单：所有核心功能运行在一个进程里，模块之间靠函数调用。听起来“老土”，但它有三个优势：高效、直接、可控。部署只需一次，调试能断点，测试范围清晰。很多中小业务在这个架构下运行多年，稳定、经济，问题少。 那为什么微服务会崛起？因为系统变大了。 当团队规模扩大、技术栈多样、功能快速膨胀时，单体的缺点开始放大：任何一个小错误都可能拖垮整个系统。此时，“把不可靠的部分隔离起来”成为唯一出路。微服务就是对这种不确定性的工程化应对：它假设错误一定会发生，于是通过拆分边界，把问题锁在最小范围内。 它以复杂换可靠，用成本换自治，用高要求的架构师替代低风险的维护逻辑。互联网厂商们的架构图像蜘蛛网一样密集，那是可用性换来的代价。没有足够的监控、自动化、灰度、认证体系，微服务接口治理、依赖地狱、跨团队协作的成本，全都堆上来了。 对一个早期业务，单体意味着效率和确定性；对一个团队成熟、系统庞大的组织，微服务可能是必要的防线。 判断是否应该微服务的关键是三点： 团队是否足够大到需要独立边界；技术栈是否多到必须解耦；系统的变更是否频繁到难以整体发布。 如果这三点都没触发，微服务不是救星，而是拖累。 对开发者来说，最重要的一点是：别急着跟风，先判断自己到底到了哪一步。 因为很多时候，你以为需要微服务，其实只是需要写好一点的代码。在工程实践上，架构演进应当遵循渐进式原则。当业务增长、团队扩张时，不要一刀切地推翻旧系统，而应从边界清晰、变更频繁的模块开始拆分，通过事件总线、接口网关或服务注册中心逐步过渡。让监控、灰度、回滚、自动化部署先跑在前面，再去谈微服务。只有当可观测、治理、容灾三项基础能力稳定后，微服务才可能真正落地，否则只会换一种方式制造混乱。 延展阅读：单体架构比微服务架构更落后吗？ 你是怎么看待这个问题的？欢迎留言评论分享，有机会获得社区精美周边一份。