架構師培訓4-高層軟件架構的設計

1、第四章 高層軟件架構的設計在高層設計階段，主要工作是分析與設計軟件的體系結構。通過系統(tǒng)分解，確定子系統(tǒng)的功能和子系統(tǒng)之間的關系，以及模塊的功能和模塊之間的關系，產生體系結構設計報告。這個階段是系統(tǒng)架構師發(fā)揮作用的主要位置，高層架構設計過程設計流程如下。確定設計策略確定 約束 因素設計 準備系統(tǒng)分解設計設計評審撰寫 文檔在分析階段，我們建立模型表示真實的世界，以便理解業(yè)務過程以及這個過程中所要用到的信息?；旧险f，分析首先是分解，把復雜信息需求的綜合問題，分解成易于理解的多個小問題。然后通過建立需求模型來對問題領域進行組織、構造并且編制文檔。分析建模過程必須要用戶參與，并且需要用戶解釋需求，并且

2、驗證建立的模型是否正確。設計也稱之為架構設計，實際上也是個建模過程，它把分析階段得出的信息也就是需求模型，轉換為稱之為解決方案的模型。一般來說架構設計是一個高度技術的工作，一般不需要涉及太多的用戶，但需要系統(tǒng)分析人員和部分開發(fā)人員參與。因為系統(tǒng)設計的輸出就是開發(fā)的藍圖。下面討論在這一階段一系列的原則和思想。第一節(jié) 高層軟件架構的規(guī)劃一、客戶服務結構（C/S architecture）這個結構可以用部署圖來表示。二、多級體系結構（four-tier architecture）這里使用了組件圖和部署圖。三、多級體系結構（串行法和團聚法）四、流處理體系結構（procedural prcessing

3、architecture）五、代理體系結構（agent architecture）六、聚合體系結構（aggregate architecture）七、聯(lián)邦體系結構（federation architecture）第二節(jié) 面向過程的架構設計面向過程的架構設計，又稱之為結構化設計。它使用“輸入 處理 輸出”這樣一個基本模型，這些模式比較適用于描述商業(yè)軟件，它們中大多數(shù)依靠數(shù)據(jù)庫或者文件，并且不太需要復雜的實時處理。我們可以使用流程圖來記錄各個子系統(tǒng)的結構，系統(tǒng)流程圖標識了每個程序，以及他們存取的數(shù)據(jù)。一、系統(tǒng)流程圖系統(tǒng)流程圖是用圖形的方式描述哪些子系統(tǒng)是系統(tǒng)自動完成的，哪些是需要人工參與的，并且顯

4、示了數(shù)據(jù)流和控制流。系統(tǒng)流程圖主要描述大的信息系統(tǒng)，這種大的信息系統(tǒng)由單個的子系統(tǒng)和大量的程序塊組成。繪制流程圖使用的主要符號如下，也可以有其它的變體。下面是一個銷售系統(tǒng)的流程。二、結構圖及其應用結構化設計的基本任務，是自頂向下的分解任務，結構圖是用來展示計算機程序模塊之間的層次關系。結構圖的主要符號如下：下面是一個工資系統(tǒng)的部分結構圖。三、模塊算法設計（偽碼）結構化設計的另一個需求，是描述每個模塊的內部邏輯，我們可以用自己熟悉的語言來定義偽碼（比如C），使用偽碼并不是寫出程序，而是為了更清楚地描述模塊級的邏輯。這樣也可以避免各種圖泛濫成災。第三節(jié) 面向對象的架構設計在面向對象的設計中，關注點

5、變成了消息和響應機制。而我們由面向對象的分析轉向面向對象的設計是一個自然的結果，在OOA中已經提供了足夠多的信息，在高層設計階段，我們可以用包圖來建立體系架構。在詳細設計階段，可以利用類圖建立相應的體系結構。下圖是以類表達的典型的Nhibernate體系結構。在設計的各個階段，在必要的重點位置，我們還可以用順序圖或者協(xié)作圖來描述一些最重要的消息機制。面向對象的設計不僅僅是根據(jù)功能性和非功能性需求建立一些相應的結構，更重要的是要分析一些潛在問題，通過種種設計技巧，提升系統(tǒng)的整體性能。下面我們來討論有關問題。第四節(jié) 高層設計中的架構分析面向對象的設計并不是簡單的把需求分析中的領域模型轉換成設計模型

6、就可以了，架構師必須在由需求分析獲取架構因素，因此我們首先必須研究架構分析的問題。另外，由于面向對象設計的成熟和發(fā)展，已經形成了一系列的重要設計原則和方法，這些原則和方法可以大大的提高我們的設計質量，這是使用OOD必須關注的問題。面向對象的架構設計與結構化設計根本的不同，是非常注意實時信息，也就是消息和響應機制。另一方面，也非常注意代碼重用，設計的目標往往是大型的、分布式的、可升級、可維護而且是安全的體系，這也對設計者提出了更高的要求。架構分析的本質，是識別可能影響架構的因素，了解它的易變性和優(yōu)先級，并解決這些問題。其難點是，應該了解提出了什么問題，權衡這些問題，并掌握解決影響架構重要因素的眾

