微服务架构设计：从单体到分布式的演进

什么是微服务？

微服务架构将应用拆分为小型、独立的服务，每个服务：

• 运行在独立进程
• 通过轻量级协议通信
• 可独立部署和扩展
• 围绕业务能力组织

单体 vs 微服务

单体架构

优点:

• 开发简单
• 测试容易
• 部署方便

缺点:

• 代码耦合度高
• 扩展困难
• 技术栈受限

微服务架构

优点:

• 独立开发和部署
• 技术栈灵活
• 细粒度扩展

缺点:

• 分布式复杂性
• 数据一致性挑战
• 运维成本高

服务拆分原则

单一职责

每个服务只负责一个业务领域：

• 用户服务
• 订单服务
• 支付服务
• 库存服务

数据库分离

每个服务拥有独立数据库，避免耦合。

服务通信

同步通信（HTTP/REST）

// 用户服务调用订单服务
const order = await fetch("http://order-service/orders/123");

异步通信（消息队列）

// 发布事件
await kafka.send({
  topic: "order-created",
  messages: [{ value: JSON.stringify(order) }]
});

关键挑战与解决方案

服务发现

使用 Consul、Eureka 或 Kubernetes Service。

配置管理

使用 Spring Cloud Config 或 Apollo。

链路追踪

使用 Jaeger、Zipkin 追踪请求链路。

熔断降级

使用 Hystrix 或 Resilience4j 防止级联故障。

API 网关

统一入口，处理认证、限流、路由。

数据一致性

Saga 模式

通过一系列本地事务实现分布式事务：

// 创建订单 Saga
1. 创建订单（待支付）
2. 扣减库存
3. 创建支付记录
// 任何一步失败则执行补偿操作

事件溯源

记录所有状态变更事件，可重放重建状态。

微服务不是银弹，需要根据团队规模和业务复杂度谨慎选择。