高并發(fā)平臺架構規(guī)劃方案設計說明

1、編號：版本：高并發(fā)平臺架構規(guī)劃方案V1.0起草人：田朝山起草時間：2013年01月08日審核人：審核時間：修改情況記錄:序號修改模塊名稱修改容修改人修改人名稱1231 概述 1.1 簡述本文檔針對 okgohome 項目的特點，根據(jù)項目各個階段的發(fā)展情況，在系統(tǒng) 不調整或微調整的情況下逐步提升整體吞吐量以適應項目的快速發(fā)展。 其中包括 各個階段項目架構部署規(guī)劃。1.2 設計目標A. 快速的響應能力在各種情況下， 能夠快速響應用戶請求； 具備可靠地容災能力， 部分系統(tǒng)問 題不影響整體系統(tǒng)的正常運行。將停止服務時間降低到最低甚至是不間斷服務。B. 可伸縮性的系統(tǒng)體系 隨著訪問的增加，系統(tǒng)具備良好的

2、伸縮能力。其中包括硬件與軟件兩部分：1）硬件：Web!務器集群，緩存服務器集群，文件服務器集群，數(shù)據(jù)庫服務 器等集群。各個群集之間負載均衡， 任何一個集群由于資源不足出現(xiàn)瓶頸的時候， 只要根據(jù)需要添加一個服務器節(jié)點，做簡單的配置就能達到擴展的目的。2）軟件：整個軟件應用系統(tǒng)縱向分割， 按照模塊劃分， 各個模塊即相互獨立， 又可以無縫結合。 如果需要擴展一個模塊， 只要做獨立開發(fā)， 無需該原有系統(tǒng)的 代碼，只要做簡單的配置就能結合在已經(jīng)，并對該模塊管理。C. 安全可靠的系統(tǒng)為保證的正常運行， 用戶數(shù)據(jù)的高度安全， 系統(tǒng)考慮了多種安全策略 （網(wǎng)絡 安全、系統(tǒng)安全、各子系統(tǒng)安全、子系統(tǒng)模塊安全、回話

3、期間安全等） 。系統(tǒng)具 有7X 24小時的運行能力，并且具有系統(tǒng)災難的快速恢復能力，及數(shù)據(jù)安全的保 證。D. 易管理的體系架構整個系統(tǒng)、服務的狀態(tài)處于一個實時的監(jiān)控之下。其中包括：配置管理、故障性能檢測、代碼發(fā)布等：1) 配置管理：可以通過統(tǒng)一的管理系統(tǒng)，對整個運行環(huán)境進行界面配置管理。 同類集群可以批量操作。2) 性能監(jiān)測：通過統(tǒng)一的監(jiān)控系統(tǒng)對不同類型的服務器或集群分別監(jiān)測， 根據(jù) 監(jiān)測報表實時決策優(yōu)化方案。3) 代碼發(fā)布 : 如果擴展模塊開發(fā)完，只要通過發(fā)布系統(tǒng)發(fā)布到指定的服務器， 或某一類服務器。1.3 設計原則1) 高可用性：將停止服務時間降低到最低甚至是不間斷服務；2) 可擴展性：隨

4、著訪問的增加，系統(tǒng)具備良好的伸縮能力；3) 可視性：系統(tǒng)、服務的狀態(tài)處于一個實時的監(jiān)控之下；4) 高性能高可靠性：經(jīng)過優(yōu)化的體系結構及合理的備份策略；5) 安全性：結構上的安全及主機的安全策略；6) 易維護性：通過簡單的操作就能維護龐大的集群系統(tǒng) ;7) 低成本：前期盡量在有限的硬件資源下，利用軟件提高性能。1.4 讀者對象 該文檔的主要讀者對象：項目經(jīng)理、架構師、服務器維護人員等。2 項目分析 項目特點如下：1) 高并發(fā)，初期雖然PV比較低，但隨著快速發(fā)展pv增長很快;2) 數(shù)據(jù)實時性要求高；3) 數(shù)據(jù)正確性要求高;4) 大多數(shù)頁面屬于動態(tài)頁面;5) 需要大量商品圖片展示;6) 用戶通過搜索

