电商整体架构

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

重复功能建设和维护带来的重复投资
烟囱式建设造成系统壁垒，数据孤岛
业务沉淀促进可持续发展
大中台小前台快速响应市场的需要

上层业务：大中台，小前台，电商中直面用户的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），并设置过期时间。
被动取消:在每次用户查询订单的时候，判断订单时间，超时则同时完成订单取消业务