1、商品详情页整体架构组成
动态渲染系统
将页面中静的数据,直接在变更的时候推送到缓存,然后每次请求页面动态渲染新数据
商品详情页系统(负责静的部分):被动接收数据,存储redis,nginx+lua动态渲染
商品详情页动态服务系统(对外提供数据接口)
提供各种数据接口
动态调用依赖服务的接口,产生数据并且返回响应
从商品详情页系统处理出来的redis中,获取数据,并返回响应
时效低:
时效高:
OneService系统
动的部分,都是走ajax异步请求的,不是走动态渲染的
商品详情页统一服务系统(负责动的部分)
前端页面
静的部分,直接被动态渲染系统渲染进去了
动的部分,html一到浏览器,直接走js脚本,ajax异步加载
商品详情页,分段存储,ajax异步分屏加载
工程运维
限流,压测,灰度发布
2、商品详情页前端介绍
最后,相当于我们已经有了两套系统
第一套:商品服务+动态渲染系统
第二套:库存/价格服务+OneService系统
第三部分:前端页面
(1)时效性比较低的数据
更新的时候发送消息到mq,专门有一套数据同步服务+数据聚合服务来进行数据的加工和处理
前端页面,请求商品详情页的时候,nginx会走多级缓存策略(nginx local cache -> 本机房redis集群 -> 数据直连服务 -> 本地jvm cache -> redis主集群 -> 依赖服务),将时效性比较低的数据,全部加载到内存中,然后动态渲染到html中
前端html展示出来的时候,上来就有一些动态渲染出来的数据
(2)时效性比较高的数据
依赖服务每次更新数据库的时候,直接就更新redis缓存了,mysql+redis双写
前端html在展示出来以后,立即会对时效性要求比较高的数据,比如库存,价格,促销,推荐,广告,发送ajax请求到后盾
后端nginx接收到请求之后,就会将请求转发给one service系统,one service系统代理了所有几十个服务的接口,统一代理,统一降级(怎么实现的?),预处理,合并接口,统一监控
由one service系统发送请求给后端的一些服务,那些服务优先读redis,如果没有则读mysql,然后再重新刷入redis
全局降级参考:使用 Hystrix 定义全局的降级方法
(3)商品介绍
写的时候,采取的是分段存储策略,之前介绍过了
读的时候,也是在用户滚屏的时候,动态的异步ajax加载,分段加载商品介绍,不要一次性将所有的商品介绍都加载出来
总结
第一版:深入redis,缓存架构,hystrix高可用
第二版:完整的亿级流量商品详情页的系统架构,spring cloud+jenkins+docker的微服务项目实战