5、引擎、廣告、類目導航尋找商品;7) 讀多寫少，比例超過 10:18) 賣家相關數(shù)據(jù)量比較大，比如商品數(shù)、評價數(shù)。3 架構遵循規(guī)則 1）能分拆的獨立應用，盡量分割開來；2）獨立應用有程序與數(shù)據(jù)庫組成；3）程序有靜態(tài)文件或動態(tài)文件組成；4）數(shù)據(jù)庫有主數(shù)據(jù)庫（專門用于寫）與從數(shù)據(jù)庫（專門用于讀）組成，其中主數(shù) 據(jù)庫中的數(shù)據(jù)會實時同步到從數(shù)據(jù)庫；5）頻繁調用的動態(tài)數(shù)據(jù)能加入緩存；6）數(shù)據(jù)庫大到影響檢索效率是，必須橫向分割。如 :用戶表已經(jīng)相當大， ID 能整 除 2 的放在 userinfo2 ， ID 能整除 3 的放在 userinfo3 ， ID 能整除 4 的放在 userinfo4 ，ID

6、能整除 5 的放在 userinfo5 等，把一大表分成 4小表。7）數(shù)據(jù)庫、文件、緩存等服務器能負載均衡；8）要求不及時，能批處理的盡量獨立批量處理。4 系統(tǒng)架構項目初期由于壓力較小，應用服務、數(shù)據(jù)庫、備份分別部署在獨立的服務器 上，甚至都部署在同一臺服務器上。但整個系統(tǒng)前期的開發(fā)需要按照以下負載方 式考慮設計分布式部署，方便隨著項目負荷增大，評估出負荷點，能很容易在不 改變程序的基礎上，添加硬件設備就能緩解整體負荷。由于前期節(jié)點比較少，“4.7服務器性能檢測系統(tǒng)”、“4.8服務器管理系統(tǒng)”、 “4.8代碼分發(fā)系統(tǒng)”等暫時不考慮，具體開發(fā)時間根據(jù)項目發(fā)展情況而定。4.1子系統(tǒng)結構注：其中前臺

7、的每個分站旗下的 App與分站相同，這里進用分站做個舉例說明4.2 App應用系統(tǒng)包含web頁面的各App應用，頁面類型分為：靜態(tài)頁面，動態(tài)頁面。靜態(tài)頁 面對I/O要求比較高；動態(tài)頁面對存、CPU等要求比較高。因此靜態(tài)頁面與動態(tài) 頁面分開部署在具有針對性的服務器上以提高性能。Web服務器分：靜態(tài) Web服務器，動態(tài) Web服務器。其中當客戶訪問靜態(tài)頁 面的時候，僅訪問靜態(tài)web服務器，靜態(tài)Web服務器根據(jù)需要從文件服務器上提 取所必須的css，js，圖片等文件；而當用戶訪問動態(tài)頁面時，動態(tài) Web服務器 根據(jù)需要先去緩存服務器上檢查是否有需要的數(shù)據(jù)，如果有，則直接從緩存服務器中取，否則從數(shù)據(jù)庫

8、中取相應的數(shù)據(jù)，同時添加到緩存服務器上（不是所有的 數(shù)據(jù)都加到緩存服務器中，主要加那些不頻繁變化的數(shù)據(jù)），根據(jù)需要從文件服務器上提取所必須的css，js，圖片等文件。如圖2-1-1所示。1件服務器（圖片，下載等）數(shù)據(jù)庫服務器群集We服務器群集與入主庫讀出動態(tài)Wei服務器更新A緩存服務器圖2-1-1 App應用系統(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ù)庫訪問的壓力， 直接訪問速度

