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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hash算法，又叫取余算法。一般是對請求報文中的某項數(shù)據(jù)(key，一般常用客戶端來源IP)計算Hash值，然后按機器數(shù)量(n)取模。

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

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

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

b、來源IP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FastDFS的一次文件下載請求過程是這樣的

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

2.tracker返回一臺可用的storage；

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

1.client詢問zookeeper哪臺server可以執(zhí)行請求；

2.zookeeper返回一臺可用server；

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

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

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

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

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

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

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

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

索引的實時性c、

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

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

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

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

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

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

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

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

--journalCommitInterval

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

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

HA集群用的比較多的是Replica

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

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

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

hash+bucket結(jié)構(gòu)，當鏈表的長度過長時，會采取遷移的措施（擴展原來兩倍的hash表，把數(shù)據(jù)遷移過去，expand+rehash）

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

在shutdown時，會調(diào)用save操作

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

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

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

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

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

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

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

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

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

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