SpringCloud 微服务主流程

1. 所有微服务启动后把自己 IP + 端口注册到 Nacos。
2. 前端请求统一接入 Gateway网关  → 请求进入网关后首先被 Sentinel 拦截处理，（IP黑白名单过滤、路由权限校验、网关全局限流。）
3. 校验放行之后，网关Gateway 根据服务注册中心 Nacos/Eureka 的服务列表拉取服务实例，通过 LoadBalancer 选一台健康实例，自动做负载均衡转发。
4. 业务微服务需要跨服务调用时，通过 OpenFeign 发起跨服务调用。Feign 底层依赖 LoadBalancer 按照轮询 / 随机规则 选一台健康实例。

（调用频繁超时 / 报错 → Sentinel 触发熔断，熔断后 Feign 直接走 Fallback 降级，不卡死线程，LoadBalancer 自带健康探测，自动剔除故障、宕机、失联的微服务实例，后续流量只分发到正常节点。）

电商下单实战应用

1. 用户下单 → 2. 校验商品/价格 → 3. 扣减库存（Redis/DB） → 4. 创建订单 → 5. 订单状态流转（待支付 → 已支付 → 已发货） → 6. 超时未支付 → 自动取消订单 + 回滚库存

需要注意的坑：

1. 并发超卖

• 必须用 Redis 分布式锁
• 库存必须用 乐观锁

2. 重复下单

• 接口必须做 幂等性（token / 唯一订单号）
• 用户维度加锁

3. 订单创建了，库存没扣 / 库存扣了订单没创建

• 必须用 Seata 分布式事务 保证原子性

4. 超时取消不准时

• 必须用 消息队列延迟消息
• 不要用定时任务（不准、性能差）

5. 远程调用异常

• 必须用 Sentinel 熔断、降级、限流
• 调用失败不能产生脏数据

6. 高并发流量冲击

• 库存预热到 Redis
• 下单接口限流
• 使用 MQ 异步削峰

7. 订单状态错乱

• 状态机严格控制
• 只能正向流转，不能乱跳状态

订单全业务时序图