重慶郵電大學(xué)實(shí)驗(yàn)指導(dǎo)書-應(yīng)用系統(tǒng)架構(gòu)

編制單位：計(jì)算機(jī)專業(yè)實(shí)驗(yàn)中心編制人：李鴻健段小林編制時(shí)間：2017年5月

前言一、課程介紹《應(yīng)用系統(tǒng)架構(gòu)》是我校計(jì)算機(jī)工科專業(yè)本科學(xué)生的一門主要的專業(yè)選修課程，主要介紹應(yīng)用系統(tǒng)架構(gòu)基本概念、基本原理和方法，也是計(jì)算機(jī)科學(xué)技術(shù)的一個(gè)重要領(lǐng)域。學(xué)生通過本課程的實(shí)驗(yàn)，一方面培養(yǎng)系統(tǒng)解決方案設(shè)計(jì)、軟件架構(gòu)設(shè)計(jì)，模塊設(shè)計(jì)等能力，培養(yǎng)設(shè)計(jì)領(lǐng)域尖端人才。另一方面培養(yǎng)學(xué)生開展前沿課題研究的能力，搜索文獻(xiàn)，提出問題，激發(fā)創(chuàng)新思維，開展科學(xué)研究的能力。二、課程要求根據(jù)課程的性質(zhì)、任務(wù)、要求及學(xué)習(xí)的對(duì)象，學(xué)生進(jìn)行的實(shí)踐應(yīng)完成2個(gè)大題，一是對(duì)系統(tǒng)架構(gòu)前沿的探索研究，包括軟件危機(jī)，軟件重用，軟件產(chǎn)品線和SOA方法；二是設(shè)計(jì)一個(gè)大型系統(tǒng)的完整架構(gòu)方案，內(nèi)容包括：功能目標(biāo)決策分析，物理視圖，邏輯視圖，開發(fā)視圖和過程視圖，非功能目標(biāo)分析等。必須首先完成實(shí)驗(yàn)任務(wù)書規(guī)定的任務(wù)。通過實(shí)驗(yàn)學(xué)生應(yīng)達(dá)到下列基本要求：學(xué)生應(yīng)能設(shè)計(jì)系統(tǒng)架構(gòu)，進(jìn)行結(jié)構(gòu)化需求分析，找出關(guān)鍵功能，設(shè)計(jì)五種視圖對(duì)架構(gòu)進(jìn)行描述，掌握SOA方法。學(xué)生應(yīng)了解前沿應(yīng)用系統(tǒng)架構(gòu)研究進(jìn)展，研究科學(xué)家的最新觀點(diǎn)，提出自己觀點(diǎn)，撰寫一篇以系統(tǒng)架構(gòu)相關(guān)的科研論文。能根據(jù)需要選學(xué)參考書，查閱手冊(cè)，通過獨(dú)立思考，深入鉆研有關(guān)問題，學(xué)會(huì)自己獨(dú)立分析問題、解決問題，具有一定的創(chuàng)新能力。能正確使用實(shí)驗(yàn)環(huán)境，掌握測(cè)試原理，明確實(shí)驗(yàn)?zāi)康募叭蝿?wù)，課前做好預(yù)習(xí)，及時(shí)發(fā)現(xiàn)及解決實(shí)驗(yàn)中的問題。能獨(dú)立撰寫實(shí)驗(yàn)報(bào)告。報(bào)告要求：分析設(shè)計(jì)思想，繪出流程圖，編制程序，準(zhǔn)確分析實(shí)驗(yàn)結(jié)果，解答思考題，以及本次實(shí)驗(yàn)的心得體會(huì)。計(jì)算機(jī)專業(yè)實(shí)驗(yàn)中心2017年5月

目錄實(shí)驗(yàn)1系統(tǒng)架構(gòu)基本理論 5實(shí)驗(yàn)2系統(tǒng)架構(gòu)設(shè)計(jì)原則 6實(shí)驗(yàn)3CAP基本理論 8實(shí)驗(yàn)4CAP的延伸BASE理論 10實(shí)驗(yàn)5軟件重構(gòu)模式 12實(shí)驗(yàn)6軟件產(chǎn)品線 13實(shí)驗(yàn)7負(fù)載均衡算法 18實(shí)驗(yàn)8負(fù)載均衡模式 21實(shí)驗(yàn)9無(wú)共享架構(gòu) 23實(shí)驗(yàn)10分布式計(jì)算架構(gòu) 26實(shí)驗(yàn)11SOA架構(gòu)設(shè)計(jì) 29實(shí)驗(yàn)12ED-SOA架構(gòu) 33實(shí)驗(yàn)13高并發(fā)系統(tǒng)架構(gòu) 37實(shí)驗(yàn)14高可用系統(tǒng)架構(gòu) 41實(shí)驗(yàn)15五視圖法架構(gòu)設(shè)計(jì)-用例分析 45實(shí)驗(yàn)16五視圖法架構(gòu)設(shè)計(jì)-邏輯架構(gòu) 48實(shí)驗(yàn)17五視圖法架構(gòu)設(shè)計(jì)-開發(fā)架構(gòu) 50實(shí)驗(yàn)18五視圖法架構(gòu)設(shè)計(jì)-數(shù)據(jù)架構(gòu) 52實(shí)驗(yàn)19五視圖法架構(gòu)設(shè)計(jì)-運(yùn)行架構(gòu) 55實(shí)驗(yàn)20五視圖法架構(gòu)設(shè)計(jì)-物理架構(gòu) 57實(shí)驗(yàn)21領(lǐng)域模型分析法基礎(chǔ)與案例 59實(shí)驗(yàn)22大規(guī)模軟件開發(fā)基礎(chǔ) 61實(shí)驗(yàn)23大規(guī)模軟件開發(fā)-案例分析 63實(shí)驗(yàn)24基于云和大數(shù)據(jù)的軟件架構(gòu)基礎(chǔ) 66實(shí)驗(yàn)25基于云和大數(shù)據(jù)的軟件架構(gòu)基礎(chǔ)-案例分析 68實(shí)驗(yàn)26遺留系統(tǒng)的改造基礎(chǔ) 70實(shí)驗(yàn)27遺留系統(tǒng)的改造-案例分析 72實(shí)驗(yàn)28主流應(yīng)用架構(gòu)案例剖析 74實(shí)驗(yàn)29應(yīng)用架構(gòu)方案設(shè)計(jì) 77

