单体架构回顾：部署拓扑、服务边界模糊与数据流耦合

在进入分布式系统之前，有必要先厘清单体架构（Monolithic Architecture）的典型特征与核心痛点。单体架构并非“过时”的代名词，而是理解服务拆分必要性的最佳参照系。本节从部署拓扑、服务边界、数据流三个维度进行回顾。

2.1 单体应用的部署拓扑

单体架构将所有功能模块（用户管理、订单、支付、库存等）打包在同一个进程内，部署在单台或多台负载均衡后的服务器上。其部署拓扑结构清晰但缺乏弹性。

这种拓扑的优势在于：开发简单（IDE 单项目调试）、部署直接（单一制品）、测试容易（端到端测试无需跨进程）。但问题同样明显：所有实例共享同一个数据库，任何模块的数据库 schema 变更都可能影响全局。

2.2 服务边界模糊的问题

在单体应用中，服务边界并非显式定义，而是由代码模块（package、namespace）或团队职责隐式划分。这种模糊性在项目早期尚可接受，但随着业务增长，会引发以下问题：

2.3 数据流耦合的痛点

数据流耦合是单体架构最隐蔽、最具破坏力的痛点。它表现为数据在模块之间的传递方式缺乏契约约束，导致牵一发而动全身。

数据流耦合的具体痛点可归纳为以下四点：

1. Schema 变更扩散： 修改用户表的一个字段，需要同步修改订单、支付、物流等所有引用该表的模块代码。
2. 事务边界过大： 一个业务操作（如“下单支付”）可能跨多个模块，不得不使用分布式事务（XA/2PC），性能急剧下降。
3. 数据一致性脆弱： 缺乏模块级的数据校验，脏数据可能从一个模块流入另一个模块，排查困难。
4. 读写负载不隔离： 高频读操作（如商品列表）与低频写操作（如订单创建）共享同一数据库连接池，互相争抢资源。

2.4 单体架构的适用场景与转型信号

尽管存在上述痛点，单体架构在特定场景下仍然是合理选择：

• 团队规模 ≤ 10 人，沟通成本低，边界模糊问题不突出。
• 业务复杂度低，核心流程不超过 3～5 个模块。
• 快速原型验证，需要最短时间上线 MVP。
• 运维能力有限，无法支撑微服务所需的 CI/CD、容器编排、服务网格等基础设施。

当出现以下信号时，应考虑向微服务或模块化单体演进：