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

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

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