實(shí)驗(yàn)1系統(tǒng)架構(gòu)基本理論一、實(shí)驗(yàn)?zāi)康?．了解系統(tǒng)架構(gòu)基本理論。2．了解系統(tǒng)架構(gòu)與軟件工程的關(guān)系。3.了解系統(tǒng)架構(gòu)發(fā)展前沿二、實(shí)驗(yàn)學(xué)時(shí) 2學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容1.查閱文獻(xiàn)分析總結(jié)系統(tǒng)架構(gòu)的發(fā)展歷程。2.系統(tǒng)架構(gòu)的最新發(fā)展趨勢(shì)總結(jié)。3．小組討論大數(shù)據(jù)時(shí)代系統(tǒng)架構(gòu)發(fā)展的新方向。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫科研論文報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)2系統(tǒng)架構(gòu)設(shè)計(jì)原則一、實(shí)驗(yàn)?zāi)康?．了解系統(tǒng)架構(gòu)設(shè)計(jì)原則。2.了解系統(tǒng)架構(gòu)設(shè)計(jì)發(fā)展前沿二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容實(shí)驗(yàn)任務(wù)：查閱文獻(xiàn)分析系統(tǒng)架構(gòu)設(shè)計(jì)原則，系統(tǒng)架構(gòu)的最新發(fā)展趨勢(shì)總結(jié)。小組討論以下系統(tǒng)架構(gòu)設(shè)計(jì)原則為架構(gòu)設(shè)計(jì)帶來(lái)的好處及避免那些風(fēng)險(xiǎn)，形成觀點(diǎn)，撰寫報(bào)告。1.單一職責(zé)原則（SRP）：一個(gè)優(yōu)良的系統(tǒng)設(shè)計(jì)，強(qiáng)調(diào)模塊間保持低耦合、高內(nèi)聚的關(guān)系，在面向?qū)ο笤O(shè)計(jì)中這條規(guī)則同樣適用，所以面向?qū)ο蟮牡谝粋€(gè)設(shè)計(jì)原則就是：?jiǎn)我宦氊?zé)原則（SRP，SingleResponsibilityPrinciple）。單一職責(zé)，強(qiáng)調(diào)的是職責(zé)的分離，在某種程度上對(duì)職責(zé)的理解，構(gòu)成了不同類之間耦合關(guān)系的設(shè)計(jì)關(guān)鍵，因此單一職責(zé)原則或多或少成為設(shè)計(jì)過程中一個(gè)必須考慮的基礎(chǔ)性原則。關(guān)于單一職責(zé)原則，其核心的思想是：一個(gè)類，最好只做一件事，只有一個(gè)引起它變化的原因。單一職責(zé)原則可以看作是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申，將職責(zé)定義為引起變化的原因，以提高內(nèi)聚性來(lái)減少引起變化的原因。職責(zé)過多，可能引起它變化的原因就越多，這將導(dǎo)致職責(zé)依賴，相互之間就產(chǎn)生影響，從而極大的損傷其內(nèi)聚性和耦合度。單一職責(zé)，通常意味著單一的功能，因此不要為類實(shí)現(xiàn)過多的功能點(diǎn)，以保證實(shí)體只有一個(gè)引起它變化的原因。因此，SRP原則的核心就是要求對(duì)類的改變只能是一個(gè)，對(duì)于違反這一原則的類應(yīng)該進(jìn)行重構(gòu)，例如以Fa?ade模式或Proxy模式分離職責(zé)，通過基本的方法ExtractInterface、ExtractClass和ExtractMethod進(jìn)行梳理。2．開放-封閉原則（OCP）無(wú)論如何，開放封閉原則（OCP，OpenClosedPrinciple）都是所有面向?qū)ο笤瓌t的核心。軟件設(shè)計(jì)本身所追求的目標(biāo)就是封裝變化、降低耦合，而開放封閉原則正是對(duì)這一目標(biāo)的最直接體現(xiàn)。其他的設(shè)計(jì)原則，很多時(shí)候是為實(shí)現(xiàn)這一目標(biāo)服務(wù)的，例如以Liskov替換原則實(shí)現(xiàn)最佳的、正確的繼承層次，就能保證不會(huì)違反開放封閉原則。關(guān)于開發(fā)封閉原則，其核心的思想是：軟件實(shí)體應(yīng)該是可擴(kuò)展，而不可修改的。也就是說，對(duì)擴(kuò)展是開放的，而對(duì)修改是封閉的。因此，開放封閉原則主要體現(xiàn)在兩個(gè)方面：對(duì)擴(kuò)展開放，意味著有新的需求或變化時(shí)，可以對(duì)現(xiàn)有代碼進(jìn)行擴(kuò)展，以適應(yīng)新的情況。對(duì)修改封閉，意味著類一旦設(shè)計(jì)完成，就可以獨(dú)立完成其工作，而不要對(duì)類進(jìn)行任何修改?！靶枨罂偸亲兓?、“世界上沒有一個(gè)軟件是不變的”，這些言論是對(duì)軟件需求最經(jīng)典的表白。從中透射出一個(gè)關(guān)鍵的意思就是，對(duì)于軟件設(shè)計(jì)者來(lái)說，必須在不需要對(duì)原有的系統(tǒng)進(jìn)行修改的情況下，實(shí)現(xiàn)靈活的系統(tǒng)擴(kuò)展。而如何能做到這一點(diǎn)呢？只有依賴于抽象。實(shí)現(xiàn)開放封閉的核心思想就是對(duì)抽象編程，而不對(duì)具體編程，因?yàn)槌橄笙鄬?duì)穩(wěn)定。讓類依賴于固定的抽象，所以對(duì)修改就是封閉的；而通過面向?qū)ο蟮睦^承和對(duì)多態(tài)機(jī)制，可以實(shí)現(xiàn)對(duì)抽象體的繼承，通過覆寫其方法來(lái)改變固有行為，實(shí)現(xiàn)新的擴(kuò)展方法，所以對(duì)于擴(kuò)展就是開放的。這是實(shí)施開放封閉原則的基本思路，同時(shí)這種機(jī)制是建立在兩個(gè)基本的設(shè)計(jì)原則的基礎(chǔ)上，這就是Liskov替換原則和合成/聚合復(fù)用原則。關(guān)于這兩個(gè)原則，我們?cè)诒緯钠渌糠侄加邢鄳?yīng)的論述，在應(yīng)用反思部分將有深入的討論。對(duì)于違反這一原則的類，必須進(jìn)行重構(gòu)來(lái)改善，常用于實(shí)現(xiàn)的設(shè)計(jì)模式主要有TemplateMethod模式和Strategy模式。而封裝變化，是實(shí)現(xiàn)這一原則的重要手段，將經(jīng)常發(fā)生變化的狀態(tài)封裝為一個(gè)類。3.里氏代換原則（LSP）4.依賴倒轉(zhuǎn)原則(DIP)要依賴抽象，不要依賴具體。5.迪米特法則(LoD)一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象有盡可能少的了解。6.接口隔離原則(ISP)使用多個(gè)專門的接口比適用單一的接口要好。7.合成/聚合復(fù)用原則(CARP)要盡量使用合成/聚合，盡量不要使用繼承。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫科研論文報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)3CAP基本理論一、實(shí)驗(yàn)?zāi)康?．了解CAP基本理論。2．了解CAP的發(fā)展歷程。3.了解數(shù)據(jù)庫(kù)事務(wù)架構(gòu)發(fā)展前沿二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容1.查閱文獻(xiàn)分析CAP的發(fā)展歷程。2.數(shù)據(jù)庫(kù)事務(wù)架構(gòu)的最新發(fā)展趨勢(shì)總結(jié)。3．小組討論如何構(gòu)建不可變模型避免CAP的復(fù)雜性。1985年Lynch證明了異步通信中不存在任何一致性的分布式算法（FLPImpossibility）的同時(shí)，人們就開始尋找分布式系統(tǒng)設(shè)計(jì)的各種因素。一致性算法既然不存在，但若能找到一些設(shè)計(jì)因素，并進(jìn)行適當(dāng)?shù)娜∩嵋宰畲笙薅葷M足實(shí)現(xiàn)系統(tǒng)需求成為當(dāng)時(shí)的重要議題。比如，在CAP之前研究者就已經(jīng)發(fā)現(xiàn)低延遲和順序一致性不可能同時(shí)被滿足。2000年，EricBrewer教授在PODC的研討會(huì)上提出了一個(gè)猜想：一致性、可用性和分區(qū)容錯(cuò)性三者無(wú)法在分布式系統(tǒng)中被同時(shí)滿足，并且最多只能滿足其中兩個(gè)！這個(gè)猜想首次把一致性、可用性和分區(qū)容錯(cuò)三個(gè)因素提煉出來(lái)作為系統(tǒng)設(shè)計(jì)的重要特征，斷言用此三者可以劃分所有的分布式系統(tǒng)，并指明這三個(gè)特征之間的不可能性關(guān)系。Brewer猜想比單純的“低延遲和順序一致性不能被同時(shí)滿足”的結(jié)論更具體，對(duì)實(shí)際系統(tǒng)的構(gòu)建也更具有可操作性！Brewer教授當(dāng)時(shí)想象的分布式場(chǎng)景是webservice，一組websevrice后臺(tái)運(yùn)行著眾多的server，對(duì)service的讀寫會(huì)反應(yīng)到后臺(tái)的server集群，并對(duì)CAP進(jìn)行了定義：C（一致性）：所有的節(jié)點(diǎn)上的數(shù)據(jù)時(shí)刻保持同步A（可用性）：每個(gè)請(qǐng)求都能接受到一個(gè)響應(yīng)，無(wú)論響應(yīng)成功或失敗P（分區(qū)容錯(cuò)）：系統(tǒng)應(yīng)該能持續(xù)提供服務(wù)，即使系統(tǒng)內(nèi)部有消息丟失（分區(qū)）高可用、數(shù)據(jù)一致是很多系統(tǒng)設(shè)計(jì)的目標(biāo)，但是分區(qū)又是不可避免的事情：CAwithoutP：如果不要求P（不允許分區(qū)），則C（強(qiáng)一致性）和A（可用性）是可以保證的。但其實(shí)分區(qū)不是你想不想的問題，而是始終會(huì)存在，因此CA的系統(tǒng)更多的是允許分區(qū)后各子系統(tǒng)依然保持CA。CPwithoutA：如果不要求A（可用），相當(dāng)于每個(gè)請(qǐng)求都需要在Server之間強(qiáng)一致，而P（分區(qū)）會(huì)導(dǎo)致同步時(shí)間無(wú)限延長(zhǎng)，如此CP也是可以保證的。很多傳統(tǒng)的數(shù)據(jù)庫(kù)分布式事務(wù)都屬于這種模式。APwihtoutC：要高可用并允許分區(qū)，則需放棄一致性。一旦分區(qū)發(fā)生，節(jié)點(diǎn)之間可能會(huì)失去聯(lián)系，為了高可用，每個(gè)節(jié)點(diǎn)只能用本地?cái)?shù)據(jù)提供服務(wù)，而這樣會(huì)導(dǎo)致全局?jǐn)?shù)據(jù)的不一致性?，F(xiàn)在眾多的NoSQL都屬于此類。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫科研論文報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)4CAP的延伸BASE理論一、實(shí)驗(yàn)?zāi)康?．了解BASE基本理論。2．了解數(shù)據(jù)庫(kù)架構(gòu)中ACID和BASE的區(qū)別與聯(lián)系。3.了解分布式系統(tǒng)BASE理論的發(fā)展前沿二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容針對(duì)以下內(nèi)容進(jìn)行小組討論，提出觀點(diǎn)。一、BASE理論eBay的架構(gòu)師DanPritchett源于對(duì)大規(guī)模分布式系統(tǒng)的實(shí)踐總結(jié)，在ACM上發(fā)表文章提出BASE理論，BASE理論是對(duì)CAP理論的延伸，核心思想是即使無(wú)法做到強(qiáng)一致性（StrongConsistency，CAP的一致性就是強(qiáng)一致性），但應(yīng)用可以采用適合的方式達(dá)到最終一致性（EventualConsitency）。BASE是指基本可用（BasicallyAvailable）、軟狀態(tài)（SoftState）、最終一致性（EventualConsistency）。二、基本可用（BasicallyAvailable）基本可用是指分布式系統(tǒng)在出現(xiàn)故障的時(shí)候，允許損失部分可用性，即保證核心可用。電商大促時(shí)，為了應(yīng)對(duì)訪問量激增，部分用戶可能會(huì)被引導(dǎo)到降級(jí)頁(yè)面，服務(wù)層也可能只提供降級(jí)服務(wù)。這就是損失部分可用性的體現(xiàn)。三、軟狀態(tài)（SoftState）軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會(huì)影響系統(tǒng)整體可用性。分布式存儲(chǔ)中一般一份數(shù)據(jù)至少會(huì)有三個(gè)副本，允許不同節(jié)點(diǎn)間副本同步的延時(shí)就是軟狀態(tài)的體現(xiàn)。mysqlreplication的異步復(fù)制也是一種體現(xiàn)。四、最終一致性（EventualConsistency）最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時(shí)間后，最終能夠達(dá)到一致的狀態(tài)。弱一致性和強(qiáng)一致性相反，最終一致性是弱一致性的一種特殊情況。五、ACID和BASE的區(qū)別與聯(lián)系A(chǔ)CID是傳統(tǒng)數(shù)據(jù)庫(kù)常用的設(shè)計(jì)理念，追求強(qiáng)一致性模型。BASE支持的是大型分布式系統(tǒng)，提出通過犧牲強(qiáng)一致性獲得高可用性。ACID和BASE代表了兩種截然相反的設(shè)計(jì)哲學(xué)，在分布式系統(tǒng)設(shè)計(jì)的場(chǎng)景中，系統(tǒng)組件對(duì)一致性要求是不同的，因此ACID和BASE又會(huì)結(jié)合使用。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫科研論文報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)5軟件重構(gòu)模式一、實(shí)驗(yàn)?zāi)康?．了解軟件重構(gòu)模式基本理論。2．掌握軟件重用形式分類。3.掌握軟件重用分類編輯方法二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容軟件制作中有三種級(jí)別的重用，重用是為了提高效率和降低成本。這是軟件制作的核心目的。1.內(nèi)部重用，即在同一應(yīng)用中能公共使用的抽象塊;2.代碼重用，即將通用模塊組合成庫(kù)或工具集，以便在多個(gè)應(yīng)用和領(lǐng)域都能使用；3.應(yīng)用框架的重用，即為專用領(lǐng)域提供通用的或現(xiàn)成的基礎(chǔ)結(jié)構(gòu)，以獲得最高級(jí)別的重用性。4.基于已有系統(tǒng)，設(shè)計(jì)以上三種級(jí)別的可重用案例。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫科研論文報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)6軟件產(chǎn)品線一、實(shí)驗(yàn)?zāi)康?．了解什么是軟件產(chǎn)品線。2．掌握軟件產(chǎn)品線開發(fā)模式。3.掌握軟件產(chǎn)品線工程方法二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容基于軟件產(chǎn)品線完成針對(duì)單一系統(tǒng)（酒店預(yù)定系統(tǒng)）的面向服務(wù)的分析與設(shè)計(jì)。SoSPL方法的核心是面向服務(wù)的分析與設(shè)計(jì)（ServiceOrientedAnalysisandDesign，SOAD）活動(dòng)。SOAD是一個(gè)新興領(lǐng)域，它涉及到基于業(yè)務(wù)需求來(lái)確定和構(gòu)建服務(wù)。SOAD將服務(wù)視為第一級(jí)實(shí)體，非常類似于處理類和對(duì)象的面向?qū)ο蟮姆治雠c設(shè)計(jì)（ObjectOrientedAnalysisandDesign，OOAD）。OOAD中的典型起點(diǎn)是用例模型，但SOAD中的起點(diǎn)是業(yè)務(wù)流程建模。需求活動(dòng)業(yè)務(wù)流程建模（Businessprocessmodeling，BPM）通常用于說明服務(wù)需求。業(yè)務(wù)流程

