Evaluates architecture and wri…

# 电商单体迁移微服务：拆分方案评估与决策记录

一、背景与现状评估

• 日订单峰值3万单（约0.35 QPS均值，峰值估算在数十至数百QPS量级），属于中小规模业务
• 单体Spring Boot在此负载下性能通常不是瓶颈，迁移动机应重点核实：团队规模、部署冲突、迭代效率、故障隔离需求

二、是否需要拆分：关键判断

• 不建议全量微服务化的信号：团队小于10人、业务域边界模糊、无Kubernetes/DevOps基础设施
• 支持适度拆分的信号：订单、库存、支付等模块频繁互相阻塞发布；大促时无法独立扩容；代码库多人冲突严重
• 推荐结论：采用“渐进式拆分”而非一步到位

三、推荐拆分方案（按优先级）

1. 第一优先级：订单服务、库存服务（大促扩容核心，故障影响最大）

2. 第二优先级：支付/结算服务（合规与安全隔离需求强）

3. 第三优先级：商品、用户服务（读多写少，可加缓存优化）

4. 暂不拆分：营销、后台管理等低频模块，保留在单体中

四、技术选型建议

• 服务注册发现：Nacos 或 Consul
• 通信：OpenFeign + 熔断降级
• 网关：Spring Cloud Gateway
• 数据库：每服务独立库或独立Schema，严禁跨服务直连库表
• 事务：本地消息表/Seata，避免强一致分布式事务
• 部署：建议先上K8s，否则运维成本会抵消收益

五、决策记录（ADR）

• 决策日期：（填写实际日期）
• 决策状态：待评审 → 建议采纳
• 背景：日订单峰值3万单，单体架构在独立部署、弹性扩容、故障隔离上存在瓶颈
• 决策：采用绞杀者模式渐进拆分，优先拆订单、库存、支付三个核心服务，其余暂留单体
• 备选方案对比：
• 全量微服务化：改造成本高、团队学习曲线陡，否决
• 仅做模块化+独立部署：收益有限，作为过渡方案
• 风险与缓解：
• 分布式事务复杂度 → 优先最终一致性方案
• 链路排查困难 → 同步引入链路追踪
• 运维成本上升 → 先补齐CI/CD与监控再拆分
• 验证指标：核心接口发布周期缩短、大促扩容耗时下降、单服务故障不扩散

六、执行节奏建议

• 第一阶段（1-2个月）：基础设施搭建 + 订单服务拆出试点
• 第二阶段：库存、支付拆分，灰度切流
• 第三阶段：单体瘦身，视情况拆剩余模块

核心提醒：拆分是为了解决组织与迭代问题，不是为了技术炫技。3万单/日的体量下，拆3-5个核心服务即可，避免过度设计。