9、快， 用戶體驗良好， 而且不 容易屏蔽；2) 容非常穩(wěn)定， 容易被搜索引擎收錄， 并且容易獲得較好排名； 搜索引擎也 會經(jīng)常光顧；3) 提高安全性，防止不良代碼注入；4) 對服務器要求不高。因此對于不頻繁變化的容盡量靜態(tài)化，同時針對靜態(tài)頁面定制相應的服務 器，這樣不但能提高的訪問速度，同時能節(jié)省服務器資源。動態(tài)網(wǎng)頁的網(wǎng)址形式通常是以 .jsp 、.php 、.aspx 、 .asax 、.shtml 、 .ascx 等為后后綴的。動態(tài)頁面主要用于人機交互(如：論壇，評論等) ，實時效率比 較高。動態(tài)頁面不但服務器要求比較高， 同時需要頻繁與數(shù)據(jù)庫交互， 給數(shù)據(jù)庫 服務器帶來很大的壓力。 因此只

10、有中頻繁變化的部分，以及管理系統(tǒng)需要做成 動態(tài)頁面隨著訪問量的不斷增加， 即使靜態(tài)頁面與動態(tài)頁面分開， 分別部署在不同的 服務器上，也難于承受那么大的流量。如果一臺服務器難于負荷靜態(tài)服務的時候， 則根據(jù)需要添加多臺服務器一起 承載靜態(tài)服務負荷。為了讓多臺服務器更好的協(xié)同工作， 且隨著集群負荷的增加， 可以根據(jù)需要添加服務器以達到分擔負荷的作用， 則利用網(wǎng)絡負載平衡器把這些 服務器群集起來。動態(tài)服務業(yè)可以按照這樣的均衡方式達到提高性能與擴展的效 果。如圖 2-1-2 所示。0客戶端動態(tài)Web艮務器集群負載均衡圖2-1-2 App應用系統(tǒng)負載均衡其中Windows2003網(wǎng)絡負載均衡原理：是按照通

11、訊量來分配的?？梢耘渲?成各個主機均分；也可以給好點的機器多分點負荷量，給差點的機器分少點負荷 量（負荷量：各主機處理的通信量/總的通訊量）。也可以指定各個主機的優(yōu)先 級，按照優(yōu)先級確定那個主機處理接收到的通訊。而整個群集對外表現(xiàn)為一個 IP，一個域名只要綁定到該IP上，則通過該域名的請求都會分發(fā)到群集中的各 個服務器上一起工作。當規(guī)模越來越大的情況下，即使用群集能解決性能問題，但所有的服務都部 署在一個群集中，一個群集就有成百上千個站點很難管理。因此在到一定規(guī)模的 時候，就需要按照模塊應用的不同進行縱向分割。 然后根據(jù)各個應用的訪問量實 際情況作負載均衡以提升整體的性能。靜態(tài)服務，動態(tài)服務都

12、可以按照這樣的方 式部署。其中動態(tài)服務縱向分割不僅方便了站點管理， 更深遠的意義在于為數(shù)據(jù) 庫負載提供了方便。因此動態(tài)服務器更應該盡量按照應用的不同縱向分割。如圖 2-1-3所示。靜態(tài)Web艮務器1靜態(tài)web艮務器3緩存服務器數(shù)據(jù)庫服務器可以有很多動 態(tài)We服務器 集群靜態(tài)we服務器4靜態(tài)We服務 器集群動 器集群靜態(tài)We服務器5Q靜態(tài)We服務器2動態(tài)Web服務 器集群1圖2-1-3 App應用負載均衡（動態(tài)應用縱向分割）4.3數(shù)據(jù)庫系統(tǒng)大型的性能瓶頸主要來自于動態(tài)服務， 而影響動態(tài)服務性能關鍵在于數(shù)據(jù)庫 能否及時響應。各個動態(tài)應用規(guī)模越大，響應的數(shù)據(jù)庫就越臃腫，響應的速度就 越慢。所以動態(tài)服