是一組執(zhí)行用于實(shí)現(xiàn)某個(gè)目標(biāo)的相關(guān)業(yè)務(wù)任務(wù)。其重點(diǎn)集中于業(yè)務(wù)流程而不是用例。其中沒有對(duì)任何參與者建模，并且重點(diǎn)在于從業(yè)務(wù)角度看到的業(yè)務(wù)流程行為?？梢允褂媒y(tǒng)一建模語(yǔ)言（UnifiedModelingLanguage，UML）活動(dòng)關(guān)系圖對(duì)業(yè)務(wù)流程建模?；顒?dòng)關(guān)系圖對(duì)于在域業(yè)務(wù)建模期間詳細(xì)描繪業(yè)務(wù)流程工作流特別有用。圖1顯示了一個(gè)酒店預(yù)訂流程。該關(guān)系圖中的每個(gè)活動(dòng)都表示一個(gè)包含子活動(dòng)的高級(jí)活動(dòng)。圖1.酒店預(yù)訂流程的UML活動(dòng)關(guān)系圖此階段的產(chǎn)物是一組BPM模型，這些模型以描述業(yè)務(wù)流程行為的UML活動(dòng)關(guān)系圖表示。分析活動(dòng)候選服務(wù)是基于需求模型來(lái)確定的。確定可重用服務(wù)是一個(gè)主要目標(biāo)，因?yàn)榭芍赜眯允敲嫦蚍?wù)的最重要好處之一。一個(gè)業(yè)務(wù)流程模型可以由單個(gè)服務(wù)或由多個(gè)服務(wù)來(lái)實(shí)現(xiàn)。可以分析業(yè)務(wù)流程模型以確定可重用的自主操作。其目標(biāo)是指定滿足所需業(yè)務(wù)流程的最基本操作，以便能夠邏輯地將它們分組到候選服務(wù)中。必須決定是在單個(gè)服務(wù)中集合所有操作，還是將相關(guān)操作分組到不同的服務(wù)中。表1.服務(wù)構(gòu)造條件構(gòu)造型角色abstractservice非具體；未綁定到實(shí)際的服務(wù)實(shí)現(xiàn)applicationservice具體standaloneservice不允許成為某個(gè)組合的一部分composableservice允許成為某個(gè)組合的一部分compositeservice由兩個(gè)或更多個(gè)服務(wù)構(gòu)成entitycentricservice數(shù)據(jù)密集型taskcentricservice業(yè)務(wù)邏輯controllerservice控制和協(xié)調(diào)其他服務(wù)monitorservice監(jiān)視其他服務(wù)分析階段的產(chǎn)物是一個(gè)元類模型，此模型描述候選服務(wù)、候選服務(wù)的角色構(gòu)造型及其操作。設(shè)計(jì)活動(dòng)在此階段，將設(shè)計(jì)在分析階段確定的候選服務(wù)。服務(wù)接口

是對(duì)該服務(wù)提供的操作的描述。它詳細(xì)描述操作、輸入/輸出參數(shù)和消息類型。還可以指定候選服務(wù)所需要的其他服務(wù)。服務(wù)接口設(shè)計(jì)要求同時(shí)指定所提供的和所需要的接口。用于軟件產(chǎn)品線的SOAD需求活動(dòng)：必須用共性和可變性分析對(duì)需求活動(dòng)進(jìn)行擴(kuò)充。需要從業(yè)務(wù)流程模型轉(zhuǎn)變到功能模型。SPL需求共性和可變性分析階段廣泛使用功能模型來(lái)對(duì)SPL成員應(yīng)用程序的所有可能配置建模。相關(guān)功能被分組到各個(gè)功能組中。產(chǎn)品線成員從功能組中選擇它們所需的功能。通過自定義，可以將服務(wù)用在多個(gè)系統(tǒng)中?；镜耐ㄓ梅?wù)可由具有不同功能的多個(gè)系統(tǒng)調(diào)用。要在軟件產(chǎn)品線中使用服務(wù)，需要在考慮可變性的情況下對(duì)服務(wù)進(jìn)行分析。通過在UML活動(dòng)關(guān)系圖中引入可變點(diǎn)，可以對(duì)需求可變性建模。為此，可以使用分支和監(jiān)護(hù)結(jié)構(gòu)，以及指示可變位置（可變點(diǎn)）和要在那些可變點(diǎn)處插入的不同行為的UML構(gòu)造型。圖2顯示了酒店預(yù)訂活動(dòng)關(guān)系圖中的一些可變點(diǎn)?？勺凕c(diǎn)對(duì)約定、居住和會(huì)議預(yù)定進(jìn)行區(qū)分。圖2.酒店預(yù)訂流程的UML活動(dòng)關(guān)系圖中的變化按照?qǐng)D書

DesigningSoftwareProductLineswithUML（請(qǐng)參見參考資料部分）中介紹的分類，需要確定公共、可選和替代功能。公共功能是產(chǎn)品線的所有成員中都存在的需求?？蛇x功能是產(chǎn)品線的部分成員中存在的需求，替代功能是產(chǎn)品線的部分成員從中進(jìn)行選擇的需求?？梢曰跇I(yè)務(wù)流程活動(dòng)關(guān)系圖中的可變點(diǎn)確定功能。每個(gè)可變點(diǎn)可以映射到單個(gè)功能，或者多個(gè)可變點(diǎn)可以映射到一個(gè)功能。此外，整個(gè)業(yè)務(wù)流程可以映射到一個(gè)功能，或者一個(gè)功能可以包含多個(gè)業(yè)務(wù)流程。最后，將為整個(gè)產(chǎn)品線開發(fā)一個(gè)功能模型（以UML元類關(guān)系圖表示），如圖3所示。圖3.酒店預(yù)訂流程的UML元類功能模型分析活動(dòng)首先，你要使用針對(duì)單一系統(tǒng)的分析部分中描述的方法，確定產(chǎn)品線的所有成員共有的候選服務(wù)。然后，通過使用前面討論的針對(duì)單一系統(tǒng)的相同技術(shù)，考慮可選和替代的服務(wù)。下一步，要分析業(yè)務(wù)流程模型中已確定的可變點(diǎn)。必須確定是要作為單個(gè)服務(wù)的一部分還是作為多個(gè)服務(wù)的一部分對(duì)這些可變點(diǎn)建模。如果可變點(diǎn)非常小，可通過對(duì)服務(wù)的操作和參數(shù)應(yīng)用可變點(diǎn)來(lái)對(duì)單個(gè)候選服務(wù)建模。但是，如果可變點(diǎn)在業(yè)務(wù)流程模型中普遍存在，則更加可管理的方法是將相關(guān)功能邏輯地分組到單獨(dú)的服務(wù)中。在一個(gè)服務(wù)中對(duì)所有可變點(diǎn)分組時(shí)，可以考慮某種參數(shù)化的服務(wù)方法。參數(shù)化可應(yīng)用于服務(wù)的操作、參數(shù)和消息。（有關(guān)Web服務(wù)參數(shù)化的示例，請(qǐng)參見參考資料部分）。當(dāng)將相關(guān)功能分組到單獨(dú)的服務(wù)中時(shí)，通過基于服務(wù)所提供的功能來(lái)發(fā)現(xiàn)和綁定到不同的服務(wù)，從而可以實(shí)現(xiàn)可變性。功能建?？梢詾樘峁┸浖a(chǎn)品線成員的服務(wù)組合性質(zhì)的早期指示。服務(wù)需要按特定的順序組合才能交付所需的功能。因此，可變性會(huì)影響各個(gè)參與服務(wù)以及它們?cè)诮M合中的執(zhí)行順序。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫科研論文報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。5.課內(nèi)完成實(shí)驗(yàn)內(nèi)容，課后進(jìn)行分析比較，寫出心得體會(huì)，完成實(shí)驗(yàn)報(bào)告。

實(shí)驗(yàn)7負(fù)載均衡算法一、實(shí)驗(yàn)?zāi)康?．了解什么是負(fù)載均衡算法。2．掌握負(fù)載均衡算法分類。3.實(shí)現(xiàn)一種負(fù)載均衡算法。二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容

實(shí)現(xiàn)以下一種負(fù)載均衡算法。負(fù)載均衡（LoadBalance），顧名思義，是把服務(wù)的并發(fā)請(qǐng)求均衡地負(fù)載到后端多個(gè)具有相同能力的服務(wù)進(jìn)行處理分擔(dān)，以廉價(jià)有效透明的方式擴(kuò)展網(wǎng)絡(luò)設(shè)備或服務(wù)的帶寬，增加吞吐量，增強(qiáng)服務(wù)的整體處理能力，提供服務(wù)的靈活性和可用性。常見的典型的負(fù)載均衡應(yīng)用場(chǎng)景：（1）、web集群：將大量的并發(fā)訪問或數(shù)據(jù)流量分擔(dān)到多臺(tái)節(jié)點(diǎn)設(shè)備上分別處理，減少用戶等待響應(yīng)的時(shí)間。（2）、MapReduce：?jiǎn)蝹€(gè)重負(fù)載的運(yùn)算分擔(dān)到多臺(tái)節(jié)點(diǎn)設(shè)備上做并行處理，每個(gè)節(jié)點(diǎn)設(shè)備處理結(jié)束后，將結(jié)果匯總，返回給?戶，系統(tǒng)處理能?得到大幅度提高。負(fù)載均衡算法

負(fù)載均衡算法是負(fù)載均衡設(shè)備（包括虛擬設(shè)備或相關(guān)軟件）在執(zhí)行負(fù)載均衡調(diào)度，選擇具體處理的后端服務(wù)的時(shí)候使用的調(diào)度和分發(fā)的邏輯。負(fù)載均衡的算法只是規(guī)定了調(diào)度和分發(fā)的邏輯，在不同的負(fù)載均衡方案中都可能使用相同和（或）類似的算法，它只是負(fù)載均衡方案的一部分。常見的主流負(fù)載均衡算法包括：(1)輪詢算法：RoundRobin/WeightRoundRobinScheduling

輪詢算法通過依次輪叫的方式依次將請(qǐng)求調(diào)度不同的后端服務(wù)器(RealServer)。通?？梢苑譃槠胀ㄝ喸兒图訖?quán)輪詢兩種方式。算法的優(yōu)點(diǎn)是簡(jiǎn)潔且無(wú)狀態(tài)。

算法簡(jiǎn)單表示為：i=(i+1)modn(2)Hash算法:隨機(jī)數(shù)Hash，SourcesHashingScheduling

Hash算法，又叫取余算法。一般是對(duì)請(qǐng)求報(bào)文中的某項(xiàng)數(shù)據(jù)(key，一般常用客戶端來(lái)源IP)計(jì)算Hash值，然后按機(jī)器數(shù)量(n)取模。

算法簡(jiǎn)單表示為：idx=Hash(key)%n

Hash算法中，Key的選擇常用實(shí)踐如下：

a、請(qǐng)求時(shí)間或隨機(jī)數(shù)特點(diǎn)是簡(jiǎn)單，具有一定分散性，但不穩(wěn)定，一般用于要求不高的負(fù)載均衡場(chǎng)景。

b、來(lái)源IP

特點(diǎn)是簡(jiǎn)單。如果客戶的分布比較廣，這種方式分散性較好。但如果較多的客戶請(qǐng)求來(lái)源于同一IP（公司網(wǎng)絡(luò)通過路由器上網(wǎng)），分散效果較差。

大多負(fù)載均衡設(shè)備都支持這種算法，著名的nginx和LVS等軟件也支持。(3)一致性Hash算法：ConsistencyHashScheduling

一致性Hash算法最常用于分布式緩存（如memcached、redis等）的定位，但同時(shí)也可以在系統(tǒng)或程序中用于負(fù)載均衡，該算法本來(lái)的意義就在于分散負(fù)載和快速定位。(4)最少連接或請(qǐng)求數(shù):(Weight)LeastConnection/RequestScheduling

最小連接調(diào)度是一種動(dòng)態(tài)調(diào)度算法，它通過服務(wù)器當(dāng)前所活躍的連接數(shù)來(lái)估計(jì)服務(wù)器的負(fù)載情況。

算法主要邏輯是，調(diào)度設(shè)備或服務(wù)記錄后端服務(wù)器接受請(qǐng)求的計(jì)數(shù)，每次請(qǐng)求總是發(fā)給計(jì)數(shù)最小的服務(wù)器處理。(5)最大空閑：MostidleFirst(基于監(jiān)控CPU,內(nèi)存,帶寬等綜合評(píng)估)（6）、平均最快響應(yīng)：平均最快響應(yīng)（7）、最少流量：LeastTrafficScheduling

四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫科研論文報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)8負(fù)載均衡模式一、實(shí)驗(yàn)?zāi)康?．了解什么是負(fù)載模式算法。2．掌握負(fù)載均衡模式分類。二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容

