实战-苏宁高时效、高并发秒杀业务中台的设计与实现

前言：

 文章主要介绍了苏宁架构设计背景，苏宁的架构设计以及系统多活部署与单机房宕机场景下的降级方案

设计背景

对于苏宁易购主站而言，正常的用户购物流程囊括选品、下单、库存扣减、付款、订单状态更新、物流履约等。但是在电商业务中往往会涉及到对某些热点商品的秒杀场景。相比于正常购物流程，秒杀场景具有时效性高、并发量大、瞬时业务量极高的业务特性，往往会出现显著的分布式一致性问题。正常的业务系统不能很好地应对瞬时高并发的业务需求，因此就需要针对于秒杀场景进行相应的架构优化，抑或是设计专门用于秒杀的中台业务系统。

就秒杀业务而言，系统在瞬时会达到极高的并发量，如果与其它业务耦合，那么势必会对其它业务造成风险，因此基于安全性考虑和业务隔离原则，秒杀系统在设计上应该与其它系统充分解耦，单独部署。本文将讨论在苏宁现有的技术架构和中台组件的基础上，如何去实现一个通用型秒杀业务中台。

架构设计

1. 系统前端与负载层设计

图一：前端与负载层设计

鉴于秒杀业务本身的高并发特性，对用户请求进行前端分流是必不可少的一步。在系统上游就对部分用户请求进行处理，可以避免海量请求对后端服务器产生过大压力。因为用户往往在秒杀前几分钟就开始点击下单按钮，因此在秒杀开始前可以使用静态资源页面，用户请求由 CDN 直接响应，不必到达后端服务器。

此外，由于秒杀业务的高时效性特征，下单窗口基本集中在秒杀开始后的几秒钟之内。因此我们可以在秒杀前某个时间点再将下单 URL 发送给前端。为了防止有人提前拿到下单 URL 进入支付流程，可以在 URL 中加入服务端生成的随机字符串，或者对下单请求进行时间校验，单就性能而言，前一种方案校验逻辑更少，性能更优。

在秒杀开始前，需要在商品秒杀页显示活动开始倒计时，其一般情况下直接调用用户本地时钟，因此就可能存在客户端与服务端时钟不一致的情况。因此在服务端需要提供定期授时接口将服务端时钟同步给客户端，为了节省带宽可以将时间戳信息优化压缩为尽可能短的 JSON 格式，去除掉不必要的信息，减轻网络带宽压力。

参与秒杀活动的商品一般数量稀少，注定只有少数用户能够进入下单支付流程，因此可以在负载层进行相应控制。下单接口可以在苏宁应用防火墙配置流量控制，当下单请求超过阀值后熔断下单接口。而对于那些被应用防火墙放行的下单请求，由 Ngnix 集群将流量均匀负载到后端应用服务器。在服务器内存中可以定义一个请求计数器，当某台服务器受理的下单请求超过阀值后，则该服务器不再受理用户的下单信息，直接返回给用户“活动已结束”页面。

2. 系统服务端设计

（1）系统服务端纵向拆分