13、務部分響應的數(shù)據(jù)庫的縱向分割不但便于管理，還能提升數(shù)據(jù)庫的性能，能達到數(shù)據(jù)庫負載均衡的效果。由于部分數(shù)據(jù)庫在沒有借助第三方軟件或硬件情況下，自身不能負載均衡。就當前形勢還沒必要用到第三方負載均衡工具的情況下，采用如下方案：1）讀寫分離。由于讀多寫少，大部分時間消耗在查詢上，因此讓主庫專門用于寫，從庫專門用于讀（讀庫可以有很多個，以減輕單個讀庫的負擔） 同時同步寫庫與讀庫的數(shù)據(jù)；如圖 2-2-1所示。主庫讀出丿緩存服務器0公網(wǎng)緩存服務器服務器DBN制0客戶端o 公網(wǎng)客戶端r-主從庫分離圖2-2-1數(shù)據(jù)庫主從分離2）縱向分割就是，不同的應用可以分到不同的 DB中，不同的實例中。這種發(fā)放不但效率高，

14、實施也很方便。如圖 2-2-2所示文件服務器數(shù)據(jù)庫服務器群集文件服務器 （圖片，下載等）前臺Web艮務器群集靜態(tài)Web艮務器動態(tài)Web艮務器數(shù)據(jù)庫服務器采用縱向分割Wel應用1Wei應用2We應用N9DB20DB1讀寫分離橫向分割主庫寫庫從庫讀庫We應用2讀寫分離讀寫分離+橫向分割分區(qū)N主庫從庫N讀寫分離+橫向分割DBN圖2-2-2數(shù)據(jù)庫分布式部署3）橫向分割就是，某些應用不能分割，比如用戶注冊，但是用戶表會非常 大，可以把大表分成小表，可以采用表分區(qū)，數(shù)據(jù)存儲在不同文件上， 然后再部署到獨立物理服務器增加10吞吐以改善讀寫性能，表分區(qū)的另 外一個優(yōu)勢可以增加數(shù)據(jù)查詢速度。4）根據(jù)需要可以綜合

15、使用以上三種方法，可以實現(xiàn)無限極的擴展。如圖2-2-3示?？v向分離We應用1，橫向分割DB1DB2We應用N圖2-2-3數(shù)據(jù)庫負載均衡（綜合用法）如果某個應用的訪問量通過上面的方式綜合使用都無法負載時候，再采用第三方的負載均衡。4.4緩存系統(tǒng)大型的吞吐率越大，尤其是動態(tài)服務部分，使數(shù)據(jù)庫的壓力也越來越大。如果數(shù)據(jù)庫壓力過大，嚴重影響的整體性能。使用緩存能有效應對大負載，減少數(shù) 據(jù)庫的壓力，并顯著提高多層應用程序的性能。采用業(yè)主流的 MemcacheMemcache是開源的分布式 cache系統(tǒng)。Memcached 的緩存是一種分布式的，可以讓不同主機上的多個用戶同時訪問，因此解決了共享存只能單

16、機應用的局限，更不會出現(xiàn)使用數(shù)據(jù)庫做類似事情的時候， 磁盤開 銷和阻塞的發(fā)生。主要應用App應用系統(tǒng)與數(shù)據(jù)庫系統(tǒng)之間根據(jù)各個應用的實際情況配置多（圖片，Js， Css等）Wei應用1緩存器集群Wei應用2緩存器集群臺緩存服務器。如圖2-3-2所示根據(jù)Wet應用 的實際情況安 排相應的緩存 服務器群集圖2-3-1 Memcache緩存部署圖4.5文件存儲系統(tǒng)有些容，既沒必要存放在數(shù)據(jù)庫里，也不適合存放在緩存中，如圖片，下載 文件，js，css等數(shù)據(jù)。當有海量容存放在文件系統(tǒng)中時，為了保證高并發(fā)請求 下文件系統(tǒng)能夠及時的相應請求，通過以下方式來提高文件系統(tǒng)的整體性能：1）按照文件類型的不同，分別部