為大型電子商務(wù)網(wǎng)站設(shè)計(jì)負(fù)載均衡方案。撰寫文檔。

負(fù)載均衡模式主要是指在整體方案中選擇從服務(wù)網(wǎng)絡(luò)的哪個(gè)層次或哪個(gè)產(chǎn)品來(lái)實(shí)現(xiàn)負(fù)載均衡方案。1、外部模式（RR-DNS）

RR-DNS，即DNS輪詢模式，它的原理是利用DNS服務(wù)器支持同一域名配置多個(gè)獨(dú)立IP指向，然后輪詢解析指向IP實(shí)現(xiàn)多次訪問的調(diào)度和分發(fā)，實(shí)現(xiàn)負(fù)載均衡。它的主要特點(diǎn)為：a、負(fù)載均衡實(shí)現(xiàn)與后端服務(wù)完全沒有關(guān)系，有DNS在本地解析指向?qū)崿F(xiàn)輪詢調(diào)度。這個(gè)方面來(lái)看性能最佳效率最高。b、DNS服務(wù)無(wú)法檢測(cè)到后端服務(wù)器是否正常，在TTL失效前，會(huì)一直指向失效的服務(wù)器，這就要求在實(shí)踐生成中，必須解決后端服務(wù)器的高可用問題。c、一般的第三方DNS服務(wù)提供商都支持該功能，但如果更新頻率高或附帶更新邏輯，一般會(huì)在系統(tǒng)內(nèi)自鍵DNS服務(wù)，然后在注冊(cè)為公共DNS服務(wù)。2、應(yīng)用層模式

正向代理：用戶通過代理服務(wù)訪問internet,把internet返回的數(shù)據(jù)轉(zhuǎn)發(fā)給用戶。正向代理對(duì)于整個(gè)網(wǎng)絡(luò)請(qǐng)求，它的角色實(shí)際是客戶端，代理客戶對(duì)外的訪問請(qǐng)求。反向代理：接受internet上用戶的請(qǐng)求，轉(zhuǎn)發(fā)給內(nèi)部的多臺(tái)服務(wù)器處理，完成后轉(zhuǎn)發(fā)后端服務(wù)器的返回給對(duì)應(yīng)的用戶。反向代理對(duì)于整個(gè)網(wǎng)絡(luò)請(qǐng)求，它的角色實(shí)際是服務(wù)器，代理接受（accept）所有用戶的請(qǐng)求。

反向代理應(yīng)用模式：常見的反向代理應(yīng)用模式，比如通過Apache,nginx等Web服務(wù)器軟件實(shí)現(xiàn)WEB應(yīng)用的負(fù)載均衡和高可用。利用反向代理軟件實(shí)現(xiàn)負(fù)載均衡是性價(jià)比較高的模式。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫科研論文報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)9無(wú)共享架構(gòu)一、實(shí)驗(yàn)?zāi)康?．了解什么是無(wú)共享架構(gòu)。2．掌握無(wú)共享架構(gòu)特征及設(shè)計(jì)方法。二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容

為大型電子商務(wù)網(wǎng)站例如淘寶網(wǎng)設(shè)計(jì)一種無(wú)共享數(shù)據(jù)架構(gòu)，考慮保證“雙十一”期間其平臺(tái)正常運(yùn)轉(zhuǎn)，并撰寫文檔。

無(wú)共享架構(gòu)（sharednothingarchitecture）是一種分布式計(jì)算架構(gòu)。這種架構(gòu)中的每一個(gè)節(jié)點(diǎn)（node）都是獨(dú)立、自給的，而且整個(gè)系統(tǒng)中沒有單點(diǎn)競(jìng)爭(zhēng)。有些系統(tǒng)需要集中保存大量的狀態(tài)信息——數(shù)據(jù)庫(kù)、應(yīng)用服務(wù)器或是其他類似的單點(diǎn)競(jìng)爭(zhēng)系統(tǒng)。

圖1無(wú)共享架構(gòu)設(shè)計(jì)無(wú)共享架構(gòu)的一個(gè)重要實(shí)踐指導(dǎo)原則就是避免在互聯(lián)系統(tǒng)中使用Session，因?yàn)閷?shí)踐已經(jīng)證明，在一個(gè)集群分布式計(jì)算環(huán)境中，若Session狀態(tài)維護(hù)在各個(gè)節(jié)點(diǎn)服務(wù)器上，為了保證狀態(tài)一致性，節(jié)點(diǎn)間Session數(shù)據(jù)需要互相拷貝同步，嚴(yán)重影響性能，我們需要盡可能的改造現(xiàn)有架構(gòu)不要使用Session。無(wú)共享架構(gòu)在Web應(yīng)用開發(fā)中尤其受到歡迎，究其原因是這種方案提供的scalability。Google在這個(gè)方面做了很好的示范。在一個(gè)純SharedNothing系統(tǒng)中，通過簡(jiǎn)單地增加一些廉價(jià)的計(jì)算機(jī)做為系統(tǒng)的節(jié)點(diǎn)卻可以獲取幾乎無(wú)限的擴(kuò)展。正是由于SharedNothing架構(gòu)中不存在單一瓶頸而降低系統(tǒng)運(yùn)行速度。Google稱之為sharding。Sharednothing系統(tǒng)通常需要將他的數(shù)據(jù)分布在多個(gè)節(jié)點(diǎn)的不同數(shù)據(jù)庫(kù)中（不同的計(jì)算機(jī)處理不同的用戶和查詢）或者要求每個(gè)節(jié)點(diǎn)通過使用某些協(xié)調(diào)協(xié)議來(lái)保留它自己的應(yīng)用程序數(shù)據(jù)備份，這通常被成為數(shù)據(jù)庫(kù)Sharding。

無(wú)共享架構(gòu)是一種分布式計(jì)算架構(gòu)，這種架構(gòu)中不存在集中存儲(chǔ)的狀態(tài)，系統(tǒng)中每個(gè)節(jié)點(diǎn)都是獨(dú)立自治的，整個(gè)系統(tǒng)中沒有資源競(jìng)爭(zhēng)，這種架構(gòu)具有非常強(qiáng)的擴(kuò)張性，目前在web應(yīng)用中被廣泛使用。

2、對(duì)比shared-nothing、shared-memory、shared-disk是并行系統(tǒng)最常使用的模式。

shared-memory：多個(gè)cpu共享同一片內(nèi)存，cpu之間通過內(nèi)部通訊機(jī)制進(jìn)行通訊

shared-disk：每一個(gè)cpu使用自己的私有內(nèi)存區(qū)域，通過內(nèi)部通訊機(jī)制直接訪問所有磁盤系統(tǒng)

和shared-memory、shared-disk相比，shared-nothing優(yōu)勢(shì)明顯，在針對(duì)多用戶并行訪問的時(shí)候，通過橫向擴(kuò)充資源，能夠大大減少響應(yīng)時(shí)間，提升整體吞吐量和效率。3、分片sharednoting需要確立一種分片策略，使得依據(jù)不同的分片策略，減少資源競(jìng)爭(zhēng)。三種基本的分片策略結(jié)構(gòu)：(1)功能分片根據(jù)多個(gè)功能互相不重疊的特點(diǎn)進(jìn)行分片，這種方式已經(jīng)在ebay取得巨大成功。缺點(diǎn)也很明顯，即技術(shù)人員需要深入理解應(yīng)用領(lǐng)域，才能更好地分片;(2)鍵值分片在數(shù)據(jù)中找到一個(gè)可以均勻分布到各個(gè)分片中的鍵值。(3)查表在集群中有一個(gè)節(jié)點(diǎn)充當(dāng)目錄角色，用于查詢哪個(gè)節(jié)點(diǎn)擁有用戶要訪問的數(shù)據(jù)。缺點(diǎn)在于這個(gè)表可能成為整個(gè)系統(tǒng)的瓶頸及單點(diǎn)失效點(diǎn);四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)10分布式計(jì)算架構(gòu)一、實(shí)驗(yàn)?zāi)康?．了解什么是分布式計(jì)算架構(gòu)。2．掌握分布式計(jì)算架構(gòu)特征及設(shè)計(jì)方法。二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容實(shí)驗(yàn)任務(wù)：某公司的計(jì)算機(jī)系統(tǒng)很龐大，自然是一個(gè)整的分布式系統(tǒng)，為了方便組織管理，公司將整個(gè)技術(shù)部按業(yè)務(wù)和平臺(tái)拆分為部門，訂單的，會(huì)員的，商家的等等，每個(gè)部門有自己的web服務(wù)器集群，數(shù)據(jù)庫(kù)服務(wù)器集群，通過同一個(gè)網(wǎng)站訪問的鏈接可能來(lái)自于不同的服務(wù)器和數(shù)據(jù)庫(kù)，對(duì)網(wǎng)站及底層對(duì)數(shù)據(jù)庫(kù)的訪問被分配到了不同的服務(wù)器集群,這個(gè)便是典型的按業(yè)務(wù)做的垂直拆分，每個(gè)部門的服務(wù)器在無(wú)法支撐時(shí)，會(huì)有彈性的擴(kuò)展，這便是水平擴(kuò)展。采用zookeeper為該大型電子商務(wù)公司設(shè)計(jì)一種分布式架構(gòu)，并撰寫文檔。

ZooKeeper是一個(gè)分布式的，開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是Google的Chubby一個(gè)開源的實(shí)現(xiàn)，是Hadoop和Hbase的重要組件。分布式系統(tǒng)的設(shè)計(jì)方式假設(shè)我們有一臺(tái)服務(wù)器，它可以承擔(dān)1百萬(wàn)/秒的請(qǐng)求，這個(gè)請(qǐng)求可以的是通過http訪問網(wǎng)頁(yè)，通過tcp下載文件，jdbc執(zhí)行sql，RPC調(diào)用接口…，現(xiàn)在我們有一條數(shù)據(jù)的請(qǐng)求是2百萬(wàn)/秒，很顯然服務(wù)器hold不住了，會(huì)各種拒絕訪問，甚至崩潰，宕機(jī)，怎么辦呢。一臺(tái)機(jī)器解決不了的問題，那就兩臺(tái)。所以我們加一臺(tái)機(jī)器，每臺(tái)承擔(dān)1百萬(wàn)。如果請(qǐng)求繼續(xù)增加呢，兩臺(tái)解決不了的問題，那就三臺(tái)唄。這種方式我們稱之為水平擴(kuò)展。如何實(shí)現(xiàn)請(qǐng)求的平均分配便是負(fù)載均衡了。另一個(gè)例子，我們現(xiàn)在有兩個(gè)數(shù)據(jù)請(qǐng)求，數(shù)據(jù)190萬(wàn)，數(shù)據(jù)280萬(wàn)，上面那臺(tái)機(jī)器也支撐不住，我們加一臺(tái)機(jī)器來(lái)負(fù)載均衡一下，每臺(tái)機(jī)器處理45萬(wàn)數(shù)據(jù)1和40萬(wàn)數(shù)據(jù)2，但是平分太麻煩，不如一臺(tái)處理數(shù)據(jù)1，一臺(tái)處理數(shù)據(jù)2，同樣能解決問題，這種方式我們稱之為垂直拆分。水平擴(kuò)展和垂直拆分是分布式架構(gòu)的兩種思路，但并不是一個(gè)二選一的問題，更多的是兼并合用。下面介紹一個(gè)實(shí)際的場(chǎng)景。這也是許多互聯(lián)網(wǎng)的公司架構(gòu)思路。在數(shù)據(jù)庫(kù)層，有些表非常大，數(shù)據(jù)量在億級(jí)，如果只是純粹的水平的擴(kuò)展并不一定最好，如果對(duì)表進(jìn)行拆分，比如可以按用戶id進(jìn)行水平拆表，通過對(duì)id取模的方式，將用戶劃分到多張表中，同時(shí)這些表也可以處在不同的服務(wù)器。按業(yè)務(wù)的垂直拆庫(kù)和按用戶水平拆表是分布式數(shù)據(jù)庫(kù)中通用的解決方案。負(fù)載均衡設(shè)計(jì)前面我們談到了分布式來(lái)解決性能問題，但其附帶的問題是怎么分布，即如何負(fù)載均衡。這里要解決的問題是當(dāng)客戶端請(qǐng)求時(shí)，應(yīng)該讓它請(qǐng)求分布式系統(tǒng)中哪一臺(tái)服務(wù)器，通常的做法是通過一臺(tái)中間服務(wù)器來(lái)給客服端分配目標(biāo)服務(wù)器。這里同樣拿兩個(gè)不同的分布式系統(tǒng)做說明，下圖左邊是分布式文件系統(tǒng)FastDFS,右邊是一個(gè)用于分布式的RPC中間件。

