1. 程式人生 > >前端工程之CDN部署

前端工程之CDN部署

之前發的一篇文章《變態的靜態資源快取與更新》中提到了靜態資源和頁面部署之間的時間間隙問題,這個問題會迫使前端靜態資源釋出必須採用非覆蓋式。那篇文章中沒有詳細解釋為什麼會產生不可忍受的時間間隙,本文算是對它的補充。

之所以會產生部署時差,最主要的原因就是使用了CDN服務。

大型Web應用對速度的追求並沒有止步於僅僅利用瀏覽器快取,因為瀏覽器快取始終只是為了提升二次訪問的速度,對於首次訪問的加速,我們需要從網路層面進行優化,最常見的手段就是CDN(Content Delivery Network,內容分發網路)加速。通過將靜態資源快取到離使用者很近的相同網路運營商的CDN節點上,不但能提升使用者的訪問速度,還能節省伺服器的頻寬消耗,降低負載。


遍佈全國的CDN節點和內容源示意圖

不同地區的使用者會訪問到離自己最近的相同網路線路上的CDN節點,當請求達到CDN節點後,節點會判斷自己的內容快取是否有效,如果有效,則立即響應快取內容給使用者,從而加快響應速度。如果CDN節點的快取失效,它會根據服務配置去我們的內容源伺服器獲取最新的資源響應給使用者,並將內容快取下來以便響應給後續訪問的使用者。因此,一個地區內只要有一個使用者先載入資源,在CDN中建立了快取,該地區的其他後續使用者都能因此而受益。


使用CDN快取技術加速網路訪問速度

如上圖所示,之所以不同地區的使用者訪問同一個域名卻能得到不同CDN節點的IP地址,這要依賴於CDN服務商提供的智慧域名解析服務,瀏覽器發起域名查詢時,這種智慧DNS服務會根據使用者IP計算並返回離它最近的同網路CDN節點IP,引導瀏覽器與此節點建立連線以獲取資源。

結合上述兩點,為了使用CDN網路快取,我們至少要對靜態資源的部署做兩項改變:

1.將靜態資源部署到不同網路線路的伺服器中,以加速對應網路中CDN節點無快取時溯源的速度。

2.載入靜態資源時使用與頁面不同的域名,一方面是便於接入為CDN而設定的智慧DNS解析服務,另一方面因為靜態資源和主頁面不同域,這樣載入資源的HTTP請求就不會帶上主頁面中的Cookie等資料,較少了資料傳輸量,又進一步加快網路訪問。

CDN服務基本上已經成為現代大型Web應用的標配,這項技術“幾乎”是一種對開發透明的網路效能優化手段,使用它的理由很充分,但是這裡既然強調了“幾乎透明”而不是“完全透明”,是因為使用CDN服務所需要的兩項改變對前端工程產生了一定的影響,而這些影響我在之前的文章中已經介紹了,就是前端工程必須引入非覆蓋式釋出的根本原因。


前端工程多米諾骨牌

上圖向大家展示了整個前端靜態資源快取技術所帶來的連鎖性工程問題。很多人不理解為什麼要選擇FIS,而不是grunt,從本質上來說,工具並麼有什麼差異,只是fis的設計出發點是以上這些工程問題,設計中優先考慮了現代網際網路應用是如何進行工程化部署與開發的,面臨的問題是哪些,基於這些問題,要怎麼解決。

比如我們在上圖中可以看到,整個靜態資源快取技術的最終影響的節點是前端靜態資源定位問題,而且前端資源定位又會進一步影響到開發,包括程式碼中的模組化載入、各種資源載入等。所以fis的設計核心之一就是資源定位。比如fis的核心配置roadmap,其目的就是為了解決在前端程式碼中的所有資源定位問題,連線開發和部署規範:

此外,fis的靜態資源表生成功能也是為了給模組化框架提供載入部署到其他域名下的路徑中md5戳的資源部署路徑,並建立資源之間的依賴關係。

至於檔案壓縮之類的功能,那只是工具問題,而非工程問題。