1
原单体应用
2
├── 用户模块 (user-service)
3
├── 订单模块 (order-service)
4
├── 支付模块 (payment-service)
5
├── 商品模块 (product-service)
6
└── 通知模块 (notification-service)

1
第一步：拆离独立的边缘服务（通知、文件）
2
第二步：拆离业务复杂度高的核心服务（订单、支付）
3
第三步：处理共享代码（用户、配置）

1
// ❌ 拆分太细，创建了大量微服务
2
user-service      // 用户管理
3
user-auth-service // 用户认证
4
user-profile-service // 用户资料
5
// 结果：维护成本爆炸
6

7
// ✅ 按业务能力拆分
8
user-service     // 用户+认证+资料 一个服务
9
order-service    // 订单相关

1
// ❌ 没有考虑分布式事务
2
orderService.create(order);
3
paymentService.pay(orderId, amount);
4
inventoryService.deduct(productId, quantity);
5
// 其中任何一个失败都会导致数据不一致
6

7
// ✅ 使用 Saga 模式
8
@Saga(choreography = true)
9
public void createOrder(Order order) {
10
    orderService.create(order);
11
    // 本地事务成功，发消息
12
    eventBus.publish("order.created", order);
13
}

1
# ❌ 使用 HTTP 直连，IP 硬编码
2
http://192.168.1.100:8080/api/orders
3

4
# ✅ 使用服务发现
5
http://order-service/api/orders
6
# Spring Cloud: 使用 Ribbon/Feign 自动负载均衡

1
// 必须引入链路追踪，否则排查问题如同大海捞针
2
// 推荐：SkyWalking / Jaeger / Zipkin
3

4
// MDC 传递 TraceId
5
MDC.put("traceId", UUID.randomUUID().toString());

1
-- 每个微服务有独立的数据库
2
user-service    -> user_db
3
order-service   -> order_db
4
product-service -> product_db

1
阶段1: 斯特拉斯堡阶段（Strangler）
2
├── 保留单体应用
3
├── 新功能用新服务
4
├── 逐步迁移旧功能
5

6
阶段2: 绞杀榕阶段（Strangler Fig）
7
└── 单体应用逐渐缩小，最终移除

1
├── 统一配置中心 (Nacos/Apollo)
2
├── 服务注册发现 (Nacos/Consul)
3
├── 统一网关 (Spring Cloud Gateway)
4
├── 链路追踪 (SkyWalking)
5
├── 日志聚合 (ELK)
6
└── 熔断限流 (Sentinel/Hystrix)