前言

我們小伙伴們在訪問淘寶、網(wǎng)易等大型網(wǎng)站時有沒有考慮到，網(wǎng)站首頁、商品詳情頁以及新聞詳情頁面是如何處理的？怎么能夠支撐這么大流量的訪問呢？

很多小伙伴們就會提出他們都采用了靜態(tài)化的方案，這樣用戶請求直接獲取靜態(tài)數(shù)據(jù)html，就不需要訪問數(shù)據(jù)庫了，性能就會大大提高；而且提高網(wǎng)站seo優(yōu)化。那今天老顧就帶著大家聊一下靜態(tài)化。把老顧之前工作場景中靜態(tài)化方案遇到的問題，以及如何演變的，分享給小伙伴。

關(guān)于相關(guān)的靜態(tài)文件的CDN技術(shù)，老顧就不在這邊講了。這個大型網(wǎng)站肯定都會用到的，什么是CDN，小伙伴們可以在網(wǎng)上查詢看一下，比較簡單；我們這邊注重看技術(shù)方案。

方案一：網(wǎng)頁靜態(tài)HTML化

這個方案是老顧最早使用的方案，我們就拿CMS系統(tǒng)舉例，類似網(wǎng)易的新聞網(wǎng)站；核心流程圖

上圖的核心思想：

1）管理后臺調(diào)用新聞服務(wù)創(chuàng)建文章成功后，發(fā)送消息到消息隊列

2）靜態(tài)服務(wù)監(jiān)聽消息，把文章靜態(tài)化，也就是生成html文件

3）在靜態(tài)服務(wù)器上面安裝一個文件同步工具，此工具的功能可以做到只同步有變動的文件，即做增量同步（老顧用久沒用了，忘了工具的名稱）

4）通過同步工具把html文件同步到所有的web服務(wù)器上面

這樣的話就達到了，用戶訪問一些變化不大的頁面時，是直接訪問的html文件，直接在web服務(wù)器那邊直接返回，不需要在訪問數(shù)據(jù)庫了，系統(tǒng)吞吐量比較高。

這個方案的問題：

1、網(wǎng)頁布局樣式僵化，無法修改

如果產(chǎn)品經(jīng)理覺得新聞詳情頁面的布局要調(diào)整一下，現(xiàn)在的不夠美觀，或者加個其他模塊，那就坑爹了，我們需要把所有的已經(jīng)靜態(tài)html化的文章全部重新靜態(tài)化。這個是不現(xiàn)實的，因為像網(wǎng)易這么大的體量，新聞量是很大的，會被搞死。

2、頁面會出現(xiàn)暫時間不一致

會出現(xiàn)用戶剛剛再看最新的新聞，刷新一下又不存在了。這個是因為同步工具在同步到web服務(wù)器是要有時間的，同步到web服務(wù)器A上面了，但web服務(wù)器B還沒有來得及同步。用戶在訪問的時候通過Nginx進行負(fù)載均衡，隨機把請求分配給web服務(wù)器的導(dǎo)致的。當(dāng)然可以調(diào)整nginx負(fù)載均衡策略去解決。

3、Html文件太多，無法維護

這個是很明顯的問題，html文件會越來越多，對存儲空間要求很大，而且每臺web服務(wù)器都一樣，浪費磁盤空間；將來遷移維護也會帶來很大的麻煩。

4、同步工具的不穩(wěn)定

因為文件一旦多之后，同步工具穩(wěn)定性就出現(xiàn)了問題

這個方案應(yīng)該是比較傳統(tǒng)的（不推薦）

方案二：偽靜態(tài)化

什么是偽靜態(tài)？

舉個例子：我們一般訪問一個文章，一般的鏈接地址為：http://www.xxx.com/news?id=1代表請求id為1的文章。不過這種鏈接方式對SEO不是太友好（SEO對網(wǎng)站來說太重要了）；所以一般進行改造：http://www.xxx.com/news/1.html 這樣看上去就是個靜態(tài)頁面。一般我們可以采用nginx對url進行rewrite。小伙伴如何有興趣可以自行了解，比較簡單。

之所以是偽靜態(tài)其實也是需要動態(tài)處理的。

針對方案一上面問題，方案進一步的演化，如下圖

此方案的核心思想

1）管理后臺調(diào)用新聞服務(wù)創(chuàng)建文章成功后，發(fā)送消息到消息隊列

2）緩存服務(wù)監(jiān)聽消息，把文章內(nèi)容緩存到緩存服務(wù)器上面

3）用戶發(fā)起請求，web服務(wù)器根據(jù)id，直接查詢緩存服務(wù)器

4）獲取數(shù)據(jù)返回給用戶

此方案就解決了方案一的一個大問題，就是html文件多的問題，因為不需要生成html，而且用緩存的方式，解決不需要訪問數(shù)據(jù)庫，提升系統(tǒng)吞吐量。

不過此方案的問題：

1、網(wǎng)頁布局樣式維護成本比較高，因為此方案照樣是把所有的內(nèi)容放到了緩存中，如果需要修改布局，需要重新設(shè)置緩存。

2、分布式緩存壓力比較大，一旦緩存故障就導(dǎo)致所有請求會查詢數(shù)據(jù)庫，導(dǎo)致系統(tǒng)崩潰

還有個小問題，就是實時數(shù)據(jù)處理，就是頁面中如價格，庫存需要到后臺讀取的。當(dāng)然小伙伴也許就會說，也可以處理啊，用戶把商品內(nèi)容請求到后，然后在用瀏覽器發(fā)送異步的ajax請求獲得商品數(shù)量就好了啊。這樣就是無形的增加了一次請求。（此問題可以忽略）

此方案類似很多公司都在使用，如：同程旅游等

方案三：布局樣式模板化

針對方案二的問題，我們可以采用openresty技術(shù)方案進行，利用http模板插件lua腳本進行解決，這里老顧不會介紹openresty+lua技術(shù)，有興趣的小伙伴，可以到訪問https://www.roncoo.com/view/139 這個視頻課程。

如下圖：

這里說明一下上圖中我們小伙伴不需要全部都要了解，這個是比較全的商品詳情頁的解決方案，涉及到了三級緩存這個概念，在這里老顧就不深入講三級緩存了。

我們主要看的是上面怎么會有兩層ngnix，分發(fā)層和應(yīng)用層，這個是什么意思？

應(yīng)用層nginx

老顧先介紹一下應(yīng)用層nginx是什么意思？nginx一般被用做負(fù)載均衡，其實nginx還有很多的功能，尤其他的openresty擴展 + lua腳本語言結(jié)合起來可以完成很多功能，小伙伴可以理解為lua腳本語言就是類似JAVA語言，可以動態(tài)處理業(yè)務(wù)，如：本地緩存處理，遠程http訪問，訪問redis等。

應(yīng)用層nginx就是利用了http模板 + 緩存通過lua腳本完成的網(wǎng)頁渲染

http模板

1）應(yīng)用層nginx通過lua腳本語言先獲取本地商品數(shù)據(jù)，然后和http模板進行渲染，形成最終商品詳情頁返回給用戶

2）如果應(yīng)用層nginx本地的緩存沒有此商品數(shù)據(jù)，就通過lua腳本發(fā)起http請求訪問web服務(wù)器，獲取商品數(shù)據(jù)。

3）web服務(wù)器會向redis或本機的ehcache請求商品數(shù)據(jù)（這里涉及三級緩存概念），如果存在此商品數(shù)據(jù)，直接返回給用戶；如果不存在則請求微服務(wù)訪問數(shù)據(jù)庫

這個思路就是通過http模板，解決了方案二中的布局樣式的問題，如果需要調(diào)整布局，只要改一下模板就行了，非常方便。也解決了實時性問題。這邊涉及到的nginx本地緩存其實就是為了保證不需要訪問數(shù)據(jù)庫，提升系統(tǒng)吞吐量。小伙伴只要了解一下思路，如果不了解openresty和lua可以自行上網(wǎng)了解，也可以聯(lián)系老顧。

分發(fā)層ngnix

為什么上面還有一層分發(fā)層呢？這個是因為大型網(wǎng)站的商品數(shù)太多了，應(yīng)用層nginx的本地緩存是有限的，不可能把所有的商品數(shù)據(jù)緩存在同一個服務(wù)器的本地緩存；一臺應(yīng)用層nginx只能緩存部分商品數(shù)據(jù)，說到這里小伙伴是不是應(yīng)該就知道為什么了吧？就是利用hash一致性算法，根據(jù)商品id路由分發(fā)到同一個應(yīng)用層ngnix服務(wù)器。