觊时娱乐共羸欢乐

设为首页 | 加入收藏 | 联系我们
咨询热线:

产品展示

当前位置:主页 > 产品案例 >

1111:商品详情系统架构设计

1111:商品详情系统架构设计
  • 产品名称:1111:商品详情系统架构设计
  • 产品简介:商品详情系统是一个展示商品基本信息、参数等详情的系统,是商品购买的入口。它是电商平台中访问量最大的系统之一,苏宁易购大促期间 PV 量和 UV 量很大,这么大的访问量对系统的并发能力要求高。在业务上它与周边系统的关系是高耦合。依赖商品详情系统的的

产品介绍:

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

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

  所有图片由独立的分布式图片系统管理,对原图进行不同规格的无损裁减和压缩。

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

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

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

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

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

  商品详情系统商品主数据通过 MQ 消息来源于外部系统,比如:商品基本信息、参数、参数模版、品牌、品类等。我们设计时把共性抽出来分成三部分:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  商品详情系统数据库用 Mysql,采用主从加读写分离结构,注意:主从不在同一个物理机上,也不在同一组路由器中。应用层中业务上对时效性要求高的数据在写库中操作,业务上对于时效性要求不高数据在读库中操作。主从结构保证在主库出现故障比如岩机自动切换到从库。读库通过 LVS 做负载均衡做到高可用。

  应用层逻辑优先从 Reids 中获取业务数据,如果 Redis 中没有,再从 DB 中获取。Redis 采用 sharding 方案,每个 sharding 由一个 master 和一个 salve 组成,再通过 sentinel 保证高可用。当 master 出现不故障,比如网络跳动,sentinel 会自动把 salve 切换为 master,这个切换是毫秒级的。master 和 salve 通过主动和被动两种方式来同步,做到最终一致性,符合 CAP 理论演变过的 BASE 理论。

  借鉴 JAVA GC 中对内存分代思路解决 Redis 缓存过期产生的惊群现象。

相关产品: