2. 单体架构的困境
在业务系统架构演进中，单体架构（Monolithic Architecture）是最早被广泛采用的模式。它将所有功能模块——用户管理、订单处理、支付、库存、报表——打包在同一个进程、同一个部署单元中。这种“大一统”模式在团队规模小、业务逻辑简单的阶段极具效率，但随着业务增长和团队扩张，其结构性缺陷会逐渐暴露，成为制约研发效能和系统稳定性的核心瓶颈。
单体应用的典型结构
单体应用在逻辑上通常采用分层架构，但在物理部署上只有一个可执行文件或容器。其典型结构如下：
典型分层结构：
- 表示层（UI）：Web 页面、REST API 端点，负责用户交互。
- 业务逻辑层（Service）：核心业务规则、工作流编排，如订单校验、库存扣减。
- 数据访问层（DAO/Repository）：与数据库交互，执行 CRUD 操作。
- 数据存储层（DB）：共享的单一关系型数据库（如 MySQL、PostgreSQL）。
这种结构在代码层面表现为一个巨大的代码仓库（Monorepo），所有模块在同一个进程内通过方法调用通信，共享同一个数据库连接和事务上下文。部署时，整个应用被打包为一个 WAR/JAR 文件或容器镜像，启动一个进程即可运行所有功能。
核心痛点：耦合、部署与故障爆炸半径
当业务复杂度上升，单体架构的三大痛点会迅速放大，直接拖累研发效率和系统可用性。
| 痛点维度 | 具体表现 | 典型后果 |
|---|---|---|
| 代码耦合 | 模块间通过共享内存、全局变量、静态方法直接依赖；数据库表被多个模块直接读写，缺乏边界。 | 修改一个模块需要回归测试整个系统；新功能难以独立开发，频繁出现“改一处崩全局”。 |
| 部署困难 | 任何微小变更都需要构建、打包、部署整个应用；启动时间长（分钟级），回滚成本高。 | 发布频率低（周/月级），无法快速响应业务需求；部署窗口期长，影响团队交付节奏。 |
| 故障爆炸半径大 | 一个模块的内存泄漏、死循环或异常会拖垮整个进程；CPU/内存资源被某个功能耗尽，导致所有服务不可用。 | 故障影响范围覆盖全部用户；定位根因困难，因为错误可能发生在任何模块；恢复手段只有重启整个进程。 |
故障爆炸半径案例：某电商平台在促销期间，报表模块因生成复杂统计报表消耗大量内存，触发 Full GC 导致整个应用停顿。结果不仅报表不可用，用户登录、商品浏览、下单支付等核心链路全部中断，故障恢复耗时 20 分钟，直接损失数百万 GMV。
何时需要拆分：从“大一统”走向“微服务”的决策信号
并非所有单体架构都需要立即拆分。过早拆分会引入分布式复杂性（网络延迟、数据一致性、服务治理），反而降低效率。以下信号表明拆分时机已经成熟：
- 团队规模与协作冲突：超过 2 个团队（约 15-20 人）在同一个代码库中频繁合并冲突；每次发布需要多个团队协调排期。
- 部署频率瓶颈：部署周期超过 1 周，且每次部署涉及大量模块变更；启动时间超过 5 分钟。
- 故障隔离失效：非核心功能（如报表、后台任务）的故障频繁导致核心业务（如支付、下单）不可用。
- 技术栈锁定：无法针对不同模块选择合适的技术栈（如用 Python 做 AI 推荐，用 Go 做高并发网关）。
- 资源扩展不均衡：某些模块需要更多 CPU/内存，但单体架构只能整体垂直扩展，造成资源浪费。
实践建议：拆分不是“全有或全无”的决策。推荐采用“绞杀者模式”（Strangler Fig Pattern），逐步将单体中的模块剥离为独立服务，同时保持新旧系统共存，直到单体完全被替代。优先拆分那些变更频繁、资源消耗独立、故障影响大的模块。
单体架构的困境本质上是“规模不经济”的体现。当系统复杂度超过团队管理能力时，模块边界拆分是必然选择。下一阶段，我们将深入探讨如何识别高内聚的业务边界，以及拆分后的服务间通信与数据一致性策略。