天猫网站内容架构分析(小型小型电商网站页面展示采用页面全量静态化的思想)

　　天猫网站内容架构分析(小型小型电商网站页面展示采用页面全量静态化的思想)

　　电商网站的商品详情页系统架构 小电商网站的商品详情页系统架构

　　小电商网站的页面展示采用了所有页面静态化的思路。所有的产品信息都存储在数据库中，通过静态页面系统将数据填充到静态模板中，形成静态页面并推送到Nginx服务器。用户浏览网站页面时，获取的是一个静态转换后的html页面，直接返回，不涉及任何业务逻辑处理。

　　以下是页面模板的简单演示。

商品名称：#{productName}<br />

商品价格：#{productPrice}<br />

商品描述：#{productDesc}

　　这样做的好处是用户每次浏览一个页面，不需要和数据库进行任何交互逻辑，也不需要执行任何代码，直接返回一个html页面，速度和性能非常高。

　　对于Xiao网站，页面很少，很实用，也很简单。可以在Java中使用velocity、freemarker、thymeleaf等，然后搭建一个cms页面内容管理系统。当模板发生变化时，点击 按钮 或 系统再次自动进行完整渲染。

　　缺点是只适合一些小的网站，比如页面大小从几十到几万不等。对于一些大型电商网站，几亿页面，你说每次修改页面模板，都需要把这些页面全部静态化。它可靠吗？每次渲染需要几天时间，然后你的整个网站 将被废弃。

　　某大型电商网站商品详情页系统架构

　　在大电商网站产品详情页面的系统设计中，当产品数据发生变化时，变化消息会被压入MQ消息队列。当缓存服务从消息队列中消费这条消息时，感知到有数据变化，然后通过调用数据服务接口获取变化的数据，然后将整合后的数据推送到redis。 Nginx本地缓存的数据有一定的时间限制，比如10分钟。当数据过期时，会从redis中获取最新缓存的数据并缓存到本地。

　　当用户浏览网页时，将本地Nginx数据动态渲染到本地html模板，返回给用户。

　　虽然没有直接返回html页面那么快，但是也非常快，因为数据是在本地缓存的。实际上，它消耗了动态渲染 html 页面的性能。如果更改了html模板，则不需要重新静态化所有页面，也不需要发送请求。没有网络请求开销，直接将数据渲染到最新的html页面模板中并响应。

　　在这种架构下，我们需要保证系统的高可用。

　　如果系统访问量很高，Nginx本地缓存过期，redis中的缓存也被LRU算法清理掉了，那么就会有很高的流量，从缓存服务中调用商品服务。但是如果此时商品服务接口失效，延迟调用，缓存服务的所有线程都被这个调用的商品服务接口耗尽。当每个线程调用商品服务接口时，会卡住很长时间。随着时间的推移，大量的后续请求会卡在那里。此时缓存服务没有足够的线程调用其他一些服务的接口，导致整个商品详情页面无法正常显示。

　　这其实是商品接口服务故障导致缓存服务资源耗尽的现象。