写点什么

架构实战营 - 毕业设计

发布于: 5 小时前

1 业务分析

1.1 背景回顾

【业务背景】

设计 6.18 大促秒杀系统的设计,业务模式如下:

  1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售,每个品类不超过 20 个商品,目前做了 10 个品类

  2. 本次 6.18 秒杀选择了 1000 个充电宝,10 台 iPhone 12 作为秒杀商品;

  3. 正常的日活大约 100 万用户;

  4. 老板要求“万无一失”。

【技术背景】

  1. 技术团队以 Java 为主已经落地了微服务架构;

  2. 主要渠道是自有的 App(包括 iOS 和 Android)和微信小程序,为了促进用户转化为 App 用户,只有下载 App 才能参加秒杀活动

  3. 目前只有单机房

【业务量级分析】

  1. 秒杀商品仅为 200 种商品中的两种,考虑到充电宝为较为常用的商品,而 iPhone12 人气较高,活动时会有更多用户关注,需要预估部分余量。综合考虑,整个秒杀活动参与的用户大概在 日活 100 万 * 2 种商品 / 总计 200 种商品 * 10 预留参数 = 10 万左右

  2. 为应对用户在商品下单后不在规定时间内完成支付,导致最终实际有部分商品未售出的问题,可下单的商品数应略大于规划的总商品数(即允许一定程度的超售)。假设允许 10%的超售,则总计可下单的商品为:1100 个充电宝和 14 台 iPhone12。

1.2 场景分析

基于上述业务背景,待设计的秒杀系统可以分为以下几个基本场景:

  1. 秒杀商品查看:在秒杀开始前 5 分钟至秒杀结束后 5 分钟这 10 分钟内,会有大量用户刷秒杀商品页准备下单、查看秒杀结果;

  2. 秒杀商品下单:参加活动的 10 万用户对两种商品均进行抢购,则在秒杀开始直到秒杀结束的 2 分钟内,会有 20 万下单请求。实际需要下单的商品仅 1000 多件,因此需要在客户端进行请求拦截控制,假设最终 99%的请求因超过秒杀期限被客户端拦截,剩余 1%的请求进入服务端

  3. 秒杀订单支付:假设要求下单后 15 分钟内完成支付,下单后 15 分钟内,先完成支付的用户可实际购买成功,超过总库存规划量的订单在支付时会提示库存不足、订单转为购买失败

  4. 商品库存扣减:配合超售策略,商品库存扣减实际在订单支付成功后进行

剩余系统与秒杀业务关键流程关联性不强,可复用现有电商平台已有系统。

2 计算架构

2.1 性能估算

业务关键场景性能估算如下:

  1. 秒杀商品查看:按照参加活动每个用户在秒杀活动前后 10 分钟内平均每人请求 60 次估算,QPS 约为:10 万 * 60 / 600 秒 = 约 1 万/s;因为秒杀商品基础信息基本不会发生变化,可以通过客户端缓存拦截大部分请求,假设 99%的请求可以被客户端拦截,则实际服务端需要处理的 QPS 为:约 1000/s

  2. 秒杀商品下单:假设最终 99%的请求因超过秒杀期限被客户端拦截,剩余 1%的请求进入服务端,则下单 TPS 约为:2000 / 120 秒 = 约 20/s

  3. 秒杀订单支付:按照秒杀商品下单量级分析,支付操作对应总计约 2000 笔订单,因此订单支付的 TPS 为:2000 / (15 * 60 秒 ) = 约 3 / s

  4. 商品库存扣减:商品库存扣减实际在订单支付成功后进行,由此分析商品库存扣减 TPS 与订单支付场景 一致,约 3/s

2.2 架构设计

秒杀系统的负载均衡及缓存架构设计如下:

负载均衡架构


缓存架构


