大型网站的页面静态化

Posted 2021-05-01 你可以不信

大型网站的特点是什么？首页的访问量巨大，用户进入首页后再点击自己感兴趣的内容，所以首页的访问量是所有页面中最大的。而将页面静态化能起到一定的优化作用。

用户发送请求后服务器直接返回静态数据html，不需要与数据库通信，同时也省去了服务器编译的时间，所有能起到优化性能的作用，主要适用于知乎，新浪等内容展示类网站。数据经常变化的页面则不适合做静态化处理。

比较典型的三种静态化方法：网页静态HTML化；伪静态化；布局样式模板化。

网页静态HTML化

这种方法会将内容与页面写在一个html文件中，当用户请求时直接返回对应的内容。用户的请求时直接请求的是html文件名，如4399.html，核心流程如下：

上图的核心思想：

1. 创建或者更新文章后，系统发送消息到消息队列中，生成html文件的服务监听消息队列，保证了有新的内容到来时能及时生成对应的html文件
   

2. 通过同步工具实现增量同步（即只同步修改了的文件），把所有新生成的html文件同步到web服务器上。

因此，当用户访问页面时由web服务器直接返回html文件，不需要与数据库通信。

由上图可看出，这个思路会生成大量的html文件，这也导致了如下缺点：

1. 修改页面布局不方便，因为是已经写死了的html文件，如果需要修改页面布局的话需要将所有html文件重新生成一遍。对于大型网站来说，基本不现实。
   

2. 生成的html文件过多，而且每台web服务器上的内容都是相同的，太过冗余，浪费空间。

3. 同步工具的稳定性问题，文件量比较大过后一定会出现稳定性问题的。多一个环节（同步），就肯定会多一份出现问题的概率，这也是很多架构讲究简单的原因，环节越少，越少出错！

伪静态化

可是当用户发送的链接中有参数时，比如id=2,time=2020就不是一个固定的文件名了，发送的链接变为了zhihu. com/abc.php?a=1&b=2。这种链接对于搜索引擎来说不太友好，会导致网站在排名时比较靠后。所以就需要伪静态化了，动态网站为了方便被搜索引擎收录，利用服务器（nginx可对url执行rewrite）的rewirte实现的假静态的过程。

例如： www.odshen.com/blog/user/id/2/page/5 // 动态
伪静态就是 www.odshen.com/blog/user.html // 看似静态

针对上一个方案的问题，方案可进一步演化为：

方案一中的静态服务进化为了缓存服务，缓存服务监听到消息队列中的数据后，将数据缓存到缓存服务器。web服务器在收到用户的请求后向缓存服务器查询对应的内容，不需要向数据库查询数据。

该方案解决了方案一种的html文件过多的问题，同时不需要查询数据库，性能较好。但是此方案仍然把所有的内容放到了缓存中，修改布局时需要重新设置缓存；分布式缓存压力较大，需要搭建集群。

布局样式模板化

为了解决方案二中的布局样式问题，方案进化成如下：

应用层nginx：

nginx一般被用做负载均衡，其实nginx还有很多的功能，尤其他的openresty扩展 + lua脚本语言结合起来可以完成很多功能，可以理解为lua脚本语言就是类似java语言，可以动态处理业务，如：本地缓存处理，远程http访问，访问redis等。

所以可以使用http模板 + lua脚本实现网页渲染

1）应用层nginx通过lua脚本语言先获取本地商品数据，然后和http模板进行渲染，形成最终商品详情页返回给用户

2）如果应用层nginx本地的缓存没有此商品数据，就通过lua脚本发起http请求访问web服务器，获取商品数据。

3）web服务器会向redis或本机的ehcache请求商品数据（这里涉及三级缓存概念），如果存在此商品数据，直接返回给用户；如果不存在则请求微服务访问数据库。

这个思路就是通过http模板，解决了方案二中的布局样式的问题，如果需要调整布局，只要改一下模板就行了，非常方便。也解决了实时性问题。nginx本地缓存其实就是为了保证不需要访问数据库，提升系统吞吐量。

分发层nginx

大型网站的商品数太多了，应用层nginx的本地缓存是有限的，不可能把所有的商品数据缓存在同一个服务器的本地缓存。

一台应用层nginx只能缓存部分商品数据，分发层就是利用hash一致性算法，根据商品id路由分发到同一个应用层ngnix服务器。

总结

1. 方案三是比较完整的方案，很多大厂都在使用，能够承受亿级流量，但系统比较复杂。

2. 如果对实时性要求不高，布局样式调整不频繁，可以考虑方案二，系统比较简单