电商大促架构体系

电商整体架构

从组织架构到技术架构,当前各大电商系统基本趋于中台化。中台在2015由阿里提出,其实是一种企业架构而不是单纯的技术层面,
目前几乎各大电商都进行着中台化的建设。中台就是对 ”共享“ 理念系统化的归纳和总结。

  • 重复功能建设和维护带来的重复投资
  • 烟囱式建设造成系统壁垒,数据孤岛
  • 业务沉淀促进可持续发展
  • 大中台小前台快速响应市场的需要
    电商大促架构体系_第1张图片
    上层业务:大中台,小前台,电商中直面用户的B2B,B2C等各个业务线
    业务中台:基于公共服务的沉淀,需要收敛一些基础的业务服务,如商品、订单、会员、库存、财务、结算等等。
    数据中台:数据中台不是一个平台,也不是一个系统。数据仓库、数据平台和数据中台是有区别的。简单的举例:
    数据平台可以理解为数据库,数据仓库类比为报表,而数据中台更贴近上层业务,带着业务属性。
    技术中台:与业务无关的基础沉淀,中间件,系统框架,监控,日志,集成部署等等
    运维中台:不一定存在,系统运维相关的内容,硬件,机房,包括企业云平台的建设等可以划分为单独的运维中台

面临问题

考量维度

  • 高性能:提供快速的访问体验
  • 高可用:网站服务7*24正常访问
  • 可伸缩:硬件弹性增加/减少能力(快速扩容与释放)
  • 扩展性:方便地增加/减少新的功能/模块(迭代与服务降级)
  • 安全性:安全访问和数据加密、安全存储等策略
  • 敏捷性:快速应对突发情况的能力(灾备等)

内部瓶颈

  • 木桶效应:水管最细的地方决定流量,水桶最低的地方决定容量(QPS压测调优为例)
  • CPU:序列化和反序列化、高频日志输出、大量反射、大量线程的应用
  • 内存:使用内存的中间件或服务,如redis,memcache,jvm大量对象堆积内存的应用等
  • 网络带宽:大流量高并发环境下,双11用户访问量激增,造成网络拥堵
  • 磁盘IO:文件上传下载,数据库频繁读写,不合理或大批量的日志输出
  • 数据库连接数:应对双11,应用服务器连接池大批扩容,警惕底层数据库、Redis等连接数瓶颈

外部服务

  • 短信:外部短信延迟与送达率问题,可以搭建短信平台,多家渠道做路由和切换分流(短信平台架构?)
  • 支付:银行支付与回调延迟,搭建支付中心,对接多支付渠道
  • 快递对接:快递服务对接(快递100)
  • 外部云存储:云存储文件访问,流量扩容(大家所使用的存储?nfs的架构与事故)
  • CDN:外部静态文件访问提速服务(使用过的项目?)

业务中台

订单中心

异步化:

大促期间新增许多需要获取订单状态的服务,比如应对双11而临时增加的数据中台订单大屏展示等;异步化,并对消息队列调优,多队列分流

过期订单:

扫表实现:通过定时任务轮询扫描订单表,超时的批量修改状态
java延迟队列实现:通过DelayQueue,每下一单,放入一个订单元素并实现getDelay()方法,方法返回该元素距离失效还
剩余的时间,当<=0时元素就失效,就可以从队列中获取到。启用线程池对数据监听,一旦捕获失效订
单,取出之后,调用取消逻辑进行处理。
消息队列实现:设置两个队列,每下一单放一条进延迟队列,设定过期时间。消息一旦过期,获取并放入工作队列,由
consumer获取,唤起超时处理逻辑
redis实现:利用redis的notify-keyspace-events,该选项默认为空,改为Ex开启过期事件,配置消息监听。每下一
单在redis中放置一个key(如订单id),并设置过期时间。
被动取消:在每次用户查询订单的时候,判断订单时间,超时则同时完成订单取消业务

支付中心

重复支付
异常订单:支付但未开单,未支付但已开单
回调延迟
支付路由

营销中心

价格分摊:满减或平台券等优惠,在多个商品下单时,涉及到金额的分摊。记账时在订单明细记录,将误差 金额 计入金额最大的明细
退单处理:退单后要同时恢复用户的权益,比如优惠券的再次使用,限购次数等。确保用户体验。

商品中心

限时商品的下架控制
库存管理

技术中台

数据库优化
缓存优化

你可能感兴趣的:(架构思想,java)