2. 单体架构的痛点：传统单体系统的耦合问题、维护成本高、扩展性差、典型故障场景分析

在深入探讨模块边界拆分之前，必须首先理解我们为什么要拆分。传统单体架构（Monolithic Architecture）在业务初期具有开发简单、部署便捷的优势，但随着业务规模的增长，其固有的结构性缺陷会逐渐演变为制约企业数字化的核心瓶颈。本节将从耦合、维护、扩展及故障四个维度，系统剖析单体架构的痛点。

2.1 耦合问题：牵一发而动全身

单体架构最根本的问题在于代码耦合与数据耦合。所有业务逻辑（订单、支付、库存、用户）运行在同一个进程内，共享同一个数据库实例。这种架构导致模块之间的依赖关系错综复杂，形成“大泥球”（Big Ball of Mud）。

下表对比了单体架构中常见的耦合类型及其具体表现：

2.2 维护成本高：技术债务的雪崩

随着业务迭代，单体系统的代码库会迅速膨胀。一个中型企业级单体项目，代码行数（LOC）通常在 50 万至 200 万行之间。维护如此庞大的代码库，面临以下具体挑战：

• 构建时间过长： 一次全量编译可能耗时 10-30 分钟，严重拖累开发效率。
• IDE 性能瓶颈： 大型单体项目会导致 IDE 索引卡顿、代码提示延迟，开发者体验极差。
• 回归测试范围失控： 任何代码变更都需要执行全量回归测试，测试周期从小时级延长到天级。
• 人员 onboarding 困难： 新成员需要理解整个业务上下文才能安全修改代码，上手周期通常超过 3 个月。
• 技术栈锁定： 一旦选择 Java + Spring + Oracle，很难局部引入 Go、Node.js 或新的数据存储技术。

2.3 扩展性差：无法弹性应对业务压力

单体架构的扩展方式只有一种：垂直扩展（Scale Up）或全量水平扩展（Scale Out）。这两种方式都存在明显的局限性。

在典型的电商场景中，订单创建和库存扣减是高频热点操作，而用户注册和报表生成的访问频率则低得多。单体架构无法针对热点模块单独扩容，只能整体扩容，导致计算资源利用率低下。

2.4 典型故障场景分析

单体架构的故障具有放大效应和全局影响。以下三个场景是生产环境中最为常见的故障模式：

场景一：内存泄漏导致全站瘫痪

报表模块的导出功能存在未关闭的数据库连接或大对象引用，导致 JVM 堆内存持续增长。当内存溢出（OOM）发生时，整个应用进程崩溃，所有业务（订单、支付、登录）全部中断。运维团队即使定位到问题模块，也无法单独重启报表功能，必须全量重启应用。

场景二：慢 SQL 拖垮所有接口

库存模块的一个复杂统计查询未命中索引，执行耗时从 200ms 飙升到 15 秒。由于所有模块共享同一个数据库连接池，该慢查询占用了大量连接，导致订单提交、用户登录等核心接口因获取不到数据库连接而超时失败。最终表现为“系统不可用”。

场景三：发布变更引发连锁故障

开发团队修复了支付模块的一个 Bug，但在代码合并时意外修改了订单模块共享的公共工具类。上线后，订单模块的序列化逻辑出错，导致所有订单创建接口返回 500 错误。由于无法单独回滚支付模块的变更，团队只能执行全量回滚，导致支付 Bug 修复也被撤销。

2.5 痛点总结与架构演进方向

综合以上分析，单体架构的四大痛点可以归纳为下表：