高并發(fā)平臺架構(gòu)規(guī)劃方案.doc

《高并發(fā)平臺架構(gòu)規(guī)劃方案.doc》由會員分享，可在線閱讀，更多相關(guān)《高并發(fā)平臺架構(gòu)規(guī)劃方案.doc（20頁珍藏版）》請在裝配圖網(wǎng)上搜索。

編號∶______ 版本∶______ 高并發(fā)平臺架構(gòu)規(guī)劃方案 V1.0 起草人： 田朝山 起草時間：2013年01月08日 審核人： 審核時間： 修改情況記錄： 序號 修改模塊名稱 修改內(nèi)容 修改人 修改人名稱 1 2 3 1 概述 1.1 簡述 本文檔針對okgohome項目的特點，根據(jù)項目各個階段的發(fā)展情況，在系統(tǒng)不調(diào)整或微調(diào)整的情況下逐步提升整體吞吐量以適應(yīng)項目的快速發(fā)展。其中包括各個階段項目架構(gòu)部署規(guī)劃。 1.2 設(shè)計目標 A. 快速的響應(yīng)能力 在各種情況下，能夠快速響應(yīng)用戶請求；具備可靠地容災(zāi)能力，部分系統(tǒng)問題不影響整體系統(tǒng)的正常運行。將停止服務(wù)時間降低到最低甚至是不間斷服務(wù)。 B. 可伸縮性的系統(tǒng)體系 隨著訪問的增加，系統(tǒng)具備良好的伸縮能力。其中包括硬件與軟件兩部分： 1)硬件：Web服務(wù)器集群，緩存服務(wù)器集群，文件服務(wù)器集群，數(shù)據(jù)庫服務(wù)器等集群。各個群集之間負載均衡，任何一個集群由于資源不足出現(xiàn)瓶頸的時候，只要根據(jù)需要添加一個服務(wù)器節(jié)點，做簡單的配置就能達到擴展的目的。 2)軟件：整個軟件應(yīng)用系統(tǒng)縱向分割，按照模塊劃分，各個模塊即相互獨立，又可以無縫結(jié)合。如果需要擴展一個模塊，只要做獨立開發(fā)，無需該原有系統(tǒng)的代碼，只要做簡單的配置就能結(jié)合在已經(jīng)，并對該模塊管理。 C. 安全可靠的系統(tǒng) 為保證網(wǎng)站的正常運行，用戶數(shù)據(jù)的高度安全，系統(tǒng)考慮了多種安全策略（網(wǎng)絡(luò)安全、系統(tǒng)安全、各子系統(tǒng)安全、子系統(tǒng)模塊安全、回話期間安全等）。系統(tǒng)具有724小時的運行能力，并且具有系統(tǒng)災(zāi)難的快速恢復(fù)能力，及數(shù)據(jù)安全的保證。 D. 易管理的體系架構(gòu) 整個系統(tǒng)、服務(wù)的狀態(tài)處于一個實時的監(jiān)控之下。其中包括：配置管理、故障性能檢測、代碼發(fā)布等： 1)配置管理：可以通過統(tǒng)一的管理系統(tǒng)，對整個運行環(huán)境進行界面配置管理。同類集群可以批量操作。 2)性能監(jiān)測：通過統(tǒng)一的監(jiān)控系統(tǒng)對不同類型的服務(wù)器或集群分別監(jiān)測，根據(jù)監(jiān)測報表實時決策優(yōu)化方案。 3)代碼發(fā)布: 如果擴展模塊開發(fā)完，只要通過發(fā)布系統(tǒng)發(fā)布到指定的服務(wù)器，或某一類服務(wù)器。 1.3 設(shè)計原則 1)高可用性：將停止服務(wù)時間降低到最低甚至是不間斷服務(wù)； 2)可擴展性：隨著訪問的增加，系統(tǒng)具備良好的伸縮能力； 3)可視性：系統(tǒng)、服務(wù)的狀態(tài)處于一個實時的監(jiān)控之下； 4)高性能高可靠性：經(jīng)過優(yōu)化的體系結(jié)構(gòu)及合理的備份策略； 5)安全性：結(jié)構(gòu)上的安全及主機的安全策略； 6)易維護性：通過簡單的操作就能維護龐大的集群系統(tǒng); 7)低成本：前期盡量在有限的硬件資源下，利用軟件提高性能。 1.4 讀者對象 該文檔的主要讀者對象：項目經(jīng)理、架構(gòu)師、服務(wù)器維護人員等。 2 項目分析 項目特點如下： 1) 高并發(fā)，初期雖然PV比較低，但隨著快速發(fā)展pv增長很快； 2) 數(shù)據(jù)實時性要求高； 3) 數(shù)據(jù)正確性要求高； 4) 大多數(shù)頁面屬于動態(tài)頁面； 5) 網(wǎng)站需要大量商品圖片展示； 6) 用戶通過搜索引擎、廣告、類目導(dǎo)航尋找商品； 7) 網(wǎng)站讀多寫少，比例超過10:1 8) 賣家相關(guān)數(shù)據(jù)量比較大，比如商品數(shù)、評價數(shù)。 3 架構(gòu)遵循規(guī)則 1)能分拆的獨立應(yīng)用，盡量分割開來； 2)獨立應(yīng)用有程序與數(shù)據(jù)庫組成； 3)程序有靜態(tài)文件或動態(tài)文件組成； 4)數(shù)據(jù)庫有主數(shù)據(jù)庫（專門用于寫）與從數(shù)據(jù)庫（專門用于讀）組成，其中主數(shù)據(jù)庫中的數(shù)據(jù)會實時同步到從數(shù)據(jù)庫； 5)頻繁調(diào)用的動態(tài)數(shù)據(jù)能加入緩存； 6)數(shù)據(jù)庫大到影響檢索效率是，必須橫向分割。如:用戶表已經(jīng)相當(dāng)大，ID能整除2的放在userinfo2，ID能整除3的放在userinfo3，ID能整除4的放在userinfo4，ID能整除5的放在userinfo5等，把一張大表分成4張小表。 7)數(shù)據(jù)庫、文件、緩存等服務(wù)器能負載均衡； 8)要求不及時，能批處理的盡量獨立批量處理。 4 系統(tǒng)架構(gòu) 項目初期由于壓力較小，應(yīng)用服務(wù)、數(shù)據(jù)庫、備份分別部署在獨立的服務(wù)器上，甚至都部署在同一臺服務(wù)器上。但整個系統(tǒng)前期的開發(fā)需要按照以下負載方式考慮設(shè)計分布式部署，方便隨著項目負荷增大，評估出負荷點，能很容易在不改變程序的基礎(chǔ)上，添加硬件設(shè)備就能緩解整體負荷。 由于前期節(jié)點比較少，“4.7 服務(wù)器性能檢測系統(tǒng)”、“4.8服務(wù)器管理系統(tǒng)”、“4.8 代碼分發(fā)系統(tǒng)”等暫時不考慮，具體開發(fā)時間根據(jù)項目發(fā)展情況而定。 4.1 子系統(tǒng)結(jié)構(gòu) 注：其中前臺的每個分站旗下的App與西安分站相同，這里進用西安分站做個舉例說明。 4.2 App應(yīng)用系統(tǒng) 包含web頁面的各App應(yīng)用，頁面類型分為：靜態(tài)頁面，動態(tài)頁面。靜態(tài)頁面對I/O要求比較高；動態(tài)頁面對內(nèi)存、CPU等要求比較高。因此靜態(tài)頁面與動態(tài)頁面分開部署在具有針對性的服務(wù)器上以提高性能。 Web服務(wù)器分：靜態(tài)Web服務(wù)器，動態(tài)Web服務(wù)器。其中當(dāng)客戶訪問靜態(tài)頁面的時候，僅訪問靜態(tài)web服務(wù)器，靜態(tài)Web服務(wù)器根據(jù)需要從文件服務(wù)器上提取所必須的css，js，圖片等文件；而當(dāng)用戶訪問動態(tài)頁面時，動態(tài)Web服務(wù)器根據(jù)需要先去緩存服務(wù)器上檢查是否有需要的數(shù)據(jù)，如果有，則直接從緩存服務(wù)器中取，否則從數(shù)據(jù)庫中取相應(yīng)的數(shù)據(jù)，同時添加到緩存服務(wù)器上（不是所有的數(shù)據(jù)都加到緩存服務(wù)器中，主要加那些不頻繁變化的數(shù)據(jù)），根據(jù)需要從文件服務(wù)器上提取所必須的css，js，圖片等文件。如圖2-1-1所示。 圖2-1-1 App應(yīng)用系統(tǒng)（分兩部分：動態(tài)，靜態(tài)） 靜態(tài)網(wǎng)頁的網(wǎng)址形式通常是以.htm、.html、.shtml、.xml等為后綴的。同時在靜態(tài)頁面上也可以出現(xiàn)各種動態(tài)的效果，如.GIF格式的動畫、FLASH、滾動字母等，這些“動態(tài)效果”只是視覺上的。靜態(tài)頁面的優(yōu)點： 1) 完全脫離了數(shù)據(jù)庫訪問的壓力，直接訪問速度快，用戶體驗良好，而且不容易屏蔽； 2) 內(nèi)容非常穩(wěn)定，容易被搜索引擎收錄，并且容易獲得較好排名；搜索引擎也會經(jīng)常光顧網(wǎng)站； 3) 提高網(wǎng)站安全性，防止不良代碼注入； 4) 對服務(wù)器要求不高。 因此對于不頻繁變化的內(nèi)容盡量靜態(tài)化，同時針對靜態(tài)頁面定制相應(yīng)的服務(wù)器，這樣不但能提高網(wǎng)站的訪問速度，同時能節(jié)省服務(wù)器資源。 動態(tài)網(wǎng)頁的網(wǎng)址形式通常是以.jsp、.php、.aspx、.asax、.shtml、.ascx等為后后綴的。動態(tài)頁面主要用于人機交互（如：論壇，評論等），實時效率比較高。動態(tài)頁面不但服務(wù)器要求比較高，同時需要頻繁與數(shù)據(jù)庫交互，給數(shù)據(jù)庫服務(wù)器帶來很大的壓力。 因此只有網(wǎng)站中頻繁變化的部分，以及管理系統(tǒng)需要做成動態(tài)頁面 隨著訪問量的不斷增加，即使靜態(tài)頁面與動態(tài)頁面分開，分別部署在不同的服務(wù)器上，也難于承受那么大的流量。 如果一臺服務(wù)器難于負荷靜態(tài)服務(wù)的時候，則根據(jù)需要添加多臺服務(wù)器一起承載靜態(tài)服務(wù)負荷。為了讓多臺服務(wù)器更好的協(xié)同工作，且隨著集群負荷的增加，可以根據(jù)需要添加服務(wù)器以達到分擔(dān)負荷的作用，則利用網(wǎng)絡(luò)負載平衡器把這些服務(wù)器群集起來。動態(tài)服務(wù)業(yè)可以按照這樣的均衡方式達到提高性能與擴展的效果。如圖2-1-2所示。 圖2-1-2 App應(yīng)用系統(tǒng)負載均衡 其中Windows2003 網(wǎng)絡(luò)負載均衡原理：是按照通訊量來分配的?？梢耘渲贸筛鱾€主機均分；也可以給好點的機器多分點負荷量，給差點的機器分少點負荷量（負荷量：各主機處理的通信量/總的通訊量）。也可以指定各個主機的優(yōu)先級，按照優(yōu)先級確定那個主機處理接收到的通訊。而整個群集對外表現(xiàn)為一個IP，一個域名只要綁定到該IP上，則通過該域名的請求都會分發(fā)到群集中的各個服務(wù)器上一起工作。 當(dāng)網(wǎng)站規(guī)模越來越大的情況下，即使用群集能解決性能問題，但所有的服務(wù)都部署在一個群集中，一個群集就有成百上千個站點很難管理。因此在網(wǎng)站到一定規(guī)模的時候，就需要按照網(wǎng)站模塊應(yīng)用的不同進行縱向分割。然后根據(jù)各個應(yīng)用的訪問量實際情況作負載均衡以提升整體的性能。靜態(tài)服務(wù)，動態(tài)服務(wù)都可以按照這樣的方式部署。其中動態(tài)服務(wù)縱向分割不僅方便了站點管理，更深遠的意義在于為數(shù)據(jù)庫負載提供了方便。因此動態(tài)服務(wù)器更應(yīng)該盡量按照應(yīng)用的不同縱向分割。如圖2-1-3所示。 圖2-1-3 App應(yīng)用負載均衡（動態(tài)應(yīng)用縱向分割） 4.3 數(shù)據(jù)庫系統(tǒng) 大型網(wǎng)站的性能瓶頸主要來自于動態(tài)服務(wù)，而影響動態(tài)服務(wù)性能關(guān)鍵在于數(shù)據(jù)庫能否及時響應(yīng)。各個動態(tài)應(yīng)用規(guī)模越大，響應(yīng)的數(shù)據(jù)庫就越臃腫，響應(yīng)的速度就越慢。所以動態(tài)服務(wù)部分響應(yīng)的數(shù)據(jù)庫的縱向分割不但便于管理，還能提升數(shù)據(jù)庫的性能，能達到數(shù)據(jù)庫負載均衡的效果。 由于部分數(shù)據(jù)庫在沒有借助第三方軟件或硬件情況下，自身不能負載均衡。就當(dāng)前形勢還沒必要用到第三方負載均衡工具的情況下，采用如下方案: 1) 讀寫分離。由于讀多寫少，大部分時間消耗在查詢上，因此讓主庫專門用于寫，從庫專門用于讀（讀庫可以有很多個，以減輕單個讀庫的負擔(dān)），同時同步寫庫與讀庫的數(shù)據(jù)；如圖2-2-1所示。 圖2-2-1 數(shù)據(jù)庫主從分離 2) 縱向分割就是，不同的應(yīng)用可以分到不同的DB中，不同的實例中。這種發(fā)放不但效率高，實施也很方便。如圖2-2-2所示。 圖2-2-2 數(shù)據(jù)庫分布式部署 3) 橫向分割就是，某些應(yīng)用不能分割，比如用戶注冊，但是用戶表會非常大，可以把大表分成小表，可以采用表分區(qū)，數(shù)據(jù)存儲在不同文件上，然后再部署到獨立物理服務(wù)器增加IO吞吐以改善讀寫性能，表分區(qū)的另外一個優(yōu)勢可以增加數(shù)據(jù)查詢速度。 4) 根據(jù)需要可以綜合使用以上三種方法，可以實現(xiàn)無限極的擴展。如圖2-2-3所示。 圖2-2-3數(shù)據(jù)庫負載均衡（綜合用法） 如果某個應(yīng)用的訪問量通過上面的方式綜合使用都無法負載時候，再采用第三方的負載均衡。 4.4 緩存系統(tǒng) 大型網(wǎng)站的吞吐率越大，尤其是動態(tài)服務(wù)部分，使數(shù)據(jù)庫的壓力也越來越大。如果數(shù)據(jù)庫壓力過大，嚴重影響網(wǎng)站的整體性能。使用緩存能有效應(yīng)對大負載，減少數(shù)據(jù)庫的壓力，并顯著提高多層應(yīng)用程序的性能。 采用業(yè)內(nèi)主流的Memcache。Memcached是開源的分布式cache系統(tǒng)。Memcached的緩存是一種分布式的，可以讓不同主機上的多個用戶同時訪問， 因此解決了共享內(nèi)存只能單機應(yīng)用的局限，更不會出現(xiàn)使用數(shù)據(jù)庫做類似事情的時候，磁盤開銷和阻塞的發(fā)生。 主要應(yīng)用App應(yīng)用系統(tǒng)與數(shù)據(jù)庫系統(tǒng)之間。根據(jù)網(wǎng)站各個應(yīng)用的實際情況配置多臺緩存服務(wù)器。如圖2-3-2所示。 圖2-3-1 Memcache緩存部署圖 4.5 文件存儲系統(tǒng) 有些內(nèi)容，既沒必要存放在數(shù)據(jù)庫里，也不適合存放在緩存中，如圖片，下載文件，js，css等數(shù)據(jù)。當(dāng)有海量內(nèi)容存放在文件系統(tǒng)中時，為了保證高并發(fā)請求下文件系統(tǒng)能夠及時的相應(yīng)請求，通過以下方式來提高文件系統(tǒng)的整體性能： 1) 按照文件類型的不同，分別部署在不同的服務(wù)器，甚至服務(wù)器集群上。如圖片文件可以不是在圖片服務(wù)器上，當(dāng)單臺圖片服務(wù)器承受不了當(dāng)前的負荷的時候，可以更具時間情況添加多臺圖片服務(wù)器通過NBL群集起來協(xié)同工作。 2) 當(dāng)多臺服務(wù)器通過負載平衡都難于承受某類文件負荷的時候，可以按照該類文件所屬的App應(yīng)用縱向劃分。如“web應(yīng)用1”的圖片文件單獨部署在單臺服務(wù)器上，甚至是多臺服務(wù)器集群上。 3) 為了將來易于擴展、移植，綜合使用以上兩種方法。先把各種文件按照App應(yīng)用劃分，再把文件按照類型劃分。即使所有的文件部署到一臺機器上，只要各個web應(yīng)用中的各種類型的文件通過獨立的域名調(diào)用，當(dāng)以后某種App應(yīng)用的的負荷很大時，或某種App應(yīng)用中的某種類型文件負荷很大時，也可以輕松移植到新添加的服務(wù)器上，只需要把相應(yīng)域名解析到相應(yīng)的服務(wù)器IP上即可。如圖2-4-1所示。 圖2-4-1 文件分布式不是 4.6 服務(wù)器性能監(jiān)控系統(tǒng) 在網(wǎng)站規(guī)模不大，服務(wù)器只有若干臺的情況下，運維人員可以逐臺服務(wù)器通過Windows任務(wù)管理器查看服務(wù)器資源使用情況，而這樣只能看到CPU、內(nèi)存以及硬盤等的使用情況，其他的（如：IIS的吞吐率，當(dāng)前的請求數(shù)等）都難于獲取，只能等錯誤發(fā)生了才能知道采取排查，是運維人員很被動。 但隨著網(wǎng)站規(guī)模的不斷擴大，整個網(wǎng)站所基于的服務(wù)器集群也在不斷擴大。當(dāng)服務(wù)器擴展到成百上千臺的時候，手工去逐臺采集已經(jīng)很不現(xiàn)實。因此必須通過專門的系統(tǒng)針對性的自動對各個服務(wù)器的信息采集，繪制成報表供運維實時掌握各個服務(wù)的現(xiàn)狀。監(jiān)控系統(tǒng)的部署如圖2-6-1所示。 圖2-6-1 服務(wù)器性能監(jiān)控系統(tǒng) 4.7 服務(wù)器管理系統(tǒng) 同“服務(wù)器性能監(jiān)控系統(tǒng)”類似。在網(wǎng)站規(guī)模不大，服務(wù)器只有若干臺的情況下，運維人員可以逐臺服務(wù)器手工配置，而且很難避免手誤。 但隨著網(wǎng)站訪問流量的不斷增加，網(wǎng)絡(luò)服務(wù)都是以負載均衡集群的方式對外提供服務(wù)，隨之集群規(guī)模的擴大，原來基于單機的服務(wù)器管理模式已經(jīng)不能夠滿足需求，新的需求必須能夠集中式的、分組的、批量的、自動化的對服務(wù)器進行管理，能夠批量化的執(zhí)行計劃任務(wù)。分布式服務(wù)器管理系統(tǒng)的部署如圖2-7-1所示。 4.8 代碼分發(fā)系統(tǒng) 隨著網(wǎng)站訪問流量的不斷增加，網(wǎng)絡(luò)服務(wù)都是以負載均衡集群的方式對外提供服務(wù)，隨之集群規(guī)模的擴大，為了滿足集群環(huán)境下程序代碼的批量分發(fā)和更新，我們還需要一個程序代碼發(fā)布系統(tǒng)，其中文件同步現(xiàn)在用Filesync，也可以用Rsync。代碼發(fā)布系統(tǒng)部署如圖2-8-1所示。代碼發(fā)布系統(tǒng)的作用： 1) 生產(chǎn)環(huán)境的服務(wù)器以虛擬主機方式提供服務(wù)，不需要開發(fā)人員介入維護和直接操作，提供發(fā)布系統(tǒng)可以實現(xiàn)不需要登陸服務(wù)器就能把程序分發(fā)到目標服務(wù)器。 2) 我們要實現(xiàn)內(nèi)部開發(fā)、內(nèi)部測試、生產(chǎn)環(huán)境測試、生產(chǎn)環(huán)境發(fā)布的4個開發(fā)階段的管理，發(fā)布系統(tǒng)可以介入各個階段的代碼發(fā)布。 3) 我們需要實現(xiàn)源代碼管理和版本控制，SVN可以實現(xiàn)該需求。 圖2-8-1代碼發(fā)布系統(tǒng)部署圖 5 數(shù)據(jù)庫分布式結(jié)構(gòu)圖 6 數(shù)據(jù)庫存儲說明 編號 數(shù)據(jù)庫 數(shù)據(jù) 備注 1 核心 業(yè)務(wù) 核心業(yè)務(wù)總DB 1、所有商品及商品相關(guān)的信息 2、所有訂單信息 3、結(jié)算信息 4、店鋪信息 5、機構(gòu)信息 6、供應(yīng)商信息 其中商品包括如下： 1、總供應(yīng)商商品 2、省供應(yīng)商商品 3、店鋪自銷商品 4、3S商品 商品DB 所有商品及商品相關(guān)的信息 商品讀寫都來自于該庫，但每一個更新都會同步到核心業(yè)務(wù)總DB 訂單DB 所有的訂單以及與訂單相關(guān)的信息 訂單讀寫都來自于該庫，但每一個更新都會同步到核心業(yè)務(wù)總DB 結(jié)算DB 所有結(jié)算需要的信息以及結(jié)算結(jié)果 結(jié)算讀寫都來自于該庫，但每一個更新都會同步到核心業(yè)務(wù)總DB 2 會員DB 所有的會員身份及驗證信息 獨立但支持單點登錄 3 評論DB 所有商品的評論信息 獨立于核心系統(tǒng) 4 曬單DB 所有會員發(fā)布的曬單信息 獨立于核心系統(tǒng) 5 流量統(tǒng)計DB 對網(wǎng)站各個頁面訪問跟蹤記錄以及統(tǒng)計信息 獨立于核心系統(tǒng) 6 廣告DB 網(wǎng)站上的所有廣告位與廣告信息 獨立于核心系統(tǒng) 7 A市分站DB A市下轄店鋪上架正常顯示的商品信息 數(shù)據(jù)從總的核心業(yè)務(wù)DB推送過來的商品信息 8 B市分站DB B市下轄店鋪上架正常顯示的商品信息 數(shù)據(jù)從總的核心業(yè)務(wù)DB推送過來的商品信息 9 ...... ...... ...... 10 N市分站DB C市下轄店鋪上架正常顯示的商品信息 數(shù)據(jù)從總的核心業(yè)務(wù)DB推送過來的商品信息