微服务架构演进历程
TIP
从单体架构到微服务架构，是一个逐步演进的过程。理解演进历程有助于做出合理的技术选型。
架构演进路径
单体架构 → 垂直拆分 → SOA → 微服务 → 服务网格单体架构
所有功能部署在同一个应用中。
优点：
- 开发简单，适合小团队
- 部署简单（一个 jar/war）
- 测试容易（端到端测试）
- 调用延迟低（进程内调用）
缺点：
- 代码耦合严重，难以维护
- 无法独立扩展某个功能
- 构建和部署时间长
- 技术栈锁定垂直拆分
按业务功能拆分为独立应用。
电商系统
├── 用户系统（独立部署）
├── 商品系统（独立部署）
├── 订单系统（独立部署）
└── 支付系统（独立部署）SOA（面向服务架构）
引入 ESB（企业服务总线）进行服务治理。
优点：服务可复用、标准化
缺点：ESB 成为瓶颈、维护成本高微服务架构
每个服务独立开发、部署、扩展。
java
// 微服务特征
// 1. 单一职责：每个服务只负责一个业务功能
// 2. 独立部署：服务可以独立部署和升级
// 3. 去中心化：每个服务可使用不同的技术栈
// 4. 自治性：拥有自己的数据库微服务与单体对比
| 维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 复杂度 | 低 | 高 |
| 扩展性 | 差 | 好 |
| 部署速度 | 慢 | 快 |
| 故障隔离 | 差（一挂全挂） | 好 |
| 运维成本 | 低 | 高 |
| 团队规模 | 小团队 | 多团队 |
服务网格（Service Mesh）
微服务架构的下一阶段进化
- Istio + Envoy 实现通信层下沉
- 业务代码无需关注服务治理
- 透明代理模式