第18章 大浏览量系统的静态化结构设计

Posted 2020-10-04 刘大飞

18.1 淘宝大浏览量商品详情系统简介

　　HTTP请求经过负载均衡设备分配到某个域名对应的集群，经过nginx代理到JBoss或者Tomcat容器，由他们负责具体处理用户请求。目前这些大浏览量的系统大部分需要读取的数据都已经直接走

K/V 缓存了，不会直接从DB获取数据。

18.2 系统面临哪些挑战

　　突发的流量冲击； 攻击和恶意请求；

18.3 淘宝前台系统的优化历程

　　系统拆分，静态文件合并，前段页面异步优化和JSON化

　　去DB依赖、引入缓存、提升单机的QPS，关注用户体验。

　　Velocity， BIgPipe

　　静态化改造

　　统一cache, CDN化， 网络协议

18.4 大浏览量系统的静态改造

　　18.4.1 什么是静态化系统

• URL能唯一标识一个页面
• 页面中不包含与浏览者相关的因素
• 页面中不包含时间因素，页面的DOM不能随时间而变化。
• 页面不包含地域因素
• 不能包含cookie等私有因素。

　　18.4.2 为什么要进行静态化架构设计

　　在web层可以直接返回结果，不用到达系统后端。

　　静态化优点：

　　　　改变了缓存方式：直接缓存HTTP连接而不仅仅缓存数据，WEB代理服务器根据请求URL直接取出对应的HTTP响应头和响应体直接返回，这个响应连HTTP都不用重新组装，同样，HTTP请求头也不一定需要解析，所以获取数据最快。

　　　　改变了缓存的地方：不是在JAVA层面做缓存，而是直接在web服务器层上做，而web服务器（如Nginx， ）都擅长处理大并发的静态文件请求。　　　　

　　18.4.3 如何改造动态系统　

　　如何将动态页面改造成适合缓存的静态页面呢？改造方法就是前面说的去掉那几个影响因素。解决办法就是将这些因素单独分离出来，也就是动静分离。

　　动静分离：

　　　　URL唯一化，detail页面就可以通过商品ID来唯一标识一个URL .

　　　　分离与浏览者相关的因素。登录信息可以单独拆分出来，通过动态请求获取。

　　　　分离时间因素。服务器输出的时间也通过动态请求获取。

　　　　异步化地域因素。把detail系统上与地域相关的做成异步方式来获取。

　　　　去掉Cookie。 

　　动态内容结构化：

　　　　分离出动态内容后，如何组织这些内容页很关键，这些动态内容会被页面中的其他模块用到，例如判断该用户是否登录、用户ID等。将这些信息JSON化可以方便前端获取，

　　如何组装动态内容：

　　　　知道如何分离那些内容后，又如何组织呢？现在的问题时如何获取它们，并和静态文件组装在一起。获取动态内容有两种方式：ESI和CSI

　　　　ESI：

　　　　CSI：

　　18.4.4 几种静态化方案的设计以及选择

　　一致性hash:

　　方案一： Niginx + Cache + java

　　方案二：

　　方案三：

　　18.4.5 如何解决失效问题

　　被动失效：处理时效性不敏感的数据，采用设置Cache时间长度这种自动失效的方式，同时也要开发一个后台管理界面，手动失效。

　　主动失效：

　　　　Cache失效中心监控数据库表变化，发送purge失效请求；

　　　　装修时间戳比较失效装修内容；

　　　　JAVA系统发布，请求Cache

　　　　VM模板发布，清空Cache;

　　18.4.6 服务端静态化方案的演进：CDN化

　　　　将Cache前移到CDN上，因为CDN离用户最近。但是有几个问题：

　　　　失效问题：CDN分布全国，要在秒级时间内失效这么广泛的Cache，对CDN的失效系统要求很高。

　　　　命中率问题：命中率是Cache的重要指标，Cache分散，命中率降低。

　　　　发布更新问题：

                  解决失效问题：

　　　　   

　　　　   解决命中率问题：