FastDFS的一次文件下載請(qǐng)求過程是這樣的

1.client詢問tracker可以下載指定文件的storage；

2.tracker返回一臺(tái)可用的storage；

3.client直接和storage通信完成文件下載。其中tracker便是負(fù)載均衡服務(wù)器，storage是存儲(chǔ)文件和處理上傳下載請(qǐng)求的服務(wù)器。而另一個(gè)RPC中間件Hedwig也是類似的

1.client詢問zookeeper哪臺(tái)server可以執(zhí)行請(qǐng)求；

2.zookeeper返回一臺(tái)可用server；

3.client直接與service完成一次RPC。zookeeper是分布式系統(tǒng)中一個(gè)負(fù)載均衡框架，google的chubby的一個(gè)開源實(shí)現(xiàn)，是是Hadoop和Hbase的重要組件。同樣的在http中，常聽說的nginx也是一個(gè)負(fù)載均衡服務(wù)器，它面向的是分布式web服務(wù)器。至于具體的負(fù)載均衡算法輪詢，hash等這里就不深入了。同步設(shè)計(jì)分布式系統(tǒng)中，解決了負(fù)載均衡的問題后，另外一個(gè)問題就是數(shù)據(jù)的一致性了，這個(gè)就需要通過同步來(lái)保障。根據(jù)不同的場(chǎng)景和需求，同步的方式也是有選擇的。在分布式文件系統(tǒng)中，比如商品頁(yè)面的圖片，如果進(jìn)行了修改，同步要求并不高，就算有數(shù)秒甚至數(shù)分鐘的延遲都是可以接受的，因?yàn)橐话悴粫?huì)產(chǎn)生損失性的影響，因此可以簡(jiǎn)單的通過文件修改的時(shí)間戳，隔一定時(shí)間掃描同步一次，可以犧牲一致性來(lái)提高效率。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)11SOA架構(gòu)設(shè)計(jì)一、實(shí)驗(yàn)?zāi)康?．了解什么是SOA架構(gòu)。2．掌握SOA架構(gòu)架構(gòu)特征及設(shè)計(jì)方法。二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容以大型電子商務(wù)網(wǎng)站為例，基于SOA架構(gòu)設(shè)計(jì)方法為其設(shè)計(jì)架構(gòu)。1.SOA的架構(gòu)層次進(jìn)行SOA類型的架構(gòu)設(shè)計(jì)就需要搞清楚SOA架構(gòu)模型才行。并不能想當(dāng)然的對(duì)系統(tǒng)進(jìn)行簡(jiǎn)單的拆分就行，需要搞清楚SOA的架構(gòu)模型是怎樣的，每一塊是干什么用的，這樣設(shè)計(jì)由分析階段輸出的需求時(shí)才能正確的劃分職責(zé)。如果把SOA的架構(gòu)簡(jiǎn)單的理解為是多個(gè)子系統(tǒng)之間的整合其實(shí)有點(diǎn)太過于簡(jiǎn)單，也沒有真正搞清楚SOA的架構(gòu)模型。按照SOA的正確方法論及目標(biāo)模型，其實(shí)SOA在實(shí)現(xiàn)架構(gòu)落地上，需要考慮到對(duì)服務(wù)的組合，不斷的重用現(xiàn)有的服務(wù)，讓企業(yè)應(yīng)用可以逐步集成，快速實(shí)現(xiàn)業(yè)務(wù)的迭代。其實(shí)這就是本節(jié)要講的服務(wù)的分層，通過分層將服務(wù)按照使用類型進(jìn)行分配，上層服務(wù)對(duì)下層服務(wù)的包裝，下層服務(wù)負(fù)責(zé)原子性的操作，上層服務(wù)對(duì)下層服務(wù)進(jìn)行業(yè)務(wù)性的組合。我們來(lái)看具體的每一層的作用及主要職責(zé)。2..應(yīng)用服務(wù)（原子服務(wù)）圖1：原子服務(wù)劃分應(yīng)用服務(wù)就是諸如：訂單服務(wù)、倉(cāng)庫(kù)服務(wù)、銷售服務(wù)、客戶管理服務(wù)，這些服務(wù)直接對(duì)應(yīng)不同的應(yīng)用系統(tǒng)，直接服務(wù)這些應(yīng)用系統(tǒng)的原子操作。訂單服務(wù)直接原子性的插入訂單，沒有任何跨其他服務(wù)的分支邏輯。倉(cāng)庫(kù)服務(wù)只管自己的倉(cāng)庫(kù)邏輯。同樣其他的應(yīng)用服務(wù)只管好自己的職責(zé)，杜絕對(duì)其他服務(wù)的調(diào)用。應(yīng)用服務(wù)位于UI與后臺(tái)之間，后臺(tái)我們可以認(rèn)為它是一異構(gòu)的系統(tǒng)或者是數(shù)據(jù)庫(kù)之類的。應(yīng)用服務(wù)的位置位于前端與后端之間，起到類似一個(gè)服務(wù)API的作用，但是SOA中的服務(wù)還遠(yuǎn)遠(yuǎn)不止這一個(gè)應(yīng)用服務(wù)，如果我們的SOA架構(gòu)中只有一種類型的服務(wù)，那么這會(huì)增加我們系統(tǒng)的耦合程度，因?yàn)槟銢]有對(duì)系統(tǒng)的服務(wù)進(jìn)行層次的劃分，你的業(yè)務(wù)功能會(huì)直接的落到某一個(gè)應(yīng)用線上的服務(wù)，繼續(xù)往下看。3.組合服務(wù)組合服務(wù)是對(duì)應(yīng)用服務(wù)的一個(gè)組合,根據(jù)實(shí)際項(xiàng)目的規(guī)模大小,不一定非要進(jìn)行物理的隔離,在代碼層面的服務(wù)化也是可以的,在將來(lái)的某一天有必要的情況下再進(jìn)行物理的拆分,畢竟物理的拆分有著嚴(yán)重的成本和代價(jià)，對(duì)系統(tǒng)的穩(wěn)定性帶來(lái)很多挑戰(zhàn)。所以經(jīng)驗(yàn)告訴我們必要的時(shí)候在進(jìn)行拆分?！眻D2組合服務(wù)設(shè)計(jì)組合服務(wù)對(duì)下層的應(yīng)用服務(wù)進(jìn)行了組合，完成了一個(gè)基本的業(yè)務(wù)動(dòng)作，應(yīng)用服務(wù)中是最基本的基礎(chǔ)性的原子性的操作。但是在復(fù)雜的業(yè)務(wù)需求下大部分業(yè)務(wù)功能都需要跨越多個(gè)應(yīng)用線來(lái)完成一個(gè)最外層的企業(yè)動(dòng)作。提交訂單可能需要穿過很多應(yīng)用線，訂單管理、倉(cāng)庫(kù)、財(cái)務(wù)等等環(huán)節(jié)。所以這里我們還需要一個(gè)能在最外層對(duì)組合服務(wù)進(jìn)行編排的業(yè)務(wù)服務(wù)。這個(gè)編排服務(wù)可以完全是自動(dòng)化的，通過工作流引擎進(jìn)行組合自動(dòng)化來(lái)完成，這對(duì)企業(yè)應(yīng)用的自動(dòng)化流程很有意義。4.業(yè)務(wù)服務(wù)（編排服務(wù)）業(yè)務(wù)服務(wù)是最外層的服務(wù)，向下編排了組合服務(wù)。業(yè)務(wù)服務(wù)位于最上層，當(dāng)需要有跨越多個(gè)應(yīng)用線來(lái)完成的業(yè)務(wù)，這個(gè)業(yè)務(wù)就放入業(yè)務(wù)服務(wù)中。比如提交訂單，先檢查庫(kù)存、扣減庫(kù)存（凍結(jié)庫(kù)存），然后下單，再往后通知財(cái)務(wù)，再往后通知物流等等都是一個(gè)復(fù)雜的企業(yè)服務(wù)線。這種最外層的業(yè)務(wù)邏輯如果你不進(jìn)行SOA分層然后將其放入最外層的業(yè)務(wù)服務(wù)中，你把它放入任何一個(gè)應(yīng)用線都會(huì)使系統(tǒng)調(diào)用混亂不堪。所以問題就是需要進(jìn)行縱向的劃分層次。如果進(jìn)行了SOA的層次劃分后就不會(huì)出現(xiàn)互相亂用的情況。其實(shí)這里可以參考阿里的服務(wù)設(shè)計(jì)方法。圖3業(yè)務(wù)服務(wù)設(shè)計(jì)當(dāng)在業(yè)務(wù)服務(wù)中執(zhí)行的業(yè)務(wù)邏輯時(shí)，需要跨越多個(gè)應(yīng)用線來(lái)完成。這部分的邏輯也說是職責(zé)，如果不放入這個(gè)位置，放在哪個(gè)應(yīng)用線都不合適，放入哪個(gè)應(yīng)用線都會(huì)使系統(tǒng)調(diào)用出現(xiàn)混亂。其實(shí)這里的問題就是我們不能用一個(gè)維度來(lái)進(jìn)行SOA系統(tǒng)的設(shè)計(jì)，本來(lái)服務(wù)就具有組合特性，所以適當(dāng)?shù)奶嵘?wù)的層次是有好處的，但是應(yīng)用服務(wù)和組合服務(wù)可以在代碼層面上進(jìn)行構(gòu)建，而業(yè)務(wù)服務(wù)也叫編排服務(wù)是需要進(jìn)行物理隔離的，畢竟考慮到系統(tǒng)復(fù)雜度和穩(wěn)定性問題這是值得的。在排查問題，系統(tǒng)性能、穩(wěn)定性等等方面，物理的隔離有一定的作用，畢竟業(yè)務(wù)服務(wù)本來(lái)就是來(lái)組合多個(gè)應(yīng)用線的，這樣做會(huì)使整個(gè)系統(tǒng)架構(gòu)很清晰。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)12ED-SOA架構(gòu)一、實(shí)驗(yàn)?zāi)康?．了解什么是ED-SOA架構(gòu)。2．掌握ED-SOA架構(gòu)特征及設(shè)計(jì)方法。二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容以股票交易系統(tǒng)為例，基于ED-SOA架構(gòu)設(shè)計(jì)方法為其設(shè)計(jì)架構(gòu)。1.Event-DrivenSOA一般將SOA和EDA的集成體稱之為事件驅(qū)動(dòng)的面向服務(wù)架構(gòu)(Event-DrivenSOA)，可以將其理解為SOA的一種衍生。SOA和EDA的交互主要體現(xiàn)在以下幾個(gè)方面：（1）將事件處理的能力引入到SOA一個(gè)事件的產(chǎn)生可以觸發(fā)一個(gè)或多個(gè)服務(wù)被調(diào)用，這樣就把這些靜態(tài)的功能動(dòng)態(tài)地串聯(lián)起來(lái)。（2）服務(wù)本身也可以產(chǎn)生事件服務(wù)除了完成特定的功能外，也可以根據(jù)自身需要產(chǎn)生某個(gè)事件。回頁(yè)首2.Event-DrivenSOA架構(gòu)的特點(diǎn)任何一種架構(gòu)模式都有其適用的場(chǎng)景，Event-DrivenSOA自然也不例外。首先，它適用于異步的環(huán)境。如果你的系統(tǒng)對(duì)實(shí)時(shí)性要求比較高，請(qǐng)不要使用該架構(gòu)。第二，如果你的系統(tǒng)需要面對(duì)復(fù)雜的異構(gòu)環(huán)境——跨平臺(tái)/跨語(yǔ)言，那么面向服務(wù)的架構(gòu)能夠很好地應(yīng)對(duì)。第三，將系統(tǒng)功能分解為適當(dāng)粒度并且重用性高的一個(gè)個(gè)服務(wù)，可以顯著地提高IT系統(tǒng)的適應(yīng)性和效率，進(jìn)而提高投資回報(bào)率(ROI)。第四，引入事件處理的能力以后，每個(gè)服務(wù)都是由不同的事件驅(qū)動(dòng)，這樣當(dāng)某個(gè)事件發(fā)生后，系統(tǒng)的不同服務(wù)就能夠自動(dòng)地進(jìn)行觸發(fā)。這對(duì)那些有更高自動(dòng)化要求的系統(tǒng)來(lái)說非常適合。第五，與面向過程的系統(tǒng)中客戶端必須輪詢更改請(qǐng)求(通過API調(diào)用)不同，事件驅(qū)動(dòng)架構(gòu)允許系統(tǒng)和組件在事件發(fā)生時(shí)實(shí)時(shí)動(dòng)態(tài)地做出響應(yīng)。事件驅(qū)動(dòng)架構(gòu)通過引入長(zhǎng)時(shí)間運(yùn)行的處理功能來(lái)彌補(bǔ)SOA的不足。這一點(diǎn)對(duì)于金融系統(tǒng)來(lái)說尤其重要，比如說一次股票買賣從客戶下單到最終交割會(huì)經(jīng)歷幾天的生命周期。最后，Event-DrivenSOA使得增加事件的consumer和producer非常容易，這樣就使得增加系統(tǒng)吞吐量也變得很簡(jiǎn)單，系統(tǒng)的彈性非常好，非常適合那些業(yè)務(wù)量持續(xù)增加的系統(tǒng)。在這方面，有一個(gè)EDA的變體SEDA（StagedEvent-DrivenArchitecture）將這方面的設(shè)計(jì)發(fā)揮到了極致，詳細(xì)的介紹請(qǐng)參考正文后的參考資料?；仨?yè)首3.Event-DrivenSOA在金融系統(tǒng)的應(yīng)用在當(dāng)今社會(huì)，市場(chǎng)變化莫測(cè)，商機(jī)稍縱即逝，企業(yè)需要有極強(qiáng)的靈活性和應(yīng)變能力，金融行業(yè)尤其如此，特別是在中國(guó)這樣一個(gè)金融行業(yè)處于快速發(fā)展的市場(chǎng)里。企業(yè)要求IT系統(tǒng)能夠快速地對(duì)業(yè)務(wù)需求做出應(yīng)對(duì)，否則就會(huì)喪失先發(fā)優(yōu)勢(shì)。這有點(diǎn)類似于現(xiàn)代戰(zhàn)爭(zhēng)條件下，各國(guó)都要求部隊(duì)具備快速反應(yīng)能力，這種能力主要體現(xiàn)在IT部門能夠通過快速開發(fā)或者重用/整合現(xiàn)有資源來(lái)達(dá)到快速響應(yīng)業(yè)務(wù)需求。還有，金融行業(yè)業(yè)務(wù)越來(lái)越龐大復(fù)雜，所涉及的第三方系統(tǒng)或者遺留系統(tǒng)非常多，這就要求IT系統(tǒng)有很強(qiáng)的整合能力及對(duì)異構(gòu)環(huán)境的適應(yīng)能力。最后，由于金融行業(yè)的發(fā)展日新月異，特定金融業(yè)務(wù)都會(huì)在其初期發(fā)展后迎來(lái)一個(gè)快速膨脹期，業(yè)務(wù)量和業(yè)務(wù)類型會(huì)急劇增加，這也要求IT系統(tǒng)有很好的可擴(kuò)展性。對(duì)照前面提到的Event-DrivenSOA的特點(diǎn)，我們可以很直觀地發(fā)現(xiàn)該架構(gòu)可以很好地滿足金融系統(tǒng)的實(shí)際需求。當(dāng)然，金融系統(tǒng)也是包羅萬(wàn)象，特點(diǎn)各不一樣，這里可能更偏重于金融行業(yè)的交易系統(tǒng)。我們還可以深入到具體系統(tǒng)的內(nèi)部，從一些微觀層面來(lái)考慮Event-DrivenSOA是否仍然能夠符合我們的要求。下圖是一個(gè)證券公司股票交易系統(tǒng)的簡(jiǎn)圖：