7、多方法。架構分析是高優(yōu)先級和大影響力的活動。架構分析對如下的工作而言是有價值的：l 降低遺漏系統(tǒng)設計核心部分的風險l 避免對低優(yōu)先級的問題花費過多的精力l 為業(yè)務目標定位產品一、架構分析 架構分析是在功能性需求過程中，有關識別非功能性需求的活動。1）架構分析需要解決的問題下面說明在架構級別上，需要解決的諸多問題的一些示例：l 可靠性和容錯性需求是如何影響設計的？l 購買的子組件的許可成本將如何影響收益？l 分布式服務如何影響有關軟件質量需求和功能需求的？l 適應性和可配置性是如何影響設計的？2）架構分析的一般步驟架構分析有多種方法，大多數(shù)方法都是以下步驟的變體。1辨識和分析影響架構的非功能性需

8、求。2對于那些具有重要影響的需求而言，分析可選方案，并做出處理這些影響的決定，這就是架構決策二、識別和分析架構因素 1）架構因素任何需求對一個系統(tǒng)架構都有重要影響。這些影響包括可靠性、時間表、技能和成本的約束。比如，在時間緊迫、技能有限同時資金充足的情況下，更好的辦法是購買和外包，而不是內部開發(fā)所有的組件。然而，對架構最具影響的的因素，包含功能、可靠性、性能、支持性、實現(xiàn)和接口。通常是非功能性屬性（如可靠性和性能）決定了某個架構的獨到之處，而不是功能性需求。2）質量場景在架構因素分析期間定義質量需求的時候，推薦應用質量場景。它定義了可量化（至少是可觀測）的響應，并且因此可以驗證。質量場景很少使

9、用模糊的不具度量意義的描述，比如“系統(tǒng)要易于修改”。質量場景用<激發(fā)因素><可量化響應>的形式作簡短的描述，如：l 當銷售額發(fā)送到遠程計稅服務器計算稅金的時候，“大多數(shù)”時候必須2秒之內返回。這一結果是在“平均”負載條件下測量的。l 當系統(tǒng)測試志愿者提交一個錯誤報告的時候，要在一個工作日內通過電話回復。這里，“大多數(shù)”和“平均”需要軟件架構師作進一步的調查和定義。質量場景直到做到真的可測試的時候，才是真正有效的。這就意味著需要有一個詳細的說明。3）架構因素的描述架構分析的一個重要目標，是了解架構因素的影響、優(yōu)先級和可變性（靈活性以及未來演變的直接需要）。因此，大多數(shù)架構

10、方法，都提倡對以下信息建立一個架構因素表。因素測量和質量場景可變性（當前靈活性和未來演化）因素（和其變化）對客戶的影響，架構和其它因素獲取成功的優(yōu)先級困難或風險可靠性 - 可恢復性從遠程服務失敗中恢復。當遠程服務失敗的時候，偵聽到遠程服務重新在線的一分鐘內，重新與之建立聯(lián)系，在產品環(huán)境下實現(xiàn)正常的存儲裝載。當前靈活性我們的SME認為直到重新建立連接前，本地客戶簡化的服務是可以接受的（也是可取的）。演化在2年之內，一些零售商可能選擇支付本地完全復制遠程服務的功能（如稅金計算器）?？赡苄?？高。對大規(guī)模設計影響大。零售商確實不愿意遠程服務失敗，因為這將限制或阻止它們使用POS進行銷售。高低注：SME

11、表示主題專家。請注意上面的分類方法：可靠性可恢復性。在這里這么說明不等于它是唯一的或者最好的，但它對架構因素的分類很有效。3）架構因素和UP工件在架構設計中，中心功能需求庫就是用例，它的構想和補充規(guī)范，都是創(chuàng)建因素表的重要源泉。在用例中，特殊需求、技術變化、未決問題應該被反復審核。其隱含或者清晰的架構因素要被統(tǒng)一整理到補充規(guī)范里面去。例如：用例1：Process Sale主要成功場景1特殊需求l 90%的信用授權應該在30秒內響應l 無論如何，當遠程服務如庫存系統(tǒng)失敗的時候，我們需要強健的恢復措施。l 技術和數(shù)據(jù)變化表2a. 商品的表識可以通過條形碼掃描器或者是鍵盤輸入。未決問題l 稅法的變化

12、是什么？l 研究遠程服務的恢復問題。三、架構因素的解析架構設計的技巧就是根據(jù)權衡、相互依賴關系和優(yōu)先級對架構因素的解決作出合適的選擇。但這還不全面，老練的架構師具有多種領域的知識（例如：架構樣式和模式、技術、產品、缺陷和趨勢），并且能把這些知識應用在它們的決定中。1）記錄架構的可選方案、決定和動機不管目前架構決策的原則有多少，事實上所有的架構方法都推薦記錄：可選的架構方案；決定；影響因素；顯著問題；決定動機。這些記錄按不同的的形式或者完善程度，被稱之為：技術備忘錄；問題卡；架構途徑文檔。技術備忘錄的一個重要的的方面就是動機或者原理，當開發(fā)者或者架構師以后需要修改系統(tǒng)的時候，架構師可能已經忘了他

13、當初的設計依據(jù)（一個資深架構師同時帶多個項目的情況非常多見），備忘錄對理解當時的設計背后的動機極為有用。解釋放棄被選方案的理由十分重要，在將來產品進化的過程中，架構師也許需要重新考慮這些備選方案，至少知道當初有些什么備選方案，為什么選中了其中之一。技術備忘錄的格式并不重要，關鍵是簡單、清楚、表達信息完整。技術備忘錄問題：可靠性-從遠程服務故障中恢復解決方案概要：通過使用查詢服務實現(xiàn)位置透明，實現(xiàn)從遠程到本地的故障恢復和本地服務的部分復制架構因素l 從遠程服務中可靠恢復l 從遠程產品數(shù)據(jù)庫的故障中可靠恢復解決方案在服務工廠創(chuàng)建一個適配器動機零售商不想停止零售活動遺留問題無考慮過的備選方案與遠程服

