#单体架构时代

2009 年，一家拥有 200 名员工的传统零售企业决定上线自己的电商平台。技术团队 8 人，项目周期 6 个月。

他们选择了当时最主流的架构模式：一个 Java Spring MVC 应用，连接一个 Oracle 数据库，所有业务逻辑在一个 WAR 包里。代码量最终稳定在 15 万行。

这套系统跑了很多年。即使后来公司业务翻了三倍，即使团队扩张到了 30 人，这套单体系统依然稳定运行。直到有一天，团队想把它拆成微服务，才发现：拆，比想象中难太多。

这个故事告诉我们：单体架构没有那么不堪，微服务也不是万能解药。在批评单体架构之前，先理解它的全貌。

#什么是单体架构

单体架构（Monolithic Architecture）是一种将所有功能模块打包在同一个进程中的软件架构模式。所有代码共享同一个代码库，编译成单一部署单元，运行在同一个应用服务器上。

┌─────────────────────────────────────────────────────────┐
│                     单体应用                             │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐   │
│  │ 用户模块 │  │ 商品模块 │  │ 订单模块 │  │ 支付模块 │   │
│  │ (注册)   │  │ (上架)   │  │ (创建)   │  │ (充值)   │   │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘   │
│       │            │            │            │         │
│  ┌────┴────────────┴────────────┴────────────┴────┐   │
│  │                   共享数据层                    │   │
│  └─────────────────────────┬───────────────────────┘   │
│                            │                           │
│  ┌─────────────────────────┴───────────────────────┐   │
│  │                    Oracle/MySQL                  │   │
│  └──────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

#核心特征

代码组织：所有模块在同一代码库中，通过包（package）或命名空间划分边界。以 Java 为例：

// 典型的单体项目结构
com.example.ecommerce
├── controller/          // 控制层（处理 HTTP 请求）
│   ├── UserController.java
│   ├── ProductController.java
│   └── OrderController.java
├── service/             // 服务层（业务逻辑）
│   ├── UserService.java
│   ├── ProductService.java
│   └── OrderService.java
├── repository/          // 数据访问层
│   ├── UserRepository.java
│   └── OrderRepository.java
├── model/               // 实体模型
│   ├── User.java
│   ├── Product.java
│   └── Order.java
└── config/              // 配置类
    └── AppConfig.java

部署模式：整个应用编译成一个 WAR 或 JAR 文件，部署到单个应用服务器（如 Tomcat、JBoss）。如果想扩容，只能复制整个应用。

数据管理：所有模块共享同一个数据库实例，通过表来区分不同业务域的数据。

#单体架构的优势

#开发效率高

在项目初期，单体架构的开发效率是最高的。团队规模小（5~10 人）时，所有人在同一个代码库里协作，代码共享和复用非常方便。一个新人 clone 代码后，几分钟就能本地跑起来。

# 单体项目的启动流程
git clone https://github.com/company/ecommerce.git
cd ecommerce
mvn clean package
java -jar target/ecommerce.jar
# 完成，整个应用启动

微服务项目则需要：克隆主仓库、克隆每个依赖的服务仓库、启动依赖服务、配置服务间网络。每个步骤都可能出问题。

#事务一致性有保障

单体应用中，所有业务操作在同一个数据库事务里完成。要么全部成功，要么全部回滚。不存在分布式事务的复杂性。

// 单体架构：本地事务保证一致性
@Service
public class OrderService {
    @Autowired private OrderRepository orderRepository;
    @Autowired private InventoryService inventoryService;

    @Transactional
    public void createOrder(Order order) {
        // 扣减库存（在同一个事务中）
        inventoryService.decreaseStock(order.getProductId(), order.getQuantity());

        // 创建订单（在同一个事务中）
        orderRepository.save(order);

        // 任何一个操作失败，整个事务回滚
    }
}

分布式系统里，一个跨服务的操作可能涉及多个数据库。任何一个环节失败，都需要额外的补偿机制来处理。这种复杂性，在单体架构中完全不存在。

#调试简单

在单体应用中，一个 HTTP 请求从入口到数据库，从头到尾都在同一个进程里。断点调试、中间件日志、请求链路追踪，都非常简单。

# 单体应用调试：只需关注一个进程
# 日志文件：catalina.out
# 线程栈：一个进程的所有线程
# 数据库连接：一个连接池

微服务架构中，一次请求可能跨越 5~10 个服务。要追踪一个 Bug，需要从 API 网关开始，一个个服务往下查日志。分布式追踪工具（Jaeger、Zipkin）虽然能帮助定位，但学习和维护成本不低。

#性能开销小

进程内调用没有网络开销，没有序列化/反序列化开销，没有额外的内存消耗。对于中小型系统，单体架构的吞吐量往往更高。

#单体架构的局限

#扩展性受限

单体应用的扩容方式只能是垂直扩容（换更大的机器）或水平扩容（复制整个应用）。当某个模块成为瓶颈时，无法只扩容那个模块。

场景：商品搜索模块是瓶颈

