下面是页面模板的大略 Demo 。

<html> <body> 商品名称：#{productName}<br /> 商品价格：#{productPrice}<br /> 商品描述：#{productDesc} </body></html>

这样做，好处在于，用户每次浏览一个页面，不须要进行任何的跟数据库的交互逻辑，也不须要实行任何的代码，直接返回一个 html 页面就可以了，速率和性能非常高。

对付小网站，页面很少，很实用，非常大略，Java 中可以利用 velocity、freemarker、thymeleaf 等等，然后做个 cms 页面内容管理系统，模板变更的时候，点击按钮或者系统自动化重新进行全量渲染。

商品详情页面html模板电商网站的商品详情页体系架构 Node.js

坏处在于，仅仅适用于一些小型的网站，比如页面的规模在几十到几万不等。
对付一些大型的电商网站，亿级数量的页面，你说你每次页面模板修正了，都须要将这么多页面全量静态化，靠谱吗？每次渲染花个好几天韶光，那你全体网站就废掉了。

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

大型电商网站商品详情页的系统设计中，当商品数据发生变更时，会将变更压入 MQ 行列步队中。
缓存做事从行列步队中消费这条时，感知到有数据发生变更，便通过调用数据做事接口，获取变更后的数据，然后将整合好的数据推送至 redis 中。
Nginx 本地缓存的数据是有一定的韶光期限的，比如说 10 分钟，当数据过期之后，它就会从 redis 获取到最新的缓存数据，并且缓存到自己本地。

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

虽然没有直接返回 html 页面那么快，但是由于数据在本地缓存，以是也很快，实在耗费的也便是动态渲染一个 html 页面的性能。
如果 html 模板发生了变更，不须要将所有的页面重新静态化，也不须要发送要求，没有网络要求的开销，直接将数据渲染进最新的 html 页面模板后相应即可。

在这种架构下，我们须要担保系统的高可用性。

如果系统访问量很高，Nginx 本地缓存过期失落效了，redis 中的缓存也被 LRU 算法给清理掉了，那么会有较高的访问量，从缓存做事调用商品做事。
但如果此时商品做事的接口发生故障，调用涌现了延时，缓存做事全部的线程都被这个调用商品做事接口给耗尽了，每个线程去调用商品做事接口的时候，都会卡住很永劫光，后面大量的要求过来都会卡在那儿，此时缓存做事没有足够的线程去调用其它一些做事的接口，从而导致全体大量的商品详情页无法正常显示。

这实在便是一个商品接口做事故障导致缓存做事资源耗尽的征象。