第3章单体架构的痛点

3、单体架构的痛点：代码耦合、部署困难、扩展瓶颈、团队协作冲突

说实话，很多团队一开始都是从单体应用起步的。这没什么丢人的，我自己也经历过。但当你真正踩过那些坑之后，你就会明白——单体架构的舒适区，其实是个温柔的陷阱。

今天咱们就来聊聊，单体架构到底痛在哪里。我把它归纳为四个核心痛点：代码耦合、部署困难、扩展瓶颈、团队协作冲突。一个一个说。

这是最要命的。单体应用里，所有功能都揉在一个进程里。用户模块、订单模块、支付模块……它们共享同一个数据库、同一个内存空间、同一个类加载器。

我在项目中遇到过这么一件事：一个同事改了一个工具类的静态变量，结果影响了整个系统的行为。那个工具类被十几个模块引用，改完之后，订单模块的缓存失效了，支付模块的日志格式变了，连用户登录都出了奇怪的问题。

为什么会这样？说白了，就是耦合太紧。你没法保证一个改动只影响一个模块。

耦合的典型表现：

你想想看，一个电商系统，用户下单、支付、发货、评价，这些功能全在一个代码库里。每次上线，你都得把整个应用重新编译、打包、部署。哪怕你只改了一行代码，也得把整个系统重启一遍。

嗯，这里要注意：代码耦合带来的最大问题，不是技术上的，而是心理上的。开发人员会变得不敢改代码，因为不知道改了之后会出什么问题。

单体应用的部署，我印象太深了。每次上线，都得挑个夜深人静的时候，全团队在线等着。编译、打包、上传、停服、替换、重启……每一步都提心吊胆。

我记得有一次，一个电商平台的大促活动前夜，需要紧急修复一个价格计算的Bug。整个团队从晚上10点开始准备，凌晨2点才完成部署。结果重启之后，发现缓存预热出了问题，系统响应慢得像蜗牛。又折腾了一个小时才恢复。

这就是单体部署的典型场景：

你看，一次部署下来，少说也得半小时到一小时。而且这期间，整个系统是不可用的。对于互联网应用来说，这就是真金白银的损失。

避坑指南：我曾经在部署时犯过一个低级错误——忘记更新配置文件。结果新版本上线后，数据库连接池配置还是旧的，导致连接数不够，系统直接挂了。从那以后，我养成了一个习惯：每次部署前，先检查配置文件的版本号。

很多人觉得，系统慢了，加机器不就行了？但单体架构的扩展，没那么简单。

单体应用是垂直扩展的。你加一台机器，就得把整个应用再部署一遍。而且，你没法只扩展某个模块。比如，你的支付模块压力大，但用户模块很空闲。在单体架构下，你只能整体扩展——多买几台服务器，把整个应用都部署上去。结果就是，支付模块的压力缓解了，但用户模块的资源浪费了。

我见过一个极端案例：一个社交平台的图片上传功能，高峰期流量是平时的100倍。单体架构下，他们只能加机器。但加了机器之后，数据库连接数不够了，又得升级数据库。升级了数据库，网络带宽又成了瓶颈。最后，整个架构被拖垮了。

说白了，单体架构的扩展是线性的，而且有天花板。你不可能无限加机器，因为总有一个组件会成为瓶颈。

注意：单体架构的扩展瓶颈，往往不是代码层面的，而是基础设施层面的。比如数据库连接数、网络带宽、文件描述符等。这些限制，加机器解决不了。

这是最让人头疼的。一个代码库，几十个开发人员同时在上面改。合并冲突是家常便饭，代码审查也变得异常困难。

我记得有个项目，团队有30多人。每次合并代码，都得花半天时间解决冲突。而且，不同模块的开发人员对代码风格、设计模式的理解不一样，导致代码质量参差不齐。

更麻烦的是，职责边界模糊。比如，用户模块的负责人想改一个接口，但这个接口被订单模块调用了。他得去跟订单模块的负责人沟通，确认改动不会影响对方。如果沟通不到位，就可能出问题。

我总结了一下，团队协作冲突的典型场景：

你想想看，一个团队里，有人想用Java 11的新特性，但有人还在用Java 8。有人想升级Spring Boot版本，但有人担心兼容性问题。这些争论，在单体架构下是无解的。因为所有模块都绑在一起，一个模块的升级，可能影响整个系统。

说了这么多，其实就一句话：单体架构在初期很香，但一旦规模上来，痛点就会暴露无遗。

我个人习惯把单体架构比作「合租」——大家住在一个房子里，共用厨房、卫生间、客厅。刚开始觉得热闹，但时间长了，矛盾就来了。有人想熬夜，有人想早睡。有人想养猫，有人过敏。最后，要么忍，要么搬出去。

微服务架构，说白了就是「分家」。每个模块独立部署、独立扩展、独立维护。但分家也有分家的麻烦——沟通成本高了，运维复杂了，数据一致性难保证了。

嗯，这些咱们后面再聊。下一章，我会讲讲从单体到微服务的演进策略，以及如何避免「为了微服务而微服务」的坑。

核心观点：单体架构的四个痛点——代码耦合、部署困难、扩展瓶颈、团队协作冲突——是推动架构演进的根本动力。如果你正在经历这些痛苦，那么，是时候考虑微服务了。