電商網站的商品詳情頁系統架構
1 小型電商架構:
小型電商網站的頁面展示采用頁面全量靜態化的思想。數據庫中存放了所有的商品信息，頁面靜態化系統，將數據填充進靜態模板中，形成靜態化頁面
推入 Nginx 服務器。用戶瀏覽網站頁面時，取用一個已經靜態化好的 html 頁面,例如freemarker,thymeleaf等，直接返回回去，不涉及任何的業務邏輯處理。
例如下面一個簡單的魔板:
<html>
<body>
商品名稱：#{productName}<br>
商品價格：#{productPrice}<br>
商品描述：#{productDesc}
</body>
</html>
這個是一個非常簡單的架構,當然也有公司使用,那么所有的數據直接走數據庫了,造成問題,數據服務器壓力比較大,
2 另外一種簡單的小型電商架構:
這中是在上一種上面加入了redis緩存服務器,可以避免所有的服務直接打到數據庫上面,可以減少服務的壓力
以上兩種架構總結:
對於小網站，頁面很少，很實用，非常簡單，Java 中可以使用 velocity、freemarker、thymeleaf 等等，然后做個 cms 頁面內容管理系統，模板變更的時候，點擊按鈕或者系統自動化重新進行全量渲染,當然第二種的架構較之前更加服務的調用量更高。
壞處在於，僅僅適用於一些小型的網站，比如頁面的規模在幾十到幾萬不等。對於一些大型的電商網站，億級數量的頁面，你說你每次頁面模板修改了，都需要將這么多頁面全量靜態化，靠譜嗎？每次渲染花個好幾天時間，那你整個網站就廢掉了。
3 大型架構一:
用戶瀏覽網頁時，動態將 Nginx 本地數據渲染到本地 html 模板並返回給用戶。
在這種架構下，我們需要保證系統的高可用性。
如果系統訪問量很高，Nginx 本地緩存過期失效了，redis 中的緩存也被 LRU 算法給清理掉了，那么會有較高的訪問量，從緩存服務調用商品服務。但如果此時商品服務的接口發生故障，調用出現了延時，緩存服務全部的線程都被這個調用商品服務接口給耗盡了，每個線程去調用商品服務接口的時候，都會卡住很長時間，后面大量的請求過來都會卡在那兒，此時緩存服務沒有足夠的線程去調用其它一些服務的接口，從而導致整個大量的商品詳情頁無法正常顯示。
這其實就是一個商品接口服務故障導致緩存服務資源耗盡的現象。
其實這種也不是最好的.最大型還可以進行改進.
4大型架構二
這種是個人理解到三層緩存服務加es的商品信息服務,openrety代替nginx可以提高西能,可以采用lua拉去redis緩存中的數據進行緩存
redis分布式服務,當redis中沒有的時候貨redis服務崩了的時候,.就會去堆緩存中進行查詢,只有整個服務掛了,那么對緩存才會出現問題,所以在這里是可以進行的
當被算法出去的時候,就會去es中查詢商品詳情,這樣對最終的服務數據不會造成太多影響,沒有服務直接打到數據庫上面