02 - 微服务到底是什么
上一章我们发现，单体的病根是”所有东西焊在一起”。药方也很直白：拆开。
一句话理解微服务
微服务（Microservices）= 把一个大应用，按业务拆成一组小的、能独立开发/独立部署/独立扩容的服务，它们各自管自己的数据，彼此通过网络接口协作。
关键词就三个：按业务拆、能独立跑、通过网络协作。
把电商拆开看看
还是上一章那个电商，用微服务的思路重新组织：
┌──────────────┐
请求进来 ───▶ │ （客户端） │
└──────┬───────┘
┌────────────┬────┴───┬────────────┐
▼ ▼ ▼ ▼
┌───────────┐ ┌──────────┐ ┌─────────┐ ┌──────────┐
│ 用户服务 │ │ 商品服务 │ │ 订单服务 │ │ 支付服务 │
│ (FastAPI) │ │(FastAPI) │ │(FastAPI)│ │(FastAPI) │
└─────┬─────┘ └────┬─────┘ └────┬────┘ └────┬─────┘
▼ ▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 用户库 │ │ 商品库 │ │ 订单库 │ │ 支付库 │
│(Postgres)│ │(Postgres)│ │(Postgres)│ │(Postgres)│
└─────────┘ └─────────┘ └─────────┘ └─────────┘
每个服务：自己的代码 + 自己的进程 + 自己的数据库，各管各的原来挤在一个项目里的四个模块，现在变成了四个独立的小应用。每一个都是一个完整的、能单独跑起来的 FastAPI 服务，还各自带一个数据库。
微服务的几个核心特征
判断一个东西”算不算微服务”，看这几点：
1. 围绕业务能力划分
按”业务”拆，不是按”技术”拆。是”用户 / 商品 / 订单 / 支付”这种业务块，而不是”数据库层 / 逻辑层 / 接口层”这种技术分层。
一个服务，最好能对应一个业务上说得清的东西：“这是管订单的”。
2. 独立部署（这是灵魂）
改了商品服务，就只重新部署商品服务，其他三个原地不动、照常运行。
这一条最重要。做不到独立部署，就不算真微服务。
3. 独立数据库
每个服务管自己的数据，别人不能直接伸手进你的库里查（第 05 章专门讲这个）。
4. 通过轻量接口通信
服务之间不再是”同一个进程里直接调函数”，而是通过网络互相请求——比如订单服务要拿用户信息，就发一个 HTTP 请求去问用户服务（第 04 章专门讲）。
一个常见误区：拆文件 ≠ 微服务
很多人以为”我把代码拆成很多文件夹、很多模块，就是微服务了”。不是。
❌ 只是把单体的代码分了文件夹
→ 还是一个进程、一个部署包、一个数据库
→ 改任何一块，还是要整体重新部署 → 这还是单体
✅ 真正的微服务
→ 每块是独立的进程、独立部署、独立的库
→ 改一块只重启那一块 → 这才是微服务微服务的关键不在”代码怎么分”，而在”能不能独立运行、独立部署”。
单体 vs 微服务 一图对比
单体架构 微服务架构
┌──────────────────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
│ 用户 商品 订单 支付 │ │用户│ │商品│ │订单│ │支付│
│ （一个进程） │ └─┬──┘ └─┬──┘ └─┬──┘ └─┬──┘
└────────┬─────────┘ ▼ ▼ ▼ ▼
▼ 独立进程 · 独立库 · 独立部署
一个大数据库
一起部署 / 一起崩 / 一起扩 各自部署 / 各自扩 / 互不拖累小结
- 微服务 = 把大应用按业务拆成一组能独立运行、独立部署的小服务，各管各的数据，通过网络协作。
- 核心特征：围绕业务划分、独立部署（灵魂）、独立数据库、轻量接口通信。
- 最大误区：拆文件夹不等于微服务，关键是能否独立部署。
- 但拆开之后，新问题也来了：它们怎么互相说话？数据一致性怎么办？——后面几章逐个解决。
上一章 ← 01 - 单体应用会遇到什么问题 ｜ 下一章 → 03 - 微服务解决了什么，又带来了什么 ｜ 回到 README 目录