苏宁易购11.11：商品详情系统架构设计

商品详情系统介绍

基本介绍

商品详情系统是一个展现商品基本信息、参数等详情的系统，是商品购买的入口。它是电商平台中访问量最大的系统之一，苏宁易购大促期间PV量和UV量很大，这么大的访问量对系统的并发能力要求高。在业务上它与周边系统的关系是高耦合。依赖商品详情系统的的系统特别多，好比：促销系统、推荐系统、大聚惠、等众多营销系统、还有主数据系统、购物车、收藏夹等，业务复杂度高对系统设计提出更多的要求。

业务特色

1. 重点在于数据展现
2. 页面信息丰富，如：商品详情、商家列表、推荐、排行榜等
3. 部分数据时效要求高，如：价格、库存等
4. 业务上依赖的系统多

商品详情系统三要素

1. 展现

产品上须要设计好页面区分展现的内容

技术上主要是页面缓存设计、前端页面模版和JAVA程序的解耦

2. 数据处理

数据所有来源于其它系统，在数据上分为：

基本数据，外部系统传过来直接就可使用的数据

聚合数据，须要加工才能使用的数据

3. 服务依赖

经过MQ解耦，异构数据

解决好以上三个问题就解决了此系统核心问题。

系统逻辑架构

商品详情系统在设计上分红前、中、后三层结构

1. 前台负责展现，作为VIEW层不处理业务逻辑，负责渲染。
2. 中台负责业务逻辑处理，提供数据给前台，同时还会对外部系统提供服务
3. 后台负责主数据管理，作为数据管理层处理商品主数据、参数、品牌、供应商等，同时部份内容开放给运营进行维护、管理和异常处理等。

前台设计

页面设计：

1. 动静分离

JavaScript、CSS统一放到公共的静态服务器上，彻底独立的子域名，防止脏Cookie问题和动态域名中无用Cookie问题，经过文件版本号解决系统新版和旧版本之间冲突问题。

全部图片由独立的分布式图片系统管理，对原图进行不一样规格的无损裁减和压缩。

2. 异步加载和懒加载

商品价格、营销活动信息、库存等动态数据经过异步加载

非首屏数据作懒加载处理，提升首屏加载时间，好比评价、商品详情等内容

3. 多级缓存策略

a. 浏览器本地缓存

协商缓存，对于某些时效要求较高的资源经过Last-modified控制数据。作到StatusCode=304

强缓存，JS、CSS等静态资源或者一些页面碎片伪静态数据经过Expires、Cache-Control(http1.1支持)设置作到强缓存，在不强制刷新的状况下能够作到200(from cache)

b. CDN缓存

CDN分两条线有自营CDN和合做商的CDN，图片、静态资源与伪静态数据分

别放在不到的CDN上

c. Varnish缓存

Varnish在设计上负载使用轮询方式，不使用URL HASH策略，用空间换时间的策略， 从而避免热数据问题，也支持横向扩展。

Varnish 缓存和CDN缓存在失效时间错开，从而避免同时失效回源压力过大。

d. 精准缓存

精准缓存失效用于促销活动准时展现的场景，基于Varnish缓存，经过精准控制缓存有效期实现缓存精准失效保证促销活动准时切换。

组件逻辑设计：

商品详情系统中的购买按钮和加入购物车会因商品不一样走不一样的流程。如：大聚惠商品、定金团商品、预售商品等因促销方式不一样，走不一样的业务处理流程。促销模式变化无穷，可能每月都会有变化，一般的面向接口编程和加上工厂方法或者依赖管理框架Spring也很难作到真正的解耦，虽然这样作已经符合开闭原则。咱们经过观察者模式很好的解决了这个问题。让前端的页面模版和JAVA应用程序之间真正的解耦。

后台设计

商品数据统一处理设计

商品详情系统商品主数据经过MQ消息来源于外部系统，好比：商品基本信息、参数、参数模版、品牌、品类等。咱们设计时把共性抽出来分红三部分：

1. 接受MQ消息并持久化经过Listener
2. 解析报文
3. 业务处理上简化为add、update、delete三个动做
4. 异常组件以观察者模式实现，记录处理失败的MQ消息并对消息进行截取，并供下次再反向执行(一条MQ消息中会有一到多条参数、品牌，因此这里用截取)

SOA服务治理

解耦分两块，系统交互间的解耦和商品详情系统组件间的解耦以及业务流程的解耦

系统间的解耦经过SOA服务治理来解决，可是因为业务的特殊性在服务治理和性能以及一些其它因素的权衡中，咱们还选择了一种共享Redis的方式来解决解耦

商品详情系统组件间解耦以及业务流程的解耦

架构演变

1.0时代中规中矩，移动端彻底移值PC的作法

咱们使用中规中矩的部署方式Varnish+Apache+JBoss。

这种架构在针对中小系统没有什么问题，但像商品详情系统这种访问量巨大的系统会显的有点吃力。移动端对性能的要求更高。

2.0时代PC和移动端服务分离，移动端服务合并，性能优化

a. 服务分离与服务合并

PC和移动端的服务分离，之前是同一个接口支持多端，如今是每端都有独立的应用层服务，原子层服务共享。

移动端处理器和内存性能上的限制，采用服务的合并，且移动端用Nginx+Lua。

b. 公共服务

提出了一个公共服务，公共服务用来接受PC、WAP、APP公共的异步请求的服务。

c．分布式文件系统

商品详情页在回源过程当中压力很大，基于其不可降级，咱们提出了把商品详情页作为一个静态页放到分布式文件系统，当DB和Redis压力过大，直接调取分布式文件系统中数据

3.0时代重点优化移动端性能，接口合并颗粒度更细，增长聚合服务层

多端都使用Nginx+Lua，Nginx 的异步非阻塞型事件处理机制资源消耗少，并发能力高。

1. 用Nginx+Lua作为总体的接入层
2. 在Nginx接入层 加入三层缓存
3. 只有聚合信息才会调用服务层，减小依赖关系
4. 服务层数据经过Worker推送和刷新缓存，这亲服务层彻底和DB隔离
5. 移动端链接复用、链路复用、防劫持SDK开发等

商品详情系统数据流结构

上面介绍了商品详情系统前、中、后三层逻辑架构以及各层的设计方法，还介绍了部署架构演变，下面是商品详情系统数据流程结构的

1.0版本.

这个结构有两个问题：

数据异构结果没有和前端展现关联起来，数据变动不能在前端及时展现

仍是没有解决前端接口依赖问题

2.0版本：

把前端分红了三部分：

基础信息组件 不须要加工的消息、聚合信息组件(须要组合消息或者计算才能提供服务的)、实时数据组件处理对外部的依赖

数据异构后会以MQ形式通知基础服务，并会刷新缓存，这种结构后前端与数据层无直接依赖。

回源方案

回源是缓存中最头痛的问题，随着系统业务复杂度的上升，很难从总体上把控各类业务数据在回源时给一个系统带来的压力，若是回源处理不端在极端状况下会致使DB压力瞬间上升，DB不可用或者链接数满了等问题，会发生之前相似JVM GC回收时的“stop-the-world”问题。咱们回源从被动更新缓存数据更改成主动推送缓存数据从根本上解决这问题。

数据变动经过listener推送缓存至varnish

多端融合

组织架构融合

原来PC端、移动端、TV端产品、开发、测试是分中心分部门，为真正作到多端融合，进行组织架构融合，产品、开发、测试合并到一个中心，统一协调。合并后工做效率变高，产品质量提高，进行小团队作战。

展现分离逻辑融合分离

展现分离是指在结合公司业务特性、产品自身特性以及降耦合指导思想进行PC、WAP、APP端(IOS、ANDROID)、TV端的展现端进行分离处理。

逻辑融合分离是指在原子服务层进行融合共享，从服务单一职责原则出发在不一样端分别提供独立的服务并加上各自特性，作到接口可扩展性和服务隔离。真正作到一包部署多端使用互不影响，在业务可扩展性和可维护性上作到成本最低。

展现层分端独立部署

在物理层为了不多端进行资源竞争、相互干扰进行独立部署

分布式存储

数据库

1. 商品详情系统数据库用Mysql，采用主从加读写分离结构，注意：主从不在同一个物理机上，也不在同一组路由器中。应用层中业务上对时效性要求高的数据在写库中操做，业务上对于时效性要求不高数据在读库中操做。主从结构保证在主库出现故障好比岩机自动切换到从库。读库经过LVS作负载均衡作到高可用。
2. DalClient组件支持对数据库的分库分表，同时支持横向扩展。

分布式Redis缓存

1. 应用层逻辑优先从Reids中获取业务数据，若是Redis中没有，再从DB中获取。Redis采用sharding方案，每一个sharding由一个master和一个salve组成，再经过sentinel保证高可用。当master出现不故障，好比网络跳动，sentinel会自动把salve切换为master，这个切换是毫秒级的。master和salve经过主动和被动两种方式来同步，作到最终一致性，符合CAP理论演变过的BASE理论。
2. 借鉴JAVA GC中对内存分代思路解决Redis缓存过时产生的惊群现象。