17、署在不同的服務器，甚至服務器集群上。如 圖片文件可以不是在圖片服務器上，當單臺圖片服務器承受不了當前的負 荷的時候，可以更具時間情況添加多臺圖片服務器通過 NBL群集起來協(xié)同 工作。2）當多臺服務器通過負載平衡都難于承受某類文件負荷的時候，可以按照該類文件所屬的App應用縱向劃分。如“ web應用1”的圖片文件單獨部署 在單臺服務器上，甚至是多臺服務器集群上。3）為了將來易于擴展、移植，綜合使用以上兩種方法。先把各種文件按照App應用劃分，再把文件按照類型劃分。即使所有的文件部署到一臺機器 上,只要各個web應用中的各種類型的文件通過獨立的域名調用，當以后某種App應用的的負荷很大時，或某種A

18、pp應用中的某種類型文件負荷很 大時，也可以輕松移植到新添加的服務器上， 只需要把相應域名解析到相 應的服務器IP上即可。如圖2-4-1所示。數(shù)據(jù)庫服務器圖2-4-1文件分布式不是針對各Web模 塊提供下載緩存服務器客戶端L -針對各We模 塊提供文件4.6 服務器性能監(jiān)控系統(tǒng)在規(guī)模不大，服務器只有若干臺的情況下，運維人員可以逐臺服務器通過Windows任務管理器查看服務器資源使用情況，而這樣只能看到CPU存以及硬盤等的使用情況，其他的（如：IIS的吞吐率，當前的請求數(shù)等）都難于獲取，只能等錯誤發(fā)生了才能知道采取排查，是運維人員很被動。但隨著規(guī)模的不斷擴大，整個所基于的服務器集群也在不斷擴大。

19、當服務器 擴展到成百上千臺的時候，手工去逐臺采集已經(jīng)很不現(xiàn)實。因此必須通過專門的 系統(tǒng)針對性的自動對各個服務器的信息采集，繪制成報表供運維實時掌握各個服 務的現(xiàn)狀。監(jiān)控系統(tǒng)的部署如圖 2-6-1所示。生產(chǎn)環(huán)境根據(jù)所監(jiān)測Web， DB文件服務器 等的資源情況來 決策是否對整體 性能擴展Web服務器數(shù)據(jù)庫服務器管理員監(jiān)控服監(jiān)控客戶端文件服務器圖2-6-1服務器性能監(jiān)控系統(tǒng)4.7服務器管理系統(tǒng)同“服務器性能監(jiān)控系統(tǒng)”類似。在規(guī)模不大，服務器只有若干臺的情況下, 運維人員可以逐臺服務器手工配置，而且很難避免手誤。但隨著訪問流量的不斷增加，網(wǎng)絡服務都是以負載均衡集群的方式對外提供 服務，隨之集群規(guī)模的擴

20、大，原來基于單機的服務器管理模式已經(jīng)不能夠滿足需 求，新的需求必須能夠集中式的、分組的、批量的、自動化的對服務器進行管理, 能夠批量化的執(zhí)行計劃任務。分布式服務器管理系統(tǒng)的部署如圖2-7-1所示。生產(chǎn)環(huán)境4.8代碼分發(fā)系統(tǒng)隨著訪問流量的不斷增加，網(wǎng)絡服務都是以負載均衡集群的方式對外提供服 務，隨之集群規(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)境的服務器以虛擬主機方式提供服務，不需要開發(fā)人員介入 維護和直接操作，提供發(fā)布系統(tǒng)可以實現(xiàn)不需要登陸服務器就能把 程序分發(fā)到目標服務器。2）我們要實現(xiàn)部開發(fā)、部測試、生產(chǎn)環(huán)境測試、生產(chǎn)環(huán)境發(fā)布的4個開發(fā)階段的管理，發(fā)布系統(tǒng)可以介入各個階段的代碼發(fā)布。3）我們需要實現(xiàn)源代碼管理和版本控制，SVN可以實現(xiàn)該需求。開發(fā)環(huán)境測試環(huán)境生產(chǎn)環(huán)境VSS風務器開發(fā)數(shù)據(jù)庫服 務器