一、单体架构的困境：为什么我们要离开舒适区？

说实话，我见过太多团队在单体架构里待得很舒服。

一开始确实爽。一个项目，一套代码，部署简单，调试方便。但慢慢地，问题就来了。我记得有个电商项目，刚开始只有几千行代码，半年后膨胀到几十万行。每次发布都像在走钢丝。

今天我们就从三个角度，聊聊单体架构到底卡在哪。

1.1 成本：你以为省钱，其实在烧钱

很多人觉得单体省钱。一台服务器，一个进程，搞定。但这是错觉。

1.1.1 硬件成本被低估

单体应用一旦流量上来，你就得升级机器。4核变8核，8核变16核，内存从16G加到64G。我有个客户，双十一期间直接把服务器从32核升到128核，一个月云账单多了十几万。

你想想看，如果拆成微服务，大部分服务其实用不到那么高配置。只有核心服务需要扩容，其他服务保持低配就行。

1.1.2 人力成本更隐蔽

单体应用改一行代码，可能影响整个系统。我经历过一次，改了个日志级别，结果触发了某个模块的缓存失效，线上挂了半小时。

为什么？因为代码耦合太深。一个功能改动，你得理解整个模块的上下文。新人上手至少两个月，老手也不敢随便动。

说白了，单体架构的维护成本是线性增长的，但人力成本是指数增长的。

1.2 扩展性：想快？门都没有

扩展性分两种：水平扩展和垂直扩展。单体架构在两方面都吃亏。

1.2.1 水平扩展的尴尬

水平扩展就是加机器。但单体应用加机器，你得把整个应用复制一份。哪怕你只想要某个模块的更多实例，也得把整个应用部署一遍。

举个例子，你的订单模块需要处理双十一的流量，但用户模块其实很闲。单体架构下，你只能把整个应用都扩容。结果就是，订单模块的压力缓解了，但用户模块的资源白白浪费。

# 单体架构的扩容方式
# 你只能复制整个应用
docker run -d --name order-service-1 my-monolith:latest
docker run -d --name order-service-2 my-monolith:latest
# 所有模块都跟着一起跑，浪费资源

1.2.2 垂直扩展的天花板

垂直扩展就是升级单机配置。但单机总有上限。我记得有个金融项目，数据库连接数到了2000，再往上加机器也解决不了，因为应用层和数据库层耦合太紧。

为什么会这样？因为单体架构里，所有模块共享同一个数据库连接池。一个模块的慢查询，会拖垮整个系统的数据库连接。

1.3 运维压力：每天都在救火

运维压力是单体架构最容易被忽视的痛点。我做了这么多年，见过太多运维同学被单体应用折磨得想转行。

1.3.1 发布就是一场豪赌

单体应用发布，你得停服或者灰度。但灰度很难做，因为整个应用是一个整体。你没法只灰度某个模块。

我记得有一次，我们发布一个新功能，结果影响了登录模块。用户登录不了，客服电话被打爆。最后只能回滚，但回滚又花了半小时。

• 发布周期长： 从代码提交到上线，至少需要2小时（编译+测试+部署）
• 回滚风险高： 一个模块出问题，整个应用都得回滚
• 监控困难： 所有日志混在一起，定位问题像大海捞针

1.3.2 故障隔离几乎为零

单体架构里，一个模块的内存泄漏，会导致整个应用OOM。一个模块的死循环，会占满所有CPU。

我有个朋友的公司，因为某个定时任务没写好，导致整个应用CPU飙到100%。所有接口都超时，业务停了整整一个下午。

1.3.3 团队协作的噩梦

当团队超过10个人，单体架构的协作问题就暴露了。代码冲突频繁，合并分支要等半天。每个人都在改同一个代码库，但谁都不敢保证自己的改动不影响别人。

我曾经带过一个20人的团队，每次迭代光解决代码冲突就要花一天。后来我们拆成了微服务，每个团队负责自己的服务，冲突少了，效率反而高了。

1.4 总结：离开舒适区，不是矫情

说了这么多，你可能会问：单体架构真的那么不堪吗？

其实不是。对于小项目、小团队，单体架构依然是最优解。但一旦业务增长、团队扩张，它的痛点就会暴露无遗。

我个人习惯把单体架构比作「小作坊」。小作坊能做精致的手工艺品，但做不了大规模生产。当你的业务需要快速迭代、弹性伸缩、故障隔离时，你就得考虑迁移了。

下一章，我会聊聊如何评估你的项目是否适合迁移到Serverless。嗯，这里先卖个关子——不是所有项目都适合，选错了反而更痛苦。