Creates structured ADRs for te…

# ADR：订单服务拆分独立微服务架构决策

一、背景与问题

• 当前订单功能与商品、库存、支付等模块耦合在同一单体应用中，发布相互影响、故障波及面大。
• 订单为流量高峰敏感模块（峰值约5000 QPS），单体扩容粒度粗、资源浪费明显。
• 促销大促场景下，下游（积分、通知、物流）处理慢会拖垮下单主链路。

二、决策内容

1. 订单服务拆分为独立微服务

• 独立代码库、独立部署、独立数据库（订单库单独拆出）。
• 通过 ACK 的 HPA 依据 CPU/QPS 指标弹性扩缩容。

2. 引入 Kafka 做异步解耦

• 订单创建成功后发送事件至 Kafka，下游服务（库存扣减确认、积分、通知、BI 等）订阅消费。
• 下单主链路只保留强一致操作，弱依赖全部异步化。

3. 部署于阿里云 ACK

• 使用 ACK 托管版集群，Kafka 优先选用阿里云消息队列 Kafka 版（托管运维），降低自建成本。

三、关键设计要点

• 削峰与可靠性：Kafka 缓冲瞬时流量，生产端开启幂等与确认机制，消费端幂等处理（基于订单号去重）。
• 顺序与分区：按订单ID作分区键，保证同一订单消息有序。
• 兜底方案：本地消息表 + 事务消息模式，确保订单落库与消息发送的最终一致。
• 容量预估：5000 QPS 对应 Kafka 峰值写入约数万 msg/s 量级，规划分区数与消费者实例数预留一定余量。

四、备选方案对比

• 继续单体 + 熔断降级：改动小，但无法独立扩容，不满足大促弹性需求。
• RocketMQ 替代 Kafka：事务消息能力更原生，团队若已有 RocketMQ 经验可复议；本项目以 Kafka 生态与团队熟悉度为优先。

五、风险与对策

• 引入消息中间件后排查链路复杂 → 接入链路追踪与消息轨迹。
• 双写/拆库期间数据不一致 → 采用灰度切流 + 对账任务兜底。

六、状态

• 状态：已采纳；复审周期：大促后复盘一次。