14、務廠商簽訂“黃金級”服務協(xié)議2）優(yōu)先級下面是指導做出架構決定目標：1不可改變的約束，包括安全和法律方面的事務2業(yè)務目標3其它全部目標早期要決定是否應該避免保證未來的設計，應該實事求是的考慮，那些將要推遲到未來的場景，有多少代碼需要改變？工作量將是多少？仔細考慮潛在的變更將有助于揭示什么是首要考慮的重要問題。一個低耦合高內聚的產品，往往比較容易適應將來的變化，但也要仔細分析這樣付出的代價，在這個問題上，架構師的掂量往往是決定這個項目的生命線。3）系統(tǒng)不同方面的分離和影響的局部化架構分析的另外一個基本原則，就是實現(xiàn)分離系統(tǒng)的不同方向。系統(tǒng)不同方向的分離，是在架構級別上關于低耦合和高內聚的一種大尺度

15、思考方法。雖然它們也應用在小尺度對象上，但這樣的分離對于架構問題尤其突出。因為系統(tǒng)的不同方面很廣泛，而且架構的解決方案涉及重要的設計選擇。至少有三個實現(xiàn)系統(tǒng)不同方面分離的大尺度技術：1把系統(tǒng)的一個方面模塊化到一個獨立的組件（如子系統(tǒng)）中并且調用它的服務。2使用裝飾器模式3采用后編譯器技術和面向方面的技術有了架構分析的結果，我們就可以討論高層架構設計本身的一系列原則了。第五節(jié) 高層架構設計中的層模式一、面向對象軟件架構的優(yōu)點 1）面向對象軟件架構的維和視圖一個系統(tǒng)的架構包括了多個維。例如：l 邏輯架構：描述系統(tǒng)的層、包、主要框架、類、接口和子系統(tǒng)的概念組織方式。l 部署架構：描述系統(tǒng)的進程如何分

16、配給處理單元和網(wǎng)絡配置。統(tǒng)一過程建議采用架構的六種視圖（邏輯、部署等），我們后面會討論這個問題。2）架構模式和模式的種類架構模式是有關大尺度和粗粒度的設計，特別是應用在早期迭代過程（細化階段）。也就是當主要的結構和連接建立起來的時候的一些原則。 l二、層模式1）解決方案：層模式（Layers pattern）的基本思想很簡單。l 根據(jù)分離系統(tǒng)的多個具有清晰、內聚職責的設計原則，把系統(tǒng)大尺度的邏輯結構組織到不同的層中，每一層都具有獨立和相關的職責，使得較低的層為低級和通用的服務，較高的層更多的為特定應用。l 從較高的層到較低的層進行協(xié)作和耦合，避免從底層到高層的耦合。層是一個大尺度的元素，通常由

17、一些包或者子系統(tǒng)組裝而成。層模式與邏輯架構相關，也就是說，它描述了設計元素概念上的組織，但不是它物理上的包或者部署。層為邏輯架構定義了一個N層模型，稱之為分層架構（Layers Architecture），它作為模式得到了極為廣泛的應用和引述?？蚣埽╢ramework）：一般來說框架具有如下的特征：l 是內聚的類和接口的集合，它們協(xié)作提供了一個邏輯子系統(tǒng)的核心和不變部分的服務。l 包含了某些特定的抽象類，它們定義了需要遵循的接口。l 通常需要用戶定義已經存在的框架類的子類，是客戶得以擴展框架的服務。l 所包含的抽象類可能同時包含抽象方法和實例方法。l 遵循好萊塢原則：“別找我們，我們會找你?！?/p>

18、就是用戶定義得類將從預定義的類中接受消息，這通常通過實現(xiàn)超類的抽象方法來實現(xiàn)。2）問題：l 由于系統(tǒng)的許多部分高度的耦合，因此源代碼的變化將波及整個系統(tǒng)。l 由于應用邏輯與用戶接口捆綁在一起，因此這些應用邏輯在其它不同的接口上無法重用，也無法分布到另一個處理節(jié)點上。l 由于潛在的通用技術服務或業(yè)務邏輯，與更具體的應用邏輯捆綁在一起，因此這些通用技術服務或者業(yè)務邏輯無法被重用，或者分布到其它的節(jié)點，或者被不同的實現(xiàn)簡單的替換。l 由于系統(tǒng)的不同部分高度的耦合，因此難以對不同開發(fā)者清晰界定格子的工作界限。l 由于高度耦合混合了系統(tǒng)的各個方面，因此改進應用程序的功能，擴展系統(tǒng)，以及使用新技術進行升級

19、往往是艱苦和代價高昂的。3）示例：信息系統(tǒng)一般分層邏輯架構。在具體架構設計的時候，可以建立比較詳細的包圖，但是，并不需要面面俱到。架構視圖的核心，是展示少數(shù)值得注意的元素。統(tǒng)一過程的架構視圖是這樣告誡的：“選擇一小組有意義的元素來傳達主要的思想?！碧貏e注意：在面向對象的層模式中，底層的類不僅僅提供調用，更主要的是提供父類，很多情況下，需要使用配置文件來動態(tài)裝配，這樣才能適應不同的需求。4）層與層之間和包與包之間的耦合邏輯架構還可以包含更多的信息，用來描述層與層以及包與包之間值得注意的耦合關系。在這里，可以用依賴關系表達耦合，但并不是確切的依賴關系，而僅僅是強調一般的依賴關系。有時候也可以不畫出

20、類，專注于包之間的依賴關系。5）協(xié)作：在架構層面上，有兩個設計上的決策： 1什么是系統(tǒng)的重要部分？2它們是如何連接的？在架構上，層模式對定義系統(tǒng)的重要部分給出了指導。象外觀、控制器、觀察者這些模式，通常用于設計層與層、包與包之間的連接。6）外觀模式GoF的外觀模式，定義了一個公共的外觀對象綜合子系統(tǒng)的服務。外觀不應該表示大量子系統(tǒng)的操作，更確切的說，外觀更適合表示少量的高層操作、粗粒度的服務。當外觀呈現(xiàn)大量的底層操作的時候，會趨向于變得沒有內聚力。外觀模式為了一組子系統(tǒng)提供一個一致的方式對外交互。這樣就可以使客戶和子系統(tǒng)絕緣，可以大大減少客戶處理對象的數(shù)目，注意下圖。使用Facade之前使用F

21、acade之后這樣本來一個類的修改可能會影響一大片代碼，而加了外觀類以后只需要修改很少量的代碼就可以了，使系統(tǒng)的高級維護成為可能。7）通過觀察者實現(xiàn)向上協(xié)作外觀模式通常用于高層到底層的操作（底層提供外觀，高層實現(xiàn)調用）。當需要上層對底層的操作的時候，可以使用觀察者模式。也就是上層響應底層的事件，但這個事件的執(zhí)行代碼由上層提供。8）層之間的松散耦合大部分的多層架構不能像基于OSI 7層模型的網(wǎng)絡協(xié)議一樣，上一層只能調用下一層。相反，在信息系統(tǒng)中的分層通常是“松散的分層”或者說是“透明的分層”。一個層的元素可以和多個其它層的元素協(xié)作或耦合。對于一般層之間耦合的觀點是：l 所有較高的層都可以依賴于技

22、術服務層和基礎層 比如在Java中，所有的層都依賴于java.util包元素。l 依賴于業(yè)務基礎設施層的領域層是要首先考慮的。l 表示層發(fā)出對應用層的調用，應用層再對領域層進行服務調用。除非不存在應用層，表示層一般是不直接對領域層進行調用的。l 如果應用是一個單進程的“桌面”程序，那么領域層的軟件對象對于表示層、應用層和更底層（如技術服務層）可以直接可見或者在中間傳遞。l 另一方面，對于一個分布式系統(tǒng)，那么領域層對象的可序列化復制對象（通常稱之為值對象或者數(shù)據(jù)容納對象）通?？梢员粋鬟f到表示層。在這種情況下，領域層被部署到另一臺服務器上，客戶端節(jié)點得到服務器數(shù)據(jù)的拷貝?，F(xiàn)在的問題是，與技術服務層

23、和基礎層的關系不是很危險嗎？正如GRASP的受保護變化模式和低耦合模式的論述，耦合本身并不是個問題，但是與變化點和演化點的耦合是不穩(wěn)定的而且是難于修正的。幾乎沒有任何理由，去抽象和隱蔽某些不太可能變化的因素，即使這些因素可能變化，這種變化所產生的影響也是微乎其微的。例如，建立一個Java應用程序，隱蔽對Java類庫的訪問有什么意義呢？與類庫的多個緊密耦合不太可能是個問題，因為它們是相對穩(wěn)定而且無處不在的。9）應用層是可選的嗎如果存在應用層，那么它所包含的對象要負責了解客戶端的會話狀態(tài)，協(xié)調表示層和領域層，以及控制工作流。10）在不同的層上模糊集合成員一些元素必定只屬于一個層，但有些元素卻難以區(qū)

24、分，特別是處在技術服務層和基礎層之間，或者領域層和業(yè)務基礎設施層之間的元素。其實這些層之間只存在模糊的差異，所以，“高層”、“低層”、“特殊”、“一般”這些術語是可以接受的。開發(fā)組并不需要在限定的分類上做出決定，可以粗略的把一個元素歸類到技術服務層或者基礎層，也可以稱之為“基礎設施層”，注意，對于層并沒有十分確定的命名習慣和約定，文獻上各種命名上的矛盾是常見的，研究問題主要把握精髓，不要被這些表面的區(qū)別搞昏了頭。11）使用反射動態(tài)裝入對象不論是Java還是.NET，都很好的支持了反射，這樣，建立一種通用對象容器成為可能，在詳細設計的討論中，我們會討論一個這樣的例子。12）利用工廠模式構建通用的

25、創(chuàng)建者為了保證層的通用型，在層中的必要部分，可以采用工廠模式創(chuàng)建對象，這個問題我們也會在詳細設計的討論中加以闡述。13）層模式的優(yōu)點：l 層模式可以分離系統(tǒng)不同方面的考慮，這樣就減少了系統(tǒng)的耦合和依賴，提高了內聚性，增加了潛在的重用性，并且增加了系統(tǒng)設計上的清晰度。l 封裝和分解了相關的復雜性。l 一些層的實現(xiàn)可以被新的實現(xiàn)替代，一般來說，技術服務層或者基礎層這些比較低層的層不能替換，而表示層、應用層和領域層可能進行替換。l 較低的層包含了可重用的功能。l 一些層可能是分布式的（主要是領域層和技術服務層）。l 由于邏輯上劃分比較清楚，有助于多個小組開發(fā)。三、模型-視圖分離原則這個原則我們已經討

26、論了多次，但這里還是有必要總結一下。非窗口類如何與窗口類通信？推薦的做法，是其它組件不和窗口對象直接耦合。因為窗口和特定的應用有關，耦合太強不利于重用。這就是模型-視圖分離的原則。模型視圖分離（Model View Separation）的原則，已經發(fā)展為模型-視圖-控制器（Model-View-Controller MVC）模式的一個關鍵原則。MVC起源于一個小規(guī)模的Web架構（比如Struts），近來，這個術語（MVC）被分布式設計團體采納，也應用在大規(guī)模的架構上，模型指領域層，視圖指表示層，控制器指應用層的工作流對象。模型視圖分離原則的動機包括：l 為關注領域處理而不是用戶界面而定義內聚

27、的模型。l 允許分離模型和用戶界面層的開發(fā)。l 最小化界面因為需求變更給領域層帶來的影響。l 允許新的視圖方便的連接到領域層而不影響領域層。l 允許在同一模型對象上有多個聯(lián)立的視圖。l 允許模型層的運行獨立于用戶界面層。l 允許方便的把模型層簡單的連接到另一個用戶界面框架上。第六節(jié) 框架設計的方法學問題一、框架（Framework）的基本概念 事實已經表明，一個軟件組織，合理的組織開發(fā)和使用框架，并且能跨越組織邊界進行合作的能力越來越重要。軟件架構使得您能夠組合大量支撐產品和服務，一個共享的架構，可以使企業(yè)開發(fā)團隊很方便的分解問題，從而確定： 哪些可以企業(yè)（或者開發(fā)組）內部解決； 哪些可以使用

28、已有的服務。 當架構跨越組織的時候，你就可以調選公司內外組織的合作力量，獲得共享架構帶來的好處，在這樣的情況下，架構設計組或者整個公司都需要掌握一些新的組織技能。 當公司內部存在產品線的時候，設計優(yōu)秀的共享架構都可以帶來實實在在的好處。（1）框架框架最簡單的形式是指已開發(fā)過并已測試過的軟件的程序塊，這些程序塊可以在多個軟件開發(fā)工程中重用?？蚣芴峁┝艘粋€概括的體系結構模版，可以用這個模板來構建特定領域中的應用程序。（2）為什么會出現(xiàn)應用框架您只要細心地研究真實的應用程序，就會發(fā)現(xiàn)程序大致上由兩類性質不同的組件組成，一類與程序要處理的具體事務密切相關，我們不妨把它們叫做業(yè)務組件；另一類是應用服務。

29、人們自然會想要是把這些在不同應用程序中有共性的一些東西抽取出來，做成一個半成品程序，這樣的半成品就是所謂的程序框架，再做一個新的東西時就不必白手起家，而是可以在這個基礎上開始搭建。實際上，大型軟件企業(yè)往往選擇搭建自己的框架。（3）為什么要用框架？因為軟件系統(tǒng)發(fā)展到今天已經很復雜了，特別是服務器端軟件，設計到的知識，內容，問題太多。在某些方面使用別人成熟的框架，就相當于讓別人幫你完成一些基礎工作，你只需要集中精力完成系統(tǒng)的業(yè)務邏輯設計。而且框架一般是成熟，穩(wěn)健的，他可以處理系統(tǒng)很多細節(jié)問題，比如，事物處理，安全性，數(shù)據(jù)流控制等問題。還有框架一般都經過很多人使用，所以結構很好，所以擴展性也很好，而

30、且它是不斷升級的，你可以直接享受別人升級代碼帶來的好處。目前一些常用的開源框架如下： Struts / WebWork / Tapestry / Spring MVCWeb層 Spring（輕量級容器）Spring框架的主要內容1）核心概念 依賴注入輕量級容器（應用上下文） AOP 聲明性企業(yè)級服務（如事務）2）持久化：JDBC封裝、與其它開源實現(xiàn)的整合3）Spring MVC4）遠程調用、EJB服務的替代方案 Hibernate / ibatis / JDO業(yè)務層數(shù)據(jù)層（持久層） 二、框架設計的核心原則 五個核心原則： 構想、預見、節(jié)奏、協(xié)作和簡化。 1）構想構想原則說明了如何向架構的受益人

31、描繪一幅一致的、有約束力的、以及靈活的未來圖像。作為架構師，關鍵是要確保它提出來的架構設想與公司的業(yè)務目標相吻合，對于一個大型公司，做到這點事實上并不容易。再次提醒，面向對象的架構，關鍵不是調用，而是繼承和重用。 2）節(jié)奏 節(jié)奏原則確保軟件組織可以定期根據(jù)可預測的速度、內容和質量對工件進行取舍。在新穎的性能和規(guī)定的發(fā)布日期之間，有時候必須進行取舍，以確保發(fā)布日期，但這點可能和公司高層的設想不同，這如何解決呢？ 3）預見 首席架構師必須對未來發(fā)展走向有敏銳的洞察力，但這種預見往往和現(xiàn)行的標準有沖突，這就需要在兩者間做出平衡，而這種平衡也是非常難處理的。 4）協(xié)作 當首席架構師開始架構設計的時候，

32、協(xié)作顯得及其重要，我們一定要確保公司、周邊合作者、領域架構師和開發(fā)組都能理解架構的關鍵思想， 5）簡化 簡化原則要求澄清并最小化架構與創(chuàng)建，當發(fā)現(xiàn)兩個小組開發(fā)的構件有重疊的部分以后，應該可以考慮指定一個共享的構件，如何實現(xiàn)簡化是構架師最值得關注的一個問題，非此架構設計的意義就顯得不大。 這五個原則被稱之為VRASP模型（Vision、Rhythm、Anticipation、Partnering、 Simplification）。這個模型重點在于軟件架構的組織方面，事實上，軟件架構師得以成功的最大障礙是組織問題而不是技術問題。 三、形成構想 1）把價值映射為架構約束這個問題的本質，是架構受益人如

33、何把客戶價值與架構約束捆綁。這里所謂受益人，實際上是指使用架構的開發(fā)者。用戶價值共享架構受益人受益人用戶價值一致性和靈活性的考慮：一致性的問題：是指受益人使用架構與期望值的符合程度。靈活性的問題：是指受益人不破壞架構的情況下，利用共享框架的創(chuàng)建新的沒有預見到的情況下的容易程度。2）產品線及其挑戰(zhàn)當產品線上有多個產品的時候，為了避免架構的設計被被動的拉向不同的方向，可以使用下面的三步方法：1，清楚、簡明的、闡述一條迫切的用戶價值。 2，把用戶價值映射為少數(shù)的能解決的問題。3，把以上問題轉譯為一組最小的約束條件。遵循準則：1，各方面的一致性2，實施人員信任并使用架構3，架構潛藏的知識對用戶是可識別

34、和可獲得的四、保證節(jié)奏節(jié)奏能夠克服復雜性，確保競爭優(yōu)勢。節(jié)奏有三個元素：速度、內容和質量。速度：一個團隊和另一個團隊之間（架構團隊和開發(fā)工程師團隊之間）同類型交接發(fā)生的頻率，每次交接的時間越是可預測的，移交也就越容易管理。內容：內容是指一個團體向另一個團體提供的價值。當軟件架構師向開發(fā)團隊提交的構架使開發(fā)團隊獲得了實實在在的好處，這個架構就被認為是有價值的。質量：質量的含義是開發(fā)過程確保架構沒有缺陷。遵循準則：1，經理們需要定期評估、同步和調整架構2，架構用戶需要對架構發(fā)布的內容和進度有高度的信心3，通過節(jié)奏協(xié)調明確的活動 五、預測、驗證和調整架構師可以通過自己的經驗和成功使用的架構，合理的猜

35、測將來會發(fā)生什么。例如： 用戶會有什么變化？ 競爭形勢會如何改變？ 運行環(huán)境會如何改變？ 架構的設計必須是能夠適應這種可能的變化。 1）驗證： 在架構設計中，驗證主要指的是對架構基礎假定的測試，在架構成型以前，除非通過測試當初的基礎假定是被確認的，否則就會發(fā)生代價高昂的錯誤。 2）調整： 當預測結果發(fā)生變化的時候，你所面臨的問題就是調整。 六、實現(xiàn)協(xié)作 在軟件架構環(huán)境中，協(xié)作主要涉及對受益人的關系進行管理的過程。 合作并不能保證架構的受益人總是能和您保持一致，但是，當架構供應者發(fā)現(xiàn)他們有哪些功能他們沒有一致的理解的時候，就必須用達成一致的方法來解決這個矛盾。 架構設計者應該和所有的架構受益人合

36、作，使利益最大化，而不是僅僅靠合同和協(xié)議過日子。 注意價值鏈的概念，每個行業(yè)都有自己的價值鏈，成功的構架設計者應該關注這些價值鏈。 幾個準則： 1，架構師需要了解誰是關鍵受益人，他們如何貢獻價值，以及他們需要貢獻什么。 2，和受益人之間達成明確和強制性的契約。 3，通過制度和非正式的規(guī)范強化合作。 七、簡化 架構師和高級經理應該協(xié)力保持架構的平衡。當某個新產品加入的時候，會大大增加架構的體積。架構師應該關注通用的服務，某個客戶專用的能力不應該放入通用的架構里面。架構師應該仔細考慮，極力找出隱蔽在多個不同需求中的公共元素。對于不能放棄的大型客戶，需要仔細的談判，提出多種解決方案供用戶選擇，而不是

37、簡單的行或者不行。 準則： 1，開發(fā)人員長期不斷的使用架構的時候，減少了總成本和復雜性。 2，架構師明確理解關鍵最小需求，并構造多應用共享核心單元。 3，當不能被共享或者增加了不必要的復雜性的時候，應該把相關元素從核心移走。在一個善于簡化的組織中，開發(fā)人員會不斷地清理核心，因為人人都知道復雜的核心所帶來的麻煩。第七節(jié) 面向服務架構（SOA） 面向服務的架構 (Service-Oriented Architecture SOA)是一種形式化的分離服務的架構風格。 面向服務的架構關注的是哪些是服務向用戶提供的功能，哪些是需要這些功能的系統(tǒng)，這種分離，使用一種服務合約（Service Contrac

38、t）的機制來完成的。本質上來說，SOA體現(xiàn)的是一種新的系統(tǒng)架構，SOA的出現(xiàn)，將為整個企業(yè)級軟件架構設計帶來巨大的影響。一、SOA的優(yōu)點SOA框架的特點是以服務為中心，它把應用程序劃分成具有明確定義接口的模塊，從而得到服務和應用程序之間相當松散的耦合。在SOA中，服務供應商和消費者是兩個獨立的實體。面向服務的架構的優(yōu)點主要體現(xiàn)在以下幾個方面：l 降低應用開發(fā)費用。l 降低維護費用。l 增長的公司敏捷性。l 生成對應用程序和設備的故障、中斷更具免疫力的系統(tǒng)，提高整體的可靠性。l 提供了一條應用系統(tǒng)的升級途徑，對比使用單一的應用程序的時候，需要替換整個應用系統(tǒng)的標準升級方法，顯然更為經濟，更不容易

39、失敗。二、SOA的特性SOA 有以下特性：l 服務具有明確的接口（合約）與策略。l 服務通常代表業(yè)務功能或者領域。l 服務擁有模塊化的設計。l 服務被松散的耦合在一起。l 服務是可以被發(fā)現(xiàn)的。l 服務的位置對客戶是透明的。l 服務是獨立于傳輸層的。l 服務是獨立于平臺的。SOA可以通過很多方式來實現(xiàn)，但最常用的SOA是用Web Service來實現(xiàn)，這主要應為Web Service的獨立于平臺的特性和其它特性更符合SOA 的規(guī)則。1）服務具有明確的接口與策略明確定義服務具有的接口（合約）是SOA 的核心定義。合約應該包含兩部分內容，一個是接口，另一個是業(yè)務策略。普通對象概念的接口包括：l 數(shù)據(jù)

40、類型。l 期望的輸出。l 必需的輸入。l 錯誤信息。SOA的合約擴大了接口的概念，包括：l 所提供的功能。l 需要的輸入和期望的輸出。先決條件。l 后置條件。l 錯誤處理。l 服務品質保證等。關于業(yè)務策略，事實上服務的生產者和消費者都要定義策略，包括可靠性、可用性、安全性等等。1所提供的功能確切說明服務允許完成什么。2，期望的輸入和輸出服務期待什么樣的輸入以及它能提供什么樣的輸出，對客戶來說這是一個重要的信息。3，先決和后置條件先決條件：服務激活前存在的輸入或者應用程序的狀態(tài)，最常見的輸入是安全口令。后置條件：請求被處理以后服務的狀態(tài)。比如服務作為某個事物的一部分來調用的，這時候服務必須接到事

41、務協(xié)調者的通知后才能完成這個事物的提交。服務如何應對錯誤是絕對的后置條件，系統(tǒng)出錯以后不同的錯誤系統(tǒng)應該是什么狀態(tài)，這點必須寫清楚。4，錯誤處理錯誤處理是另外一個需要在合約中說明的領域，從UML的觀點來看，錯誤是一個通道，所有錯誤都不返回參與者所期望的價值產品?？蛻粜枰烂枋鲥e誤的數(shù)據(jù)結構或者其它信息。5，服務品質協(xié)議服務品質（QoS）是可選的，但確是合約的重要組成部分，因為消費者很大程度上可以根據(jù)提供者提供的服務水準，來選擇它們的提供者。服務品質包括諸如：性能、多線程、容錯之類問題。6，注冊表注冊表（Registry）把所有的東西聯(lián)系到了一起，它是服務保存信息和登記信息的地方，也是消費者找

42、尋和履行合同的地方。注冊表這個術語有很多意思。一個注冊表可以為消費者提供一個指定的查詢標準，來查找合約的機制。然后消費者將和服務聯(lián)接在一起。注冊表可以由企業(yè)、獨立來源、或者需要提供服務的其它業(yè)務組織來維護和提供，所有的注冊表都需要實現(xiàn)允許獨立登記，讓消費者查找服務提供者并且和它們連接的應用程序編程接口（API）。注冊表是把消費者和服務方分離開來的核心機制，這種分離允許SOA增加需求能力，并且提供連續(xù)可用的服務。注冊表并不一定需要包含合約，注冊表可以包括提供者所提供的服務以及合約地點的描述信息，這樣可以允許提供者在本地維護自己的合約，這樣也可能更加方便。2）服務代表業(yè)務領域服務可以用來建立各種各

43、樣的問題的領域，即可以是企業(yè)領域，也可以是技術領域。SOA真正的能力，在與可以為企業(yè)領域建模，因為業(yè)務服務通常比技術服務更加難以實現(xiàn)，無論對內和對外都更加有價值，所以SOA真正持久的價值在于建立一個重要業(yè)務過程的服務。3）服務擁有模塊化設計服務由模塊組成，模塊花設計對SOA來說是很重要的，模塊可以被看作是一個執(zhí)行具體、明確功能的軟件和子系統(tǒng)。模塊應該表現(xiàn)為高的內聚性，而且是完整的功能。粗粒度做法是構造一個完整的轉賬模塊，這種模塊提升了系統(tǒng)性能，但減少了可重用性。但是，SOA通過網(wǎng)絡實現(xiàn)服務，網(wǎng)絡擁擠可能是主要矛盾，因此，SOA推薦的是粗粒度設計。這點非常重要。4）服務應該松散耦合服務客戶和服務

44、提供者之間應該實現(xiàn)松散耦合，也就是客戶和提供者之間沒有靜態(tài)的、編譯時刻的依賴關系。服務把它履行職責的細節(jié)隱蔽起來。這種隱蔽，幾乎大部分資料都是建議主要通過GoF 的外觀模式（Facade）實現(xiàn)。5）服務應該是可以被發(fā)現(xiàn)并且支持內省的SOA的靈活性和可復用性另外一個關鍵點，就是動態(tài)發(fā)現(xiàn)和綁定的概念。服務和客戶之間沒有任何靜態(tài)連接，SOA客戶通過注冊表來查找它們想要的功能，而不是使用編譯的時候靜態(tài)連接。因此，服務和客戶都可以自由修改。服務還可以在一個有限的時間內被提供，這就是說它們可以被租借，當客戶超過有效時間以后，將會被迫轉回到注冊表，重新綁定合約或者選擇另外的合約。6）服務是獨立于傳輸機制的客

45、戶使用網(wǎng)絡來訪問和使用服務，SOA 應該獨立于訪問服務的網(wǎng)絡種類，服務獨立于用來訪問他的傳輸機制，意味著需要建立一個適配器來支持訪問它的各種傳輸機制。通常情況下，適配器需要根據(jù)情況來構造（HTTP或者RMI），同一個適配器，也可以被多個服務所使用。7）服務的位置對客戶是透明的服務的位置對客戶透明，實施上表達了客戶調用服務的時候，并不需要關心服務具體的位置。這就使SOA在實現(xiàn)過程具有巨大的靈活性。服務可以被放到最方便的地方去，必要的時候（比如企業(yè)整頓），服務業(yè)可以放到第三方提供者那里。或者服務中斷的時候，可以把服務請求轉發(fā)到完全不同的另一個地點。8）服務應該是獨立于平臺的服務應該獨立于平臺和操作

46、系統(tǒng)。對于Web 服務來說，雖然在理論上，Java和.NET使用著相同的協(xié)議和標準，因此，進行互操作是沒有問題的，但實際上，由于SOAP、協(xié)議中有很多模糊和未定義部分，所以，這之間的互操作還是存在不少問題，需要我們認真加以研究和試驗。三、構建SOA架構時應該注意的問題當架構師基于SOA來構建一個企業(yè)級的系統(tǒng)架構的時候，一定要注意對原有系統(tǒng)架構中的集成需求進行細致的分析和整理?；赟OA的企業(yè)系統(tǒng)架構通常都是在現(xiàn)有系統(tǒng)架構投資的基礎上發(fā)展起來的，我們并不需要徹底重新開發(fā)全部的子系統(tǒng)。SOA可以通過利用當前系統(tǒng)已有的資源(開發(fā)人員、軟件語言、硬件平臺、數(shù)據(jù)庫和應用程序)來重復利用系統(tǒng)中現(xiàn)有的系統(tǒng)和

47、資源。SOA是一種可適應的、靈活的體系結構類型，基于SOA構建的系統(tǒng)架構可以在系統(tǒng)的開發(fā)和維護中縮短產品上市時間，因而可以降低企業(yè)系統(tǒng)開發(fā)的成本和風險。四、服務粒度的控制當SOA架構師構建一個企業(yè)級的SOA系統(tǒng)架構的時候，關于系統(tǒng)中最重要的元素，也就是SOA系統(tǒng)中的服務的構建有一點需要特別注意的地方，就是對于服務粒度的控制。 服務粒度的控制SOA系統(tǒng)中的服務粒度的控制是一項十分重要的設計任務。通常來說，對于將暴露在整個系統(tǒng)外部的服務推薦使用粗粒度的接口，而相對較細粒度的服務接口通常用于企業(yè)系統(tǒng)架構的內部。五、案例：電源銷售服務系統(tǒng)高層架構這里只列出了初步的頂層架構。設計中注意了幾個問題：1，對

48、于管理層和客戶，主要從使用方便性考慮，采用瀏覽器。2，對于工作人員，因為要處理的內容比較復雜，采用應用程序，但是一個免維護的瘦客戶端。3，瘦客戶段并不是指代碼越少越好或者功能越少越好，而是把易變的、需要配置的、需要集中處理的內容轉向應用程序服務器。事實上，客戶端的功能越強，越能緩解服務器的壓力。4，某些特殊的專業(yè)通訊聯(lián)系（比如信用卡授權機構），可以由客戶段直接完成，并不一定一切都通過服務器，但需要向服務器提交必要的信息。5，對于集中處理的部分，采用大粒度設計，以緩解網(wǎng)絡壓力。6，由于服務方采用無狀態(tài)模式，所以要嚴格控制客戶調用信息的時間，對于需要長時間傳輸?shù)男畔?，可以采用其它通道完成?，對于

49、客戶應用程序，某些不是十分大的，變化頻度不是十分高的，調用頻度比較高的數(shù)據(jù)，可以在客戶端建立緩存，并且可以建立關聯(lián)的映像表，這樣就可以對避免對最主要的數(shù)據(jù)處理的擠壓，提高數(shù)據(jù)庫的應用效率，但要考慮修改數(shù)據(jù)時候的并發(fā)策略。第八節(jié) 軟件架構的質量描述和評估一、軟件架構的創(chuàng)建原則每個項目最開始的時候，是構架師最重要的時刻，在創(chuàng)建架構的過程中，可以依照下面的原則：架構應該是精煉的；架構應該是平易近人的；架構應該是易讀的；架構應該是容易理解的；架構應該是可信的；架構不一定要是完美無缺的；不一定要一開始就做大的設計，如果在模型完善和實現(xiàn)之間作個選擇的話，選擇實現(xiàn)它；做最簡單和可行的事情，不要排除未來的需求；架構是共享的財產；讓所有的涉眾都參加進來，但還要能控制局面；架構組的規(guī)模應該??；軟件架構需要做的事情是：