圖1.證券公司股票交易系統(tǒng)概略圖

從上圖我們可以看出，整個(gè)應(yīng)用被分為很多子系統(tǒng)，各個(gè)子系統(tǒng)之間存在著大量的信息交互。而且大部分應(yīng)用輸入都需要經(jīng)歷一個(gè)比較長(zhǎng)的生命周期，比如說一個(gè)客戶訂單輸入到系統(tǒng)后，會(huì)先后經(jīng)歷前臺(tái)系統(tǒng)(FrontOffice)，中臺(tái)系統(tǒng)(MiddleOffice)以及后臺(tái)系統(tǒng)(BackOffice)，而且每個(gè)系統(tǒng)內(nèi)部又包括很多服務(wù)組件。除了系統(tǒng)層面的跨度外，這個(gè)生命周期也體現(xiàn)在時(shí)間長(zhǎng)度上。而且，如今所有的金融系統(tǒng)都追求STP(StraightThroughProcessing)的能力，主張盡可能少的人工干預(yù)，這樣所有的服務(wù)組件都需要具備自觸發(fā)的能力?；仨?yè)首4.Event-DrivenSOA架構(gòu)設(shè)計(jì)架構(gòu)師在著手每次的架構(gòu)設(shè)計(jì)時(shí)，其實(shí)都是在提出并回答一系列的問題，把這些問題都回答了，架構(gòu)設(shè)計(jì)也就出來(lái)了。比如我們每次肯定都會(huì)問：系統(tǒng)的最終用戶是誰(shuí)，他們會(huì)如何來(lái)使用該系統(tǒng)，他們的核心訴求是什么。當(dāng)然，不是所有的問題都能有一個(gè)圓滿的答案，更多的時(shí)候其實(shí)是一個(gè)取舍的過程。比如說系統(tǒng)的關(guān)鍵指標(biāo)我們很難一下子全部滿足，就需要結(jié)合具體的業(yè)務(wù)需求和人力物力以及時(shí)間的具體情況來(lái)做取舍。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)13高并發(fā)系統(tǒng)架構(gòu)一、實(shí)驗(yàn)?zāi)康?．了解什么是高并發(fā)系統(tǒng)架構(gòu)。2．掌握高并發(fā)系統(tǒng)架構(gòu)設(shè)計(jì)方法。二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容以電子商務(wù)搜索系統(tǒng)為例，為其設(shè)計(jì)并行與高性能計(jì)算系統(tǒng)架構(gòu)。1.空間換時(shí)間1)多級(jí)緩存，靜態(tài)化客戶端頁(yè)面緩存（httpheader中包含Expires/CacheofControl，lastmodified(304，server不返回body，客戶端可以繼續(xù)用cache，減少流量)，ETag）反向代理緩存應(yīng)用端的緩存(memcache)內(nèi)存數(shù)據(jù)庫(kù)Buffer、cache機(jī)制（數(shù)據(jù)庫(kù)，中間件等）2)索引哈希、B樹、倒排、bitmap哈希索引適合綜合數(shù)組的尋址和鏈表的插入特性，可以實(shí)現(xiàn)數(shù)據(jù)的快速存取。B樹索引適合于查詢?yōu)橹鲗?dǎo)的場(chǎng)景，避免多次的IO，提高查詢的效率。倒排索引實(shí)現(xiàn)單詞到文檔映射關(guān)系的最佳實(shí)現(xiàn)方式和最有效的索引結(jié)構(gòu)，廣泛用在搜索領(lǐng)域。Bitmap是一種非常簡(jiǎn)潔快速的數(shù)據(jù)結(jié)構(gòu)，他能同時(shí)使存儲(chǔ)空間和速度最優(yōu)化（而不必空間換時(shí)間），適合于海量數(shù)據(jù)的的計(jì)算場(chǎng)景。2.并行與分布式計(jì)算1)任務(wù)切分、分而治之(MR)在大規(guī)模的數(shù)據(jù)中，數(shù)據(jù)存在一定的局部性的特征，利用局部性的原理將海量數(shù)據(jù)計(jì)算的問題分而治之。MR模型是無(wú)共享的架構(gòu)，數(shù)據(jù)集分布至各個(gè)節(jié)點(diǎn)。處理時(shí)，每個(gè)節(jié)點(diǎn)就近讀取本地存儲(chǔ)的數(shù)據(jù)處理(map)，將處理后的數(shù)據(jù)進(jìn)行合并(combine)、排序(shuffleandsort)后再分發(fā)(至reduce節(jié)點(diǎn))，避免了大量數(shù)據(jù)的傳輸，提高了處理效率。2)多進(jìn)程、多線程并行執(zhí)行(MPP)并行計(jì)算（ParallelComputing）是指同時(shí)使用多種計(jì)算資源解決計(jì)算問題的過程，是提高計(jì)算機(jī)系統(tǒng)計(jì)算速度和處理能力的一種有效手段。它的基本思想是用多個(gè)處理器/進(jìn)程/線程來(lái)協(xié)同求解同一問題，即將被求解的問題分解成若干個(gè)部分，各部分均由一個(gè)獨(dú)立的處理機(jī)來(lái)并行計(jì)算。和MR的區(qū)別在于，它是基于問題分解的，而不是基于數(shù)據(jù)分解。3電子商務(wù)搜索系統(tǒng)高并發(fā)架構(gòu)設(shè)計(jì)在電子商務(wù)平臺(tái)中搜索是一個(gè)非常的重要功能，主要有搜索詞類目導(dǎo)航、自動(dòng)提示和搜索排序功能。開源的企業(yè)級(jí)\o"搜索引擎知識(shí)庫(kù)"搜索引擎主要有l(wèi)ucene,

sphinx，這里不去論述哪種搜索引擎更好一些，不過選擇搜索引擎除了基本的功能需要支持外，非功能方面需要考慮以下兩點(diǎn)：a、

搜索引擎是否支持分布式的索引和搜索，來(lái)應(yīng)對(duì)海量的數(shù)據(jù)，支持讀寫分離，提高可用性b、

索引的實(shí)時(shí)性c、

性能Solr是基于lucene的高性能的全文搜索服務(wù)器，提供了比lucene更為豐富的查詢語(yǔ)言，可配置可擴(kuò)展，對(duì)外提供基于http協(xié)議的XML/JSON格式的接口。從Solr4版本開始提供了SolrCloud方式來(lái)支持分布式的索引，自動(dòng)進(jìn)行sharding數(shù)據(jù)切分；通過每個(gè)sharding的master-slave(leader、replica)模式提高搜索的性能；利用zookeeper對(duì)集群進(jìn)行管理，包括leader選舉等等，保障集群的可用性。Lucene索引的Reader是基于索引的snapshot的，所以必須在索引commit的后，重新打開一個(gè)新的snapshot，才能搜索到新添加的內(nèi)容；而索引的commit是非常耗性能的，這樣達(dá)到實(shí)時(shí)索引搜索效率就比較低下。對(duì)于索引搜索實(shí)時(shí)性，Solr4的之前解決方案是結(jié)合文件全量索引和內(nèi)存增量索引合并的方式，參見下圖。圖1-3搜索解決方案Solr4提供了NRT

