01 - 单体应用会遇到什么问题

你现在已经会用 FastAPI 写接口、用 PostgreSQL 存数据了。假设你要做一个电商系统，最自然的做法是：开一个项目，把所有功能都写进去。

电商系统（一个 FastAPI 项目）
├── 用户模块      （注册、登录、个人信息）
├── 商品模块      （商品列表、详情、库存）
├── 订单模块      （下单、查订单、取消）
└── 支付模块      （发起支付、支付回调）
        │
        ▼
   连同一个 PostgreSQL 数据库
        │
        ▼
   打成一个包，部署在一台服务器上

这种”所有功能挤在一个应用里”的架构，就叫单体应用（Monolith）。

单体一开始其实很爽

别急着嫌弃它。项目小的时候，单体是最优解：

• 开发简单：一个项目、一个代码库，想调哪个函数直接调
• 部署简单：打一个包，扔到服务器上跑起来就行
• 调试简单：所有代码在本地一跑，断点随便打

90% 的项目，一辈子用单体就够了。别人说微服务好，不代表你现在就需要。

但项目变大后，五个痛点开始冒出来

当你的电商越做越大、团队越来越多、用户越来越多，单体开始”力不从心”。

痛点 1：改一行代码，要重新部署整个系统

你只是想给”商品详情”加一个字段，结果：

• 必须把整个电商系统重新打包、重新部署
• 部署期间，用户、订单、支付全都跟着受影响

就想动一个小房间，却要把整栋楼断电重装。

痛点 2：一个模块出 bug，整个应用一起倒

支付模块有个内存泄漏，把进程搞崩了。结果呢？

• 不只是支付挂了
• 用户登录、浏览商品、查订单……全挂了

一荣俱荣，一损俱损。一个不重要的模块，能拖垮整个系统。

痛点 3：只有订单压力大，却要整个系统一起扩容

大促时，订单模块被挤爆了，但用户、商品模块其实很闲。你想只给订单加机器，可是：

• 单体是一个整体，加机器只能把整套系统复制一份
• 商品、用户那些不忙的模块也跟着白白多占资源

想给厨房多加个灶台，却被迫把整个餐厅（含大堂、洗手间）复制一份。扩容不精准，烧钱。

痛点 4：几十号人挤在一个代码库，天天打架

团队从 5 个人涨到 50 个人，全都往同一个项目里提交代码：

• 合并代码天天冲突
• 谁的改动出了问题，牵连一大片
• 想发布，得等所有人的功能都测好（大家互相等）

一条独木桥上挤了 50 个人，谁也走不快。

痛点 5：技术栈被焊死，想换换不了

整个项目用 Python 写死了。可”推荐模块”其实用 Go 性能会好很多，“AI 模块”想上某个只有别的语言支持的库——

• 对不起，单体是一个整体，要换一起换，动不了。

问题的本质：所有东西都被”焊”在了一起

把上面五个痛点串起来，会发现根子是同一个：

单体把所有功能强行绑成一个整体——一起开发、一起部署、一起扩容、一起崩溃。规模小的时候这是优点，规模大了就全变成缺点。

一个自然的念头冒出来了：

能不能把这个大应用，按业务拆成几个能各管各的小块？用户归用户、订单归订单，各自独立开发、独立部署、独立扩容，谁也别拖累谁。

这个念头，就是微服务的起点。下一章我们正式认识它。

小结

• 单体应用：所有功能挤在一个应用、一个代码库、一个部署包里。
• 项目小的时候，单体简单又高效，别盲目嫌弃。
• 项目大了会遇到五个痛点：改动牵一发动全身、一处崩全体崩、扩容不精准、协作困难、技术栈锁死。
• 本质：所有东西被”焊”在一起。解药是——按业务拆开。

下一章 → 02 - 微服务到底是什么 ｜ 回到 README 目录