當Web Application(以下簡稱WebApp)大量取代傳統(tǒng)桌面應(yīng)用程式，資訊服務(wù)類型的軟體公司，需要解決的「重復(fù)與浪費」問題，就不只有軟體架構(gòu)本身;相信大家都清楚軟體架構(gòu)本身，需要模組化、元件化，讓寫好的功能(程式碼)可以盡可能再利用，最好有很多Plugins或Modules，當有需要的時候就可以拿來使用或擴充。

　　資訊服務(wù)公司通常不會只有一或少數(shù)幾項軟體專案，而是會建立非常多系統(tǒng)。因此，重復(fù)造成的浪費問題就更加嚴重。

　　一般來說，經(jīng)過編譯的程式或者原始碼本身，都不太會有體積的問題。例如封裝成.dll或.jar之后，就可以再不同專案中引用。搭配好的自動化建置機制，通常我們不需要將外部共用的模組(或元件)，放到專案的版本控制系統(tǒng)，只有進行測試或最后發(fā)布時，才需要把這些檔案暫時加進來。

　　但是WebApp包含的內(nèi)容并不只有程式，還有許多比較像是「資源」的東西。例如：

　　jQuery core + jQuery UI + .... 一大票 jQuery Plugins

　　Ext JS + 一大票 Widgets ...

　　ICON library + ... 一大票圖庫

　　自行開發(fā)維護的JavaScript、CSS、ICON 共用libraries 等

　　如果沒有好的解決辦法，這些資源除了被重復(fù)發(fā)布到很多網(wǎng)站伺服器，造成儲存空間及頻寬的浪費，甚至也會被加到專案版本控制系統(tǒng)的repository。

　　舉例來說，Ext JS 4 的原始碼ext-4.0.7-gpl 解壓縮后體積高達166MB，為了某些情況除錯方便，我們可能不會只保留必要及壓縮最佳化的檔案，而是需要完整的檔案。除非使用的Framework 有良好的Plugins 機制，可以引用Ext JS 但不會實際被加到專案資料夾(只有在建置test 或production 階段才會加入暫存的區(qū)域);否則，一般來說都是直接在WebApp 的資料夾中，也保存一份完整的副本。

　　相信有很大一部份比例的專案，都是直接就把這些資源加到專案的repository，一起發(fā)布到版本控制系統(tǒng);這是最簡便的方式，可是也是最浪費資源。這么做會帶來一些問題：

　　不屬于專案的東西，卻要納入專案的版本控管。占空間(雖然現(xiàn)在硬碟很便宜，這問題顯得不大)、維護麻煩。

　　專案的repository 變得十分肥大，真正屬于專案的部份也許不到30MB，但整體卻超過100MB。對于版本較舊的SVN 來說，執(zhí)行速度可能隨檔案愈多愈復(fù)雜而變得愈慢。

　　不管是新加入的成員，或經(jīng)歷一次災(zāi)難后需要重新取出(checkout)完整的檔案，浪費伺服器資源及網(wǎng)絡(luò)頻寬，最重要的寶貴時間也會因此白白浪費。

　　假設(shè)一家資訊服務(wù)公司有20 個系統(tǒng)，就造成資源20 倍浪費。

　　對于導(dǎo)入持續(xù)整合機制的專案來說，又造成更多的浪費。

　　像是GitHub 等專案托管服務(wù)，有檔案容量的限制，占空間就是個需要考慮的問題。

　　即使在開發(fā)階段，解決資源重復(fù)造成的浪費問題，例如可以不必將外部資源納入版本控管;但是最終打包發(fā)布時，放到正式的伺服器運作，還是需要加入這些檔案(可以透過最佳化讓檔案少一些、體積小一些)，最終，浪費的問題還是存在。

　　對于資訊服務(wù)公司來說，建置私有CDN 不僅可以得到很多好處，而且在云端服務(wù)價格低廉的時代，更是很難找到理由不這么做。

　　CDN(內(nèi)容傳遞網(wǎng)路，content delivery network)的概念，是指一種透過網(wǎng)際網(wǎng)路互相連接的電腦網(wǎng)路系統(tǒng)，提供高效能、可擴展性、及低成本的網(wǎng)路將內(nèi)容傳遞給使用者。