实施落地时,秒杀系统实际是基于已有电商系统进行构建,按照目前电商整体体量来看:

  1. 秒杀系统对缓存架构要求不高,因此可以完全沿用现有电商的缓存系统

  2. 100 万日活的电商负载均衡架构,可能已采用基于 LVS 的负载均衡架构。如果已采用 LVS,则可以完全沿用现有电商系统的负载均衡能力,无需额外进行部署;如果电商系统本身也是基于 Nginx 部署,可以视 Nginx 负载情况,考虑是否需要额外部署秒杀系统专用的 Nginx 实例,避免秒杀活动影响普通业务。

3 存储架构

3.1 性能估算

业务关键场景性能估算如下:

  1. 秒杀商品查看:参与秒杀的商品仅两件,且秒杀活动期间商品信息不会更改,可直接沿用原电商系统商品信息存储能力,秒杀系统的额外存储损耗可忽略不计;

  2. 秒杀商品下单:假设最终 99%的请求因超过秒杀期限被客户端拦截,剩余 1%的请求进入服务端,则需要存储的下单数据量约为:2000 笔 * 0.5KB/笔 = 约 1MB;

  3. 秒杀订单支付:按照秒杀商品下单量级分析,支付操作对应总计约 2000 笔订单,因此需要存储的支付数据量约为:2000 笔 * 0.5KB/笔 = 约 1MB;

  4. 商品库存扣减:仅涉及两件商品的库存扣减,假设除存储库存最终状态外,还需存储库存扣减记录备查,总共需要存储 1114 笔 * 0.1K/笔 = 约 100KB。

3.2 架构设计

针对秒杀系统本身,对存储架构的需求如下图所示:

存储架构


其中,考虑到秒杀系统对系统整体可用性的要求,MySQL 与 Redis 需具备主备自动切换能力。

而存储量本身,如 3.1 小节分析,因为参与用户数量及商品总量较少,存储量几乎可以忽略不计。

因为秒杀系统是在已有电商系统的基础上进行构建,从上述存储量、存储可用性及请求性能需求上看,直接沿用原电商系统的存储系统即可,无需额外再部署存储节点

4 其他架构

4.1 可扩展架构

秒杀系统涉及的微服务如下图所示:

服务划分


对现有电商系统而言:

  1. 上图中的微服务都应该已经实现

  2. 已经选定微服务框架(从现有业务情况来看采,不需要引入 RPC+百万量级,因此采用 Spring Cloud 更为合理),可直接复用现有的微服务框架

考虑到秒杀业务核心流程与电商通用业务流程一致,因此实际落地时需要修改优化的主要有以下几方面:

  1. 修改后台管理门户前端及对应的 BFF 服务,支撑秒杀活动管理

  2. 修改 APP 前端,添加秒杀倒计时、秒杀超时拦截、秒杀商品缓存逻辑

  3. 由 3.1 小节分析,秒杀业务对服务端性能要求其实不高,理论上直接复用现有业务服务不会对常规业务产生影响。但是如果现有服务负载已经很高,可以考虑增加对应服务的部署实例数量(例如:商品、交易服务新增额外的服务器节点)

4.2 高可用架构

由于秒杀活动时间短,秒杀系统的高可用更多依托于现有电商系统本身的高可用能力。

由于目前整个电商系统采用单机房部署,因此不具备灾备/多活能力。本次秒杀活动本身的体量不大,专门为秒杀系统构建灾备/多活架构成本太高。

针对老板提出的“万无一失”要求,可以尝试借此机会推进真个电商系统的同城灾备机房建设。(异地多活成本太高,可先实现同城灾备,后续逐步演进至异地多活)。

4.3 大数据架构

对秒杀结果的分析可借助大数据相关组件实现。

考虑到本次活动的商品种类及数量都不多,如果现有电商系统已使用大数据相关组件(例如 clickhouse),可直接复用其组件及分析流程。如果还没有引入,可以先通过线下手动导出数据分析的方式进行分析。


发布于: 5 小时前阅读数: 8
用户头像

还未添加个人签名 2017.12.17 加入

还未添加个人简介

评论

发布
暂无评论
架构实战营-毕业设计