单体架构 vs 微服务架构
背景
在学习并发控制时，接触到"多实例部署"的概念，容易混淆"多实例"和"微服务"。这篇文章用 Bush/Jungle 项目来对比两种架构。
单体架构（Monolithic Architecture）
什么是单体架构？
所有功能模块在一个应用内，共享同一个数据库。
Bush/Jungle 项目结构：
┌────────────────────────────────────────┐
│ Jungle 后端应用 │
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │分类模块 │ │用户模块 │ │订单模块 │ │
│ └────────┘ └────────┘ └────────┘ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │库存模块 │ │支付模块 │ │物流模块 │ │
│ └────────┘ └────────┘ └────────┘ │
└────────────────┬───────────────────────┘
↓
┌──────────────┐
│ PostgreSQL │ ← 一个数据库
└──────────────┘
部署方式（多实例）：
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Jungle │ │ Jungle │ │ Jungle │ ← 3个容器
│ 实例 1 │ │ 实例 2 │ │ 实例 3 │
└────┬────┘ └────┬────┘ └────┬────┘
└────────┬────────┬─────────┘
↓ ↓
┌──────────────────┐
│ PostgreSQL │ ← 共享同一个数据库
└──────────────────┘微服务架构（Microservices Architecture）
什么是微服务？
按业务领域拆分成多个独立服务，各自数据库，通过 HTTP/RPC 通信。
改造 Bush/Jungle 成微服务：
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 分类服务 │ │ 用户服务 │ │ 订单服务 │ │ 库存服务 │
│ (Nest) │ │ (Nest) │ │ (Nest) │ │ (Go) │
│ :3001 │ │ :3002 │ │ :3003 │ │ :8080 │
└────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
↓ ↓ ↓ ↓
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│分类数据库 │ │用户数据库 │ │订单数据库 │ │库存数据库 │
│Postgres │ │Postgres │ │Postgres │ │ MySQL │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
↓ 通过 HTTP 调用 ↓
┌─────────────────────────┐
│ API 网关 (Nginx/Kong) │ ← 统一入口
└─────────────────────────┘
↓
┌─────────────────────────┐
│ 服务注册/发现 (Consul) │ ← 服务管理
└─────────────────────────┘业界案例
单体架构成功案例
GitHub（早期）
- 单体 Rails 应用支撑到百万级用户
- 后期才逐步拆分服务
StackOverflow
- 单体 ASP.NET 应用
- 月访问量 10 亿+
微服务架构案例
阿里巴巴
- 数千个微服务
- 双11 峰值数十万 QPS
- 自研 Dubbo、Seata、Nacos
美团
- 1000+ 微服务
- 多语言架构（Java、Go、Python）
总结
单体架构不是落后，微服务不是银弹。
选择的核心标准：
- 团队规模：能否维护微服务的复杂度？
- 业务复杂度：是否真的需要拆分？
- 技术储备：团队是否有微服务经验？
- 运维能力：是否有 DevOps 团队支撑？
对于大部分项目来说：
- 从单体开始 ✅
- 做好模块化设计 ✅
- 必要时再拆分 ✅
- 不要过早优化 ❌
记住：架构是演进的。