微服务架构
经典架构模式
把应用拆成可独立部署的小服务，服务围绕业务能力、通过网络协作。
结构示意
flowchart TB
G[API 网关]
G --> U[用户服务]
G --> O[订单服务]
G --> P[支付服务]
O --> MQ[消息]
P --> MQ
知识说明
微服务强调：按业务边界拆分、独立进程与数据、独立发布。好处是团队自治、弹性扩缩、技术异构。代价是分布式事务、网络故障、运维与可观测性成本。
它常与 API 网关、服务发现、容器编排一起出现，但「拆成很多 JAR」本身不是微服务——没有独立部署与清晰边界只是分布式单体。
对比单体分层：不是替代分层，每个微服务内部仍常采用分层/MVC。
特点
- 独立部署
- 围绕业务能力
- 去中心化数据
- 轻量通信（HTTP/消息）
优点
- 故障隔离
- 按服务扩容
- 技术栈可并存
局限
- 分布式复杂度
- 数据一致性难
- 运维与测试成本高
适用
大型电商 多团队并行的平台型系统
例子展示 —— 电商：订单与库存拆分
问题
单体里下单、库存、支付同一数据库事务；流量高峰时只能整站扩容，库存团队发版会拖住交易团队。
做法
订单服务与库存服务分开部署、分开库。下单通过接口或消息扣减库存，接受最终一致，并用超时与补偿处理失败。
sequenceDiagram
participant App as 客户端
participant Ord as 订单服务
participant Inv as 库存服务
App->>Ord: 下单
Ord->>Inv: 预留库存
Inv-->>Ord: OK
Ord-->>App: 下单成功
// 订单服务
class OrderService {
InventoryClient inventory;
public String place(Order o) {
inventory.reserve(o.sku, o.qty);
return save(o);
}
}
// 库存服务独立进程
class InventoryController {
@PostMapping("/reserve")
public void reserve(String sku, int qty) { /* 本库扣减 */ }
}# 订单服务调用库存 HTTP API
import requests
def place_order(order, inventory_url):
r = requests.post(inventory_url + "/reserve", json=order)
r.raise_for_status()
save_order(order)