秒杀场景下订单中心的架构设计

不管是普通场景的下单,还是秒杀场景的下单,对订单中心来说,都是下单,关键是要能支撑秒杀瞬间大量的下单请求 。本文探讨一下通用的订单中心架构,主要从服务划分、下单请求处理流程、核心表分库等方面来介绍,不区分普通下单还是秒杀下单,系统架构设计做好了,有秒杀活动时,无非进行一些扩容、限流、降级等手段即可应对 。
服务划分

秒杀场景下订单中心的架构设计

文章插图
 
服务说明我不希望整个订单中心就是一个巨大的单体服务,也不希望是太细的微服务,我希望订单中心是合理的“中服务”的组合 。
可针对不同场景对服务进行扩容,比如订单搜索请求量比较大,就适当增加订单搜索服务的实例数量;消费速度慢,可针对订单消费者服务进行优化,调整服务实例数量 。
上面划分的每一个服务都是独立部署运行的服务 。
服务
说明
order-core(订单核心服务)
负责订单的业务处理,直接和 DB 交互
order-search(订单搜索服务)
负责订单索引的维护和搜索,直接和 ES 交互
order-job(订单调度服务)
订单超时取消等调度任务
order-consumer(订单消费者服务)
消费订单相关消息,如下单消息、订单索引更新消息
order-manage(订单管理后台系统)
订单管理后台,数据来源于 ES 和从库
应用架构图
秒杀场景下订单中心的架构设计

文章插图
 
服务调用关系图提交订单服务调用关系:
  1. 链路 1.1 ~ 1.3 提交订单
  2. 链路 2.1 ~ 2.4 消费下单消息(下单业务处理)
  3. 链路 3.1 ~ 3.2 查询下单结果
  4. BFF(小程序的后端,负责聚合和适配)

秒杀场景下订单中心的架构设计

文章插图
 
后台服务调用关系:
  1. 后台连接独立的专有读库,与前台隔离,不能因为后台的查询影响前台的操作
  2. 后台的订单查询可以调用搜索服务和读库来完成
  3. 后台的增删改操作调用 order-core(订单核心服务)进行操作,不能直接操作数据库

秒杀场景下订单中心的架构设计

文章插图
 
订单搜索或查看订单详情服务调用关系:
秒杀场景下订单中心的架构设计

文章插图
 
  1. 订单列表或者搜索订单可以调 order-search(订单搜索服务)来完成
  2. 在订单列表店家订单明细,可以根据订单号由 order-core(订单核心服务)查询从库来完成
订单调度服务调用关系:
秒杀场景下订单中心的架构设计

文章插图
 
  1. 订单调度服务查询专有的读库
  2. 写操作调用 order-core(订单核心服务)查询来完成
下单流程下单请求通过 MQ 异步化处理,下单处理结果存入 redis,前端轮询下单结果 。
秒杀场景下订单中心的架构设计

文章插图
【秒杀场景下订单中心的架构设计】 
步骤说明步骤 1:提交订单说明
  1. order-core(订单核心服务)提供提交订单接口(/order/submit)
  2. 这个接口接收订单相关的参数,如商品 id、价格、数量等
  3. 接收到请求后,做好基本参数校验
  4. 生成唯一的订单号,组装基本的订单信息
  5. 将订单号和订单创建中状态存入 Redis
  6. 发送 MQ,然后将订单号返回给前端
步骤 2:消费下单请求说明
  1. order-consumer(订单消费者服务)获取到下单请求消息后,调库存中心接口进行库存预占
  2. 如果库存不足,预占失败,则将订单创建失败状态和失败信息更新到 Redis,流程终止
  3. 如果库存充足,预占成功,则将订单创建成功状态更新到 Redis
  4. 调用 order-core(订单核心服务)保存订单信息到数据库,调用 order-search(订单搜索服务)对订单进行索引
  5. 发送创建订单结果消息,库存中心根据创单结果消息进行库存扣减或者释放


    推荐阅读