softcommit的解決方案，softcommit無(wú)需進(jìn)行提交索引操作，就可以搜素到最新對(duì)索引的變更，不過對(duì)索引的變更并沒有sync

commit到硬盤存儲(chǔ)上，若發(fā)生意外導(dǎo)致程序非正常結(jié)束，未commit的數(shù)據(jù)會(huì)丟失，因此需要定時(shí)的進(jìn)行commit操作。平臺(tái)中對(duì)數(shù)據(jù)的索引和存儲(chǔ)操作是異步的，可以大大提高可用性和吞吐量；只對(duì)某些屬性字段做索引操作，存儲(chǔ)數(shù)據(jù)的標(biāo)識(shí)key，減少索引的大小；數(shù)據(jù)是存儲(chǔ)在分布式存儲(chǔ)\o"Hbase知識(shí)庫(kù)"Hbase

中的，HBase對(duì)二級(jí)索引搜索支持的不好，然而可以結(jié)合Solr搜索功能進(jìn)行多維度的檢索統(tǒng)計(jì)。索引數(shù)據(jù)和HBase數(shù)據(jù)存儲(chǔ)的一致性，也就是如何保障HBase存儲(chǔ)的數(shù)據(jù)都被索引過，可以采用confirm確認(rèn)機(jī)制，通過在索引前建立待索引數(shù)據(jù)隊(duì)列，在數(shù)據(jù)存儲(chǔ)并索引完成后，從待索引數(shù)據(jù)隊(duì)列中刪除數(shù)據(jù)。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)14高可用系統(tǒng)架構(gòu)一、實(shí)驗(yàn)?zāi)康?．了解什么是高可用系統(tǒng)架構(gòu)。2．掌握高可用系統(tǒng)架構(gòu)設(shè)計(jì)方法。二、實(shí)驗(yàn)學(xué)時(shí) 4學(xué)時(shí)三、實(shí)驗(yàn)內(nèi)容以電子商務(wù)系統(tǒng)為例，為其設(shè)計(jì)高可用數(shù)據(jù)存儲(chǔ)架構(gòu)。1)

內(nèi)存型數(shù)據(jù)庫(kù)內(nèi)存型的數(shù)據(jù)庫(kù)，以高并發(fā)高性能為目標(biāo)，在事務(wù)性方面沒那么嚴(yán)格，以開源nosql數(shù)據(jù)庫(kù)mongodb、redis為例通信方式多線程方式，主線程監(jiān)聽新的連接，連接后，啟動(dòng)新的線程做數(shù)據(jù)的操作（IO切換）。數(shù)據(jù)結(jié)構(gòu)圖1MongoDB在數(shù)據(jù)結(jié)構(gòu)MongoDB在數(shù)據(jù)存儲(chǔ)上按命名空間來(lái)劃分，一個(gè)collection是一個(gè)命名空間，一個(gè)索引也是一個(gè)命名空間。同一個(gè)命名空間的數(shù)據(jù)被分成很多個(gè)Extent，Extent之間使用雙向鏈表連接。在每一個(gè)Extent中，保存了具體每一行的數(shù)據(jù)，這些數(shù)據(jù)也是通過雙向鏈接連接的。每一行數(shù)據(jù)存儲(chǔ)空間不僅包括數(shù)據(jù)占用空間，還可能包含一部分附加空間，這使得在數(shù)據(jù)update變大后可以不移動(dòng)位置。索引以BTree結(jié)構(gòu)實(shí)現(xiàn)。如果你開啟了jorunaling日志，那么還會(huì)有一些文件存儲(chǔ)著你所有的操作記錄。持久化存儲(chǔ)MMap方式把文件地址映射到內(nèi)存的地址空間，直接操作內(nèi)存地址空間就可以操作文件不用再調(diào)用write,read操作，性能比較高。mongodb調(diào)用mmap把磁盤中的數(shù)據(jù)映射到內(nèi)存中的，所以必須有一個(gè)機(jī)制時(shí)刻的刷數(shù)據(jù)到硬盤才能保證可靠性，多久刷一次是syncdelay參數(shù)相關(guān)的。

journal（進(jìn)行恢復(fù)用）是Mongodb中的redo

log，而Oplog則是負(fù)責(zé)復(fù)制的binlog。如果打開journal，那么即使斷電也只會(huì)丟失100ms的數(shù)據(jù)，這對(duì)大多數(shù)應(yīng)用來(lái)說都可以容忍了。從1.9.2+，mongodb都會(huì)默認(rèn)打開journal功能，以確保數(shù)據(jù)安全。而且journal的刷新時(shí)間是可以改變的，2-300ms的范圍,使用

--journalCommitInterval

命令。Oplog和數(shù)據(jù)刷新到磁盤的時(shí)間是60s，對(duì)于復(fù)制來(lái)說，不用等到oplog刷新磁盤，在內(nèi)存中就可以直接復(fù)制到Sencondary節(jié)點(diǎn)。

事務(wù)支持Mongodb只支持對(duì)單行記錄的原子操作

HA集群用的比較多的是Replica

Sets，采用選舉算法，自動(dòng)進(jìn)行l(wèi)eader選舉，在保證可用性的同時(shí)，可以做到強(qiáng)一致性要求。通信方式因都在內(nèi)存操作，所以邏輯的操作非?？欤瑴p少了CPU的切換開銷，所以為單線程的模式（邏輯處理線程和主線程是一個(gè)）。

reactor模式，實(shí)現(xiàn)自己的多路復(fù)用NIO機(jī)制（epoll，select，kqueue等）

單線程處理多任務(wù)數(shù)據(jù)結(jié)構(gòu)

hash+bucket結(jié)構(gòu)，當(dāng)鏈表的長(zhǎng)度過長(zhǎng)時(shí)，會(huì)采取遷移的措施（擴(kuò)展原來(lái)兩倍的hash表，把數(shù)據(jù)遷移過去，expand+rehash）

持久化存儲(chǔ)a、全量持久化RDB（遍歷redisDB,讀取bucket中的key,value），save命令阻塞主線程，bgsave開啟子進(jìn)程進(jìn)行snapshot持久化操作，生成rdb文件。

在shutdown時(shí)，會(huì)調(diào)用save操作

數(shù)據(jù)發(fā)生變化，在多少秒內(nèi)觸發(fā)一次bgsavesync，master接受slave發(fā)出來(lái)的命令b、增量持久化（aof類似redolog），先寫到日志buffer,再flush到日志文件中（flush的策略可以配置的，而已單條，也可以批量），只有flush到文件上的，才真正返回客戶端。要定時(shí)對(duì)aof文件和rdb文件做合并操作（在快照過程中，變化的數(shù)據(jù)先寫到aof

buf中等子進(jìn)程完成快照<內(nèi)存snapshot>后，再進(jìn)行合并aofbuf變化的部分以及全鏡像數(shù)據(jù)）。在高并發(fā)訪問模式下，RDB模式使服務(wù)的性能指標(biāo)出現(xiàn)明顯的抖動(dòng)，aof在性能開銷上比RDB好，但是恢復(fù)時(shí)重新加載到內(nèi)存的時(shí)間和數(shù)據(jù)量成正比。

集群HA通用的解決方案是主從備份切換，采用HA軟件，使得失效的主redis可以快速的切換到從redis上。主從數(shù)據(jù)的同步采用復(fù)制機(jī)制，該場(chǎng)景可以做讀寫分離。目前在復(fù)制方面，存在的一個(gè)問題是在遇到網(wǎng)絡(luò)不穩(wěn)定的情況下，Slave和Master斷開（包括閃斷）會(huì)導(dǎo)致Master需要將內(nèi)存中的數(shù)據(jù)全部重新生成rdb文件（快照文件），然后傳輸給Slave。Slave接收完Master傳遞過來(lái)的rdb文件以后會(huì)將自身的內(nèi)存清空，把rdb文件重新加載到內(nèi)存中。這種方式效率比較低下，在后面的未來(lái)版本Redis2.8作者已經(jīng)實(shí)現(xiàn)了部分復(fù)制的功能。2）分布式數(shù)據(jù)庫(kù)對(duì)于數(shù)據(jù)的高并發(fā)的訪問，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)提供讀寫分離的方案，但是帶來(lái)的確實(shí)數(shù)據(jù)的一致性問題提供的數(shù)據(jù)切分的方案；對(duì)于越來(lái)越多的海量數(shù)據(jù)，傳統(tǒng)的數(shù)據(jù)庫(kù)采用的是分庫(kù)分表，實(shí)現(xiàn)起來(lái)比較復(fù)雜，后期要不斷的進(jìn)行遷移維護(hù)；對(duì)于高可用和伸縮方面，傳統(tǒng)數(shù)據(jù)采用的是主備、主從、多主的方案，但是本身擴(kuò)展性比較差，增加節(jié)點(diǎn)和宕機(jī)需要進(jìn)行數(shù)據(jù)的遷移。對(duì)于以上提出的這些問題，分布式數(shù)據(jù)庫(kù)HBase有一套完善的解決方案，適用于高并發(fā)海量數(shù)據(jù)存取的要求。高可靠HBase的數(shù)據(jù)存儲(chǔ)基于HDFS，提供了冗余機(jī)制。Region節(jié)點(diǎn)的宕機(jī)，對(duì)于內(nèi)存中的數(shù)據(jù)還未flush到文件中，提供了可靠的恢復(fù)機(jī)制。可用性存在單點(diǎn)故障，Region

Server宕機(jī)后，短時(shí)間內(nèi)該server維護(hù)的region無(wú)法訪問，等待failover生效。通過Master維護(hù)各Region

Server健康狀況和Region分布。多個(gè)Master，Master宕機(jī)有zookeeper的paxos投票機(jī)制選取下一任Master。Master就算全宕機(jī)，也不影響Region讀寫。Master僅充當(dāng)一個(gè)自動(dòng)運(yùn)維角色。HDFS為分布式存儲(chǔ)引擎，一備三，高可靠，0數(shù)據(jù)丟失。HDFS的namenode是一個(gè)SPOF。為避免單個(gè)region訪問過于頻繁，單機(jī)壓力過大，提供了split機(jī)制。HBase的寫入是LSM-TREE的架構(gòu)方式，隨著數(shù)據(jù)的append，HFile越來(lái)越多，HBase提供了HFile文件進(jìn)行compact，對(duì)過期數(shù)據(jù)進(jìn)行清除，提高查詢的性能。Schema

freeHBase沒有像關(guān)系型數(shù)據(jù)庫(kù)那樣的嚴(yán)格的schema，可以自由的增加和刪除schema中的字段。HBase分布式數(shù)據(jù)庫(kù)，對(duì)于二級(jí)索引支持的不太好，目前只支持在rowkey上的索引，所以rowkey的設(shè)計(jì)對(duì)于查詢的性能來(lái)講非常關(guān)鍵。四、實(shí)驗(yàn)要求1.學(xué)生每三人分為一組，通過搜索閱讀分析等方法，查閱本實(shí)驗(yàn)相關(guān)的文獻(xiàn)資料；2.針對(duì)本實(shí)驗(yàn)內(nèi)容，分析已有前沿文獻(xiàn)的觀點(diǎn)，討論提出小組的觀點(diǎn)。3.基于小組觀點(diǎn)，撰寫報(bào)告。4.基于小組觀點(diǎn)制作演講ppt。

