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的微服务项目实战