　　簡單地說，我們可以建置遠端的檔案服務(wù)伺服器，將WebApp 專案常需要用到的靜態(tài)資源，都放到這些伺服器，讓這些伺服器維持高可用性、擴展性，提供足夠的負載量;如此一來，所有的專案共用的WebApp 資源，就可以布署到這些服務(wù)器。

　　建立CDN 的優(yōu)點很多，包括開發(fā)人員可以快速利用(不必每次都要重新下載、建立library)，減少遠端布署需要的時間，讓不同專案之間可以共用資源，降低正式伺服器的存取及頻寬消耗，幫助需要高負載的WebApp 減輕負擔，...

　　事實上，Google就建立了自己的CDN，提供包含jQuery、jQuery UI、Prototype等網(wǎng)站常用到的資源，并且也把這個CDN免費開放給所有開發(fā)者使用。

　　不過，免費的CDN 通常不會剛好有你需要的所有東西;以Ext JS 來說，Google 僅提供核心部份Ext Core，而Sencha 雖然也有為Ext JS GPL 架設(shè)CDN，但實測后發(fā)現(xiàn)經(jīng)常有找不到檔案的情況。

　　對資訊服務(wù)公司來說，用其他人提供的CDN 并不是個好辦法，因為哪天該CDN 結(jié)束運作，或者已經(jīng)不提供某個版本的資源，就會造成一些系統(tǒng)因此受連累而掛點。所以，建置私有CDN 是比較好的方案。

　　一般來說，自己租用專線架設(shè)伺服器來做CDN 并不劃算，光是要達到資料及網(wǎng)路的備援，以及高可用性(要預(yù)防斷電斷網(wǎng)路天災(zāi)人禍等問題)，要付出的成本實在太高。

　　使用虛擬主機(Virtual Host 或VPN)是個相對便宜的方法，但是一般的虛擬主機都有容量、頻寬流量限制，以及不管有沒有用到它，都需要付基本的月租費。

　　所以，本文介紹的方案，是采用Amazon S3(Simple Storage Service)及CloudFront。

　　Amazon S3 的主要優(yōu)點，包括它是采「使用量付費」，計費內(nèi)容包括儲存空間、存取次數(shù)、傳輸量三項。因此若剛開始只需要放500MB 的檔案，就只需要為這有用到的儲存空間及傳輸量付費，注冊S3 服務(wù)并不需要設(shè)定容量，即使未來可能成長到幾TB 的容量，也不需要一開始就租賃旗艦級的方案，同時也不會有每月傳輸量限制的問題。

　　使用S3 建立CDN 的步驟很簡單：

　　建立S3 Bucket(儲存空間)，并將名稱設(shè)為CDN 網(wǎng)址(如：cdn.yourname.com)

　　修改DNS 設(shè)定，將網(wǎng)址透過CNAME 指向Bucket 的End Point 網(wǎng)址

　　設(shè)定Bucket 的Web Site 為Enabled

　　將要放到CDN 的檔案如Ext JS 等，上傳至Bucket，并設(shè)為Public

　　對于Mac及Linux的使用者來說，可以用s3cmd工具來管理檔案，這個軟體可以在command line下輕松將本地檔案，上傳或同步到指定的S3位址。

　　除了在建立CDN 時可以用s3cmd，如果遇到客戶因預(yù)算或速度考量，需要把專案整個搬遷到企業(yè)內(nèi)部網(wǎng)絡(luò)可以直接存取的服務(wù)器，也可以利用s3cmd 做一份mirror，維持專案使用到的資源有一致的存取配置。

　　如果開發(fā)的WebApp 是需要提供給大眾使用，甚至有來自世界各地的使用者，使用S3 可以方便地搭配CloudFront 建置全球化的CDN。

　　CloudFront 不能儲存檔案，它是用來「傳遞」S3 或其他來源的檔案，透過分散在世界各地的資料中心(S3 的Bucket)，減少網(wǎng)路傳遞路徑的延遲。簡單地說，CloudFront 可以讓S3 的檔案下載速度更快，而且傳輸費用也比S3 便宜(包括傳輸費用+存取次數(shù))。

本文鏈接：http://m.51huadong.com/cloundnews/11000669.html