单体 vs 微服务
约 758 字大约 3 分钟
布欧-Lewyon
2026-05-15
首页 › Spring Cloud › 微服务基础
单体架构
所有功能模块在一个进程中运行，打包为单一部署单元。
单体架构的问题
| 问题 | 说明 |
|---|---|
| 耦合严重 | 改一行代码需要整个应用重新部署 |
| 扩展困难 | 只能整体扩展，无法针对热点服务单独扩容 |
| 技术绑定 | 所有模块只能用同一套技术栈 |
| 发布风险 | 一个小模块的 Bug 可能导致整个系统宕机 |
| 团队协作 | 多个团队修改同一代码库，冲突频繁 |
微服务架构
每个服务独立部署、独立扩展、独立技术栈，服务间通过轻量通信（HTTP/RPC）协作。
微服务的优势
| 优势 | 说明 |
|---|---|
| 独立部署 | 每个服务可独立发布，不影响其他服务 |
| 技术多样性 | 不同服务可用不同的语言和数据库 |
| 独立扩展 | 只扩容热点服务，成本更低 |
| 故障隔离 | 一个服务宕机不影响全局 |
| 团队自治 | 小团队负责小服务，效率更高 |
微服务面临的挑战
这些挑战正是 Spring Cloud 要解决的问题。
拆分原则
// 按业务能力拆分（推荐）
user-service // 用户服务
product-service // 商品服务
order-service // 订单服务
payment-service // 支付服务
notification-service // 通知服务
// 按领域驱动设计（DDD Bounded Context）
// 每个限界上下文对应一个服务| 原则 | 说明 |
|---|---|
| 高内聚低耦合 | 一个服务内强关联，服务间松耦合 |
| 按业务拆分 | 用户/订单/商品，而非按层拆分 |
| 数据独立 | 每个服务拥有自己的数据库 |
| 服务大小 | 2 周内可独立重写的规模 |
小结
- 单体架构：所有功能一个进程，简单但耦合严重。
- 微服务：每个功能独立进程，独立部署和扩展。
- 微服务优势：独立部署、故障隔离、技术多样性。
- 微服务挑战：服务发现、配置管理、网关、链路追踪、容错。
- Spring Cloud 提供了一整套解决方案应对上述挑战。