2011年(264)
分类: LINUX
2011-05-04 17:22:19
答案是:用BT,也就是你我應該都很熟悉的BitTorrent。
對於網站經營者、創業者來說,延展性的問題是在網站流量成長過程中勢必會面對的問題,如何建立一個具有延展性的架構(scalable architecture)便是在規劃網站事業過程中不可或缺的專業知識。
如果服務本身的功能性合乎使用者需求,卻因為架構、程式效能、資料庫效能的問題導致服務成長出現瓶頸,如何評估、分析網站效能瓶頸?釐清問題後如何找出對應的解決方案,可以思考的相關議題可能包括:
參考國外知名網站在架構上的作法是很好的一種方式,儘管服務的規模可能無法相比,但根據「正確的作法與經驗」踏出對的第一步,肯定是有助於突破網站營運的效能瓶頸。
Twitter身為全球最大的微網誌服務,運用數千台的伺服器提供服務給來自全球各地的使用者,然而每當網站內容、應用程式有更新時,如何盡可能地在越短的時間內將程式碼部署(deploy)到所有的伺服器便是相當重要的課題。
上的一篇文章:「」分享了Twitter如何持續改善應用程式的部署流程,在過去Twitter使用部 署應用程式,Capistrano是許多Ruby/Rails使用者(當然也有其他語言的開發人員會使用)用來部署程式碼的一個開源專案,開發人員在部署 程式碼的過程都可以透過自動化的部署流程來簡化經常重複的動作,尤其在專案必須同時部署到多台應用程式伺服器時會特別方便。
Twitter在早期便依賴Capistrano來進行應用程式的部署,每當有新版本的程式碼需要釋出時,Capistrano會根據預設好的各種 設定、流程到Twitter所有的伺服器上進行更新的動作,在過去伺服器還不多的情況下一切都很美好,但隨著Twitter伺服器數量的成長,到了幾百台 伺服器時,事情已經不再像過去一樣美好,甚至到後來擁有數千台伺服器時,更新的作業會耗費40分鐘。
Twitter針對這個問題,認為問題的關鍵在於:使用集中式的系統,也就是所有的伺服器要輪流排隊到同一台版本控制系統上進行程式碼更新。 Twitter最初的想法是將版本控制系統也做出分散式的架構,伺服器的程式碼更新就可以分散到不同的機器來壓縮部署時間,但事實上版本控制系統即使分散 在多台伺服器上,也同樣會有這些伺服器要更新檔案的時間。因此Twitter發現或許是需要一個完全去中心化、最好像是BitTorrent,利用P2P 的特色讓所有的節點都可以協助進行程式碼的更新。
以結果來看,在採用了BitTorrent的方式來更新程式碼後,部署的時間從40分鐘大幅減少到只要12秒鐘!實在是非常驚人的改善,數千台伺服器的程式碼居然只要短短12秒鐘就能完成。
Twitter也將此次部署流程改善的成果分享出來,專案名稱叫做,如果對於技術細節有興趣的讀者,可以再進行深入的研究;筆者簡單摘錄幾個重點如下: