单体架构回顾：从辉煌到瓶颈

聊混合架构之前，我觉得有必要先回头看看单体架构。毕竟，不了解过去，就很难理解现在为什么要变。我最早做项目时，清一色全是单体架构。那时候觉得，一个项目一个包，部署简单，管理也方便。但后来随着业务膨胀，问题就一个个冒出来了。

单体架构的优缺点

先说说优点吧。说实话，单体架构在早期阶段真的很香。

• 开发简单：一个IDE，一个项目，代码都在一个工程里。我习惯把所有模块放在一起，调试起来特别方便。
• 部署容易：打一个jar包或war包，扔到服务器上就能跑。我记得有一次上线，前后只用了十分钟。
• 测试成本低：单元测试、集成测试都在一个进程里，不需要启动各种外部服务。
• 运维省心：监控一个进程就够了，不像微服务那样要盯着几十个服务。

但缺点也很明显。你想想看，当项目代码量超过10万行时，会发生什么？

• 代码耦合严重：一个模块改了，可能影响到其他模块。我在项目中遇到过，改了一个支付接口，结果订单模块也跟着出问题。
• 团队协作困难：多人同时修改同一个代码库，合并冲突能让人崩溃。
• 技术栈锁定：一旦选了Java，就很难再引入Go或Python。说白了，整个项目被绑死在一个技术栈上。
• 扩展性差：只能整体扩展，不能针对某个热点模块单独扩容。

单体架构的性能瓶颈分析

性能问题，是单体架构最让人头疼的地方。我做过一个电商系统，高峰期时，订单模块和商品模块抢CPU资源，结果整个系统都变慢了。

具体来说，性能瓶颈主要集中在以下几个方面：

瓶颈类型	原因	表现
CPU瓶颈	所有请求都在一个进程里处理	高并发时CPU飙升，响应变慢
内存瓶颈	所有模块共享堆内存	某个模块内存泄漏，拖垮整个系统
IO瓶颈	数据库连接、文件读写集中	数据库连接池耗尽，请求排队
启动瓶颈	代码量大，启动时间长	重启一次要5分钟，影响发布效率

为什么会这样？说白了，单体架构把所有功能都塞进一个进程里。就像一条单车道，所有车都挤在一起。一旦某辆车抛锚，整条路都堵死了。

我记得有一次线上事故，一个报表查询功能消耗了大量内存，导致用户登录模块也响应超时。嗯，这就是典型的「一颗老鼠屎坏了一锅粥」。

单体架构的适用场景

虽然我一直在吐槽单体架构，但它并不是一无是处。在某些场景下，它反而是最佳选择。

• 小型项目：比如内部管理系统、工具类应用。用户量不大，功能简单，单体架构完全够用。
• 创业初期：团队小，资源有限，快速验证业务模式才是重点。我建议先用单体架构跑起来，等业务稳定了再考虑拆分。
• 原型开发：做POC（概念验证）时，单体架构能让你最快看到效果。
• 低并发场景：日均PV在10万以下，单体架构的性能完全能扛住。

最后，我用一张图来总结单体架构的核心逻辑：

这张图很直观：所有模块都在一个进程里，共享内存和数据库。好处是简单，坏处是——一旦某个模块出问题，整个应用都受影响。

好了，关于单体架构就聊这么多。下一章我们开始讲分层架构，看看它是怎么解决单体架构的痛点的。