架構設計中要考慮的核心五要素;
性能、可用性、擴展性、伸縮性、安全性算法
響應時間
應用執行一個操做須要的時間,包括從發出請求開始到收到最後響應數據所須要的時間。響應時間是系統最重要的性能指標,直觀地反映了系統的「快慢」。下表列出了一些經常使用的系統操做須要的響應時間。
sql
併發數
系統可以同時處理請求的數目數據庫
隨着併發數的增大,吞吐量隨着增大;
超過閾值後,併發數繼續增大,吞吐量降低,直到吞吐量降爲0,網站宕機;緩存
理解上述3個指標:類比高速公路行車
吞吐量就是天天經過的車輛數
併發數是正在行駛的車輛
響應時間是車速安全
下圖中的橫座標表示消耗的系統資源,縱座標表示系統處理能力(吞吐量)。在開始階段,隨着併發請求數目的增長,系統使用較少的資源就達到較好的處理能力(a~b段),這一段是網站的平常運行區間,網站的絕大部分訪問負載壓力都集中在這一段區間,被稱做性能測試,測試目標是評估系統性能是否符合需求及設計目標;隨着壓力的持續增長,系統處理能力增長變緩,直到達到一個最大值(c點),這是系統的最大負載點,這一段被稱做負載測試。測試目標是評估當系統由於突發事件超出平常訪問壓力的狀況下,保證系統正常運行狀況下可以承受的最大訪問負載壓力;超過這個點後,再增長壓力,系統的處理能力反而降低,而資源消耗卻更多,直到資源消耗達到極限(d點),這個點能夠看做是系統的崩潰點,超過這個點繼續加大併發請求數目,系統不能再處理任何請求,這一段被稱做壓力測試,測試目標是評估可能致使系統崩潰的最大訪問負載壓力。服務器
性能測試反應的是系統在實際生產環境中使用時,隨着用戶併發訪問數量的增長,系統的處理能力。與性能曲線相對應的是用戶訪問的等待時間(系統響應時間),如圖所示。網絡
在平常運行區間,能夠得到最好的用戶響應時間,隨着併發用戶數的增長,響應延遲愈來愈大,直到系統崩潰,用戶失去響應。session
測試結果報告應可以反映上述性能測試曲線的規律,閱讀者能夠獲得系統性能是否知足設計目標和業務要求、系統最大負載能力、系統最大壓力承受能力等重要信息,下表是一個簡單示例。架構
構建高可用的應用服務器關鍵是session的處理,若是能使得天天機器上處理的請求都無狀態,便可實現應用服務器的線性伸縮;服務器宕機後也可隨時將請求放到其它機器上再次處理;
而對於須要處理狀態信息的應用,解決方案是讓每臺機器使用共享的Session服務器,本地上仍是無狀態特徵;併發
設計要點
CAP原理
一個提升服務的存儲系統沒法同時知足如下三個條件
一致性(Consistency)
數據可用性(Avalibility)
分區耐受性(Patition Tolerance,系統具備跨網絡分區的伸縮性)
WEB架構設計中,一般爲了保證高可用性,會犧牲一致性;
數據一致性分爲:強一致、用戶一致、最終一致;
大型WEB站點通常只保證數據的最終一致性;
在網站新增業務產品時,實現對現有產品無影響,透明上線新產品。
主要手段
經過不斷向集羣中加入服務器的手段來緩解不斷上升的用戶併發訪問壓力。
可能加入的服務器有如下4類,其伸縮性能各不相同;
經過設計實現集羣內服務器對等,使用合適的負載均衡可保證良好的伸縮性;
緩存服務器伸縮性良好,但新加入服務器後可能致使緩存路由失效;
經過改進緩存路由算法,好比Memcached的一致性Hash,可實現加入新的緩存服務器後對原有緩存的影響儘可能減小;
很難作到大規模集羣的可伸縮性
實現方式有:讀寫分離、數據表分庫
(單表拆分:Cobar)
也可考慮伸縮性方案在數據庫以外實現(經過路由分區)
Nosql數據庫就是爲海量數據而生,可輕鬆實現集羣規模的線性伸縮;
(Hbase使用Zookeeper選舉master)
99.99%的設計標準:無單點、在線更新、自動切換
卓越亞馬遜地址: 《大型網站技術架構》
點擊查看原圖
Posted by: 大CC | 13APR,2014
博客:blog.me115.com [訂閱]
微博:新浪微博