實(shí)驗(yàn)15五視圖法架構(gòu)設(shè)計(jì)-用例分析一、實(shí)驗(yàn)?zāi)康?、了解五視圖設(shè)計(jì)方法的基本內(nèi)容；2、掌握用例分析的基本方法；3、掌握相關(guān)UML圖形的繪制方法；二、實(shí)驗(yàn)環(huán)境Windows7+Visio2010+Word2010三、實(shí)驗(yàn)內(nèi)容1、架構(gòu)設(shè)計(jì)五視圖法五視圖法可以幫助軟件架構(gòu)師以不同的視角對(duì)軟件的各個(gè)方面的屬性：功能需求，約束，運(yùn)行期質(zhì)量屬性，開發(fā)期質(zhì)量屬性。1）物理架構(gòu)物理架構(gòu)的目的是確定物理節(jié)點(diǎn)和物理節(jié)點(diǎn)的拓?fù)浣Y(jié)構(gòu)；其中物理節(jié)點(diǎn)包括服務(wù)器、PC機(jī)、專用機(jī)、軟件安裝部署以及系統(tǒng)軟件的選型；拓?fù)浣Y(jié)構(gòu)明確物理節(jié)點(diǎn)的關(guān)系。2）運(yùn)行架構(gòu)運(yùn)行架構(gòu)的目的是確定控制流和控制流的組織；其中控制流包括進(jìn)程、線程、服務(wù)程序；控制流組織包括系統(tǒng)的啟動(dòng)與停機(jī)、控制流通訊、同步與加鎖。3）開發(fā)架構(gòu)開發(fā)架構(gòu)的目的是確定程序單元以及程序單元的組織結(jié)構(gòu)；其中程序單元包括源文件、配置文件、程序庫(kù)、框架、目標(biāo)單元；程序單元組織包括project劃分、project目錄結(jié)構(gòu)、編譯依賴關(guān)系。4）邏輯架構(gòu)邏輯架構(gòu)的目的是職責(zé)的劃分，并明確其與協(xié)作關(guān)系；其中職責(zé)的劃分注意邏輯的分層、子系統(tǒng)以及關(guān)鍵類的定義；協(xié)作的定義關(guān)注接口的定義與協(xié)作關(guān)系的明確。5）數(shù)據(jù)模型數(shù)據(jù)架構(gòu)的目的是確定要存儲(chǔ)的數(shù)據(jù)以及存儲(chǔ)格式；其中存儲(chǔ)的數(shù)據(jù)可以是文件、關(guān)系數(shù)據(jù)庫(kù)、實(shí)時(shí)數(shù)據(jù)庫(kù)；存儲(chǔ)格式包括文件格式、數(shù)據(jù)庫(kù)圖表。2、用例分析用例分析是五視圖法的基礎(chǔ)。系統(tǒng)的用戶視圖由用例圖組成，用例圖包含執(zhí)行者、用例、及它們的關(guān)系，用例圖表示了系統(tǒng)對(duì)外部實(shí)體提供的功能，用例圖由執(zhí)行者和用例組成（執(zhí)行者對(duì)系統(tǒng)做什么的）執(zhí)行者主要可分為四類：主要執(zhí)行者–直接與系統(tǒng)交互的人，次要執(zhí)行者–涉及到系統(tǒng)維護(hù)的人，外部硬件–運(yùn)行應(yīng)用的非計(jì)算機(jī)的系統(tǒng)部分，其他系統(tǒng)–為其工作需要與你系統(tǒng)交互的外部系統(tǒng)。3、案例分析 設(shè)計(jì)一個(gè)面向全國(guó)的績(jī)效考核系統(tǒng)。如何進(jìn)行用例分析？如何進(jìn)行流程分析？如何進(jìn)行領(lǐng)域分析？ 原始需求：系統(tǒng)根據(jù)操作規(guī)范制定考核指標(biāo)，通過分析業(yè)務(wù)系統(tǒng)的數(shù)據(jù)產(chǎn)生考核結(jié)果；過錯(cuò)責(zé)任人可以對(duì)自己的過錯(cuò)提出申辯，通過申辯受理、調(diào)查確認(rèn)、領(lǐng)導(dǎo)審批后，對(duì)過錯(cuò)進(jìn)行調(diào)整；對(duì)最終考核結(jié)果的過錯(cuò)責(zé)任人進(jìn)行過錯(cuò)追究，根據(jù)過錯(cuò)程度進(jìn)行罰款與行政追究；各級(jí)機(jī)關(guān)對(duì)當(dāng)月工作情況進(jìn)行通報(bào)；工作性質(zhì)與內(nèi)容相似的部門相互進(jìn)行評(píng)比。用例分析如下所示：其中一個(gè)用例描述如下所示：四、實(shí)驗(yàn)步驟1、針對(duì)教師講授內(nèi)容，明確用例分析與建模的基本方法，熟悉常用的UML圖形類型。2、分小組展開討論，確定項(xiàng)目選題。針對(duì)選題明確系統(tǒng)的功能性需求和非功能性需求。針對(duì)功能性需求進(jìn)行用例分析與建模。五、實(shí)驗(yàn)要求針對(duì)選定項(xiàng)目的業(yè)務(wù)場(chǎng)景進(jìn)行用例建模，繪制用例圖并編寫用例描述，繪制活動(dòng)圖和魯棒圖。

實(shí)驗(yàn)16五視圖法架構(gòu)設(shè)計(jì)-邏輯架構(gòu)一、實(shí)驗(yàn)?zāi)康?、了解五視圖設(shè)計(jì)方法的基本內(nèi)容；2、掌握邏輯架構(gòu)設(shè)計(jì)的基本方法；3、掌握相關(guān)UML圖形的繪制方法；二、實(shí)驗(yàn)環(huán)境Windows7+Visio2010+Word2010三、實(shí)驗(yàn)內(nèi)容1、邏輯架構(gòu)：邏輯架構(gòu)關(guān)注功能，不僅包括用戶可見的功能，還包括為實(shí)現(xiàn)用戶功能而必須提供的“輔助功能模塊”。2、邏輯架構(gòu)的建立是基于用例模型分析基礎(chǔ)之上，可采用領(lǐng)域分析方法進(jìn)行系統(tǒng)的建模。3、案例分析：最初的業(yè)務(wù)需求：維護(hù)一個(gè)員工檔案表每來(lái)一個(gè)新員工，錄入員工檔案根據(jù)員工檔案每月發(fā)放工資人力專員手工錄入各個(gè)工資項(xiàng)目匯總并計(jì)算工資打印出工資報(bào)表系統(tǒng)的領(lǐng)域模型如下所示：需求開始變更：根據(jù)規(guī)則生成工資表基本工資來(lái)源于對(duì)員工的職務(wù)定級(jí)考核工資=職務(wù)定級(jí)×績(jī)效考核項(xiàng)目提成來(lái)源于項(xiàng)目結(jié)束后的收益……更新后的領(lǐng)域模型：四、實(shí)驗(yàn)步驟1、針對(duì)教師講授內(nèi)容，明確用例分析與建模的基本方法，熟悉常用的UML圖形類型。2、分小組展開討論，針對(duì)用例模型進(jìn)行系統(tǒng)的邏輯模型設(shè)計(jì)。五、實(shí)驗(yàn)要求針對(duì)選定項(xiàng)目的用例模型，采用領(lǐng)域分析法進(jìn)行系統(tǒng)的邏輯架構(gòu)設(shè)計(jì)并完成相關(guān)文檔編寫和UML圖形繪制！

實(shí)驗(yàn)17五視圖法架構(gòu)設(shè)計(jì)-開發(fā)架構(gòu)一、實(shí)驗(yàn)?zāi)康?、了解五視圖設(shè)計(jì)方法的基本內(nèi)容；2、掌握開發(fā)架構(gòu)的基本方法；3、掌握相關(guān)UML圖形的繪制方法；二、實(shí)驗(yàn)環(huán)境Windows7+Visio2010+Word2010三、實(shí)驗(yàn)內(nèi)容開發(fā)架構(gòu)開發(fā)架構(gòu)的目的是確定程序單元以及程序單元的組織結(jié)構(gòu)；其中程序單元包括源文件、配置文件、程序庫(kù)、框架、目標(biāo)單元；程序單元組織包括project劃分、project目錄結(jié)構(gòu)、編譯依賴關(guān)系。好的開發(fā)架構(gòu)設(shè)計(jì)需滿足下面兩圖所說的分層結(jié)構(gòu)：案例分析原始需求：全國(guó)性的績(jī)效考核系統(tǒng)。開發(fā)架構(gòu)如下所示：四、實(shí)驗(yàn)步驟1、針對(duì)教師講授內(nèi)容，明確用例分析與建模的基本方法，熟悉常用的UML圖形類型。2、分小組展開討論，針對(duì)用例模型進(jìn)行系統(tǒng)的邏輯模型設(shè)計(jì)。五、實(shí)驗(yàn)要求針對(duì)選定項(xiàng)目的邏輯模型，進(jìn)行系統(tǒng)的開發(fā)架構(gòu)設(shè)計(jì)并完成相關(guān)文檔編寫和UML圖形繪制！實(shí)驗(yàn)18五視圖法架構(gòu)設(shè)計(jì)-數(shù)據(jù)架構(gòu)一、實(shí)驗(yàn)?zāi)康?、了解五視圖設(shè)計(jì)方法的基本內(nèi)容；2、掌握數(shù)據(jù)架構(gòu)設(shè)計(jì)的基本方法；3、掌握相關(guān)UML圖形的繪制方法；二、實(shí)驗(yàn)環(huán)境Windows7+Visio2010+Word2010三、實(shí)驗(yàn)內(nèi)容1、數(shù)據(jù)架構(gòu)數(shù)據(jù)架構(gòu)的目的是確定要存儲(chǔ)的數(shù)據(jù)以及存儲(chǔ)格式；其中存儲(chǔ)的數(shù)據(jù)可以是文件、關(guān)系數(shù)據(jù)庫(kù)、實(shí)時(shí)數(shù)據(jù)庫(kù)；存儲(chǔ)格式包括文件格式、數(shù)據(jù)庫(kù)圖表。2、案例分析：下圖給出了績(jī)效考核的領(lǐng)域模型，在此基礎(chǔ)上進(jìn)行數(shù)據(jù)架構(gòu)的設(shè)計(jì)：數(shù)據(jù)庫(kù)的映射如下所示：四、實(shí)驗(yàn)步驟1、針對(duì)教師講授內(nèi)容，明確數(shù)據(jù)架構(gòu)設(shè)計(jì)的基本方法，熟悉常用的UML圖形類型。2、分小組展開討論，在邏輯架構(gòu)基礎(chǔ)上進(jìn)行系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計(jì)。五、實(shí)驗(yàn)要求針對(duì)選定項(xiàng)目的邏輯架構(gòu)，進(jìn)行系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計(jì)并完成相關(guān)文檔編寫和UML圖形繪制！

實(shí)驗(yàn)19五視圖法架構(gòu)設(shè)計(jì)-運(yùn)行架構(gòu)一、實(shí)驗(yàn)?zāi)康?、了解五視圖設(shè)計(jì)方法的基本內(nèi)容；2、掌握運(yùn)行架構(gòu)設(shè)計(jì)的基本方法；3、掌握相關(guān)UML圖形的繪制方法；二、實(shí)驗(yàn)環(huán)境Windows7+Visio2010+Word2010三、實(shí)驗(yàn)內(nèi)容1、運(yùn)行架構(gòu)運(yùn)行架構(gòu)的目的是確定控制流和控制流的組織；其中控制流包括進(jìn)程、線程、服務(wù)程序；控制流組