单体架构：
┌──────────────────────────────────────┐
│         应用实例 1（完整复制）          │
│  [用户] [商品] [订单] [搜索]           │
└──────────────────────────────────────┘
┌──────────────────────────────────────┐
│         应用实例 2（完整复制）          │
│  [用户] [商品] [订单] [搜索]           │
└──────────────────────────────────────┘
# 问题：用户、订单模块被复制了两次，但它们不需要扩容

微服务可以按需扩容：只扩容搜索服务，不需要复制其他模块。

#技术锁定

当团队想引入新技术时，单体架构的改造成本很高。比如想把某模块从 Java 换成 Go，需要重写整个模块，然后和其他模块一起重新部署。这意味着整个系统的稳定性都绑在一起了。

技术选型受限场景：

# 某团队想在单体架构中引入 Python 机器学习模块
# 问题：
# 1. 如何让 Python 模块和 Java 主应用交互？
# 2. 如何保证两个不同语言进程的部署一致性？
# 3. 如何统一管理两套完全不同的依赖？

微服务可以通过暴露 API 来集成异构技术栈，每个服务可以用最合适的技术实现。

#团队协作瓶颈

当团队规模超过 10 人时，单体代码库的协作成本急剧上升。代码冲突、集成测试时间、发布协调，都会成为效率瓶颈。

协作瓶颈数据（某团队实测）：

| 团队规模 | 代码冲突频率 | 集成测试时间 | 发布协调耗时 |
| --- | --- | --- | --- |
| 5 人 | 每天 2~3 次 | 15 分钟 | 几乎不需要 |
| 15 人 | 每天 10+ 次 | 1.5 小时 | 每次发布 2 小时 |
| 30 人 | 几乎每小时 | 3+ 小时 | 每次发布 1 天 |

#故障影响范围大

单体应用中任何一个模块的问题，都可能拖垮整个应用。一个内存泄漏、一条慢查询、一个死循环，可能导致整个服务不可用。

#真实案例：某传统企业电商平台的困境

以下案例来自 2016 年某中型零售企业的真实经历（已脱敏）：

背景：公司从线下零售转型电商，技术团队 8 人，上线了一个 Java 单体电商系统，代码量 20 万行，稳定运行了 4 年。

问题爆发：2015 年双十一，平台当天 GMV 突破 1000 万。但随后暴露出几个问题：

1. 发布风险极高。任何代码改动都需要发布整个系统。有一次，开发人员修改了商品搜索的 SQL 索引，导致整个网站的响应时间从 50ms 飙升到 3 秒，持续了 45 分钟才发现问题。

2. 团队协作困难。代码库里有 8 个开发者在同时修改，经常出现「提交代码后不知道会不会影响别人」的情况。每周五下午的发布窗口，是所有人最紧张的时刻。

3. 扩容效率低。双十一期间需要扩容，但只能复制整个应用。4 个实例运行一天，云账单比平时多了 3 倍。

教训：这家企业的 CTO 后来反思：「我们的问题不是架构选错了，而是业务增长超出了架构的承载能力。如果能早点做容量规划，早点引入灰度发布和监控告警，单体架构其实可以再撑两年。」

#反模式警示：什么情况下单体反而更好

很多人觉得单体架构是「落后」的代名词，恨不得第一天就上微服务。但现实中，有大量场景单体架构反而是最佳选择。

#小团队（5 人以下）

如果团队只有 5 个人，代码量在 5 万行以内，根本没有必要上微服务。这个阶段的瓶颈是「如何快速开发」，而不是「如何大规模协作」。微服务带来的运维复杂度和团队协作成本，是小团队无法承受的负担。

#业务边界不清晰

DDD 建模还没做完，不知道业务边界在哪里。这时候拆分微服务，大概率会拆错边界。拆错了再合并，代价比不拆还大。

#资金和人力有限

微服务需要配套基础设施：Kubernetes、CI/CD、监控、日志、服务治理。这些都需要投入。一个月薪 2 万的 DevOps 工程师，一年就是 24 万。如果预算有限，单体架构是更务实的选择。

#业务逻辑简单

如果系统只是做 CRUD，没有复杂的业务逻辑、分布式计算、高并发需求，单体架构完全够用。一个博客系统、一个内部工具、一个简单的管理后台，完全不需要微服务。

#总结

单体架构不是落后的代名词，它是一种适合特定阶段的架构模式。它的优势在于简单、高效、易调试，适合业务初期和小规模团队。它的局限在于扩展性受限、技术锁定、协作成本高，适合业务复杂后需要解决的问题。

理解单体架构的适用场景，才能判断什么时候该坚持，什么时候该演进。下一节，我们来看企业级架构的第一次尝试：SOA 面向服务架构。

#思考题

问题 1：某创业公司在 A 轮融资前使用单体架构快速迭代，B 轮融资后计划扩展团队规模到 50 人。这时候应该立即拆分微服务吗？

问题 2：单体架构中，团队如何在不拆分的情况下改善协作效率？

问题 3：如果单体架构的某个模块成为性能瓶颈，团队没有资源做微服务拆分，应该怎么办？