軟件架構學習小結

時間 2019-11-29

原文原文鏈接

軟件架構設計系統整體架構，從需求到設計的每個細節都要考慮到，把握整個項目，使設計的項目儘可能效率高，開發easy，維護方便，升級簡單。本文從架構師職責、軟件架構定義、設計架構、評估架構、架構管理等方面來描寫敘述瞭解軟件架構的含義和如何設計軟件架構。php

1、軟件架構師的職責html

架構師分爲下面幾大類：業務架構師、主題領域架構師、技術架構師、項目架構師（J2EE架構師、.NET架構師等）、系統架構師。java

1、架構師的職責主要體現算法

架構師的職責就是設計一個公司系統的基礎架構，並提供關於如何創建和維護系統的指導方針。詳細來說，架構師的職責主要體現在下面幾方面：spring

1）、負責公司系統的架構設計、研發工做。sql

2）、承擔從業務向技術轉換的橋樑做用。數據庫

3）、協助項目經理制定項目計劃和控制項目進度。編程

4）、負責輔助並指導系統分析開展設計工做。設計模式

5）、負責組織技術研究和攻關工做。緩存

6）、負責組織和管理公司內部的技術培訓工做。

7）、負責組織及帶領公司內部員工研究與項目相關的新技術。

8）、管理技術支撐團隊並給項目、產品開發實施團隊提供技術保障。

9）、理解系統的業務需求，制定系統的整體框架（包含、技術框架和業務框架）。

10）、對系統框架相關技術和業務進行培訓，指導開發者開發。並解決系統開發、執行中出現的各類問題。

2、構架設計師必須具有的技能

經驗：既包含在問題領域的經驗（經過完全瞭解需求），也包含在軟件project領域的經驗。對於一個構架團隊，這些素養要求可由各團隊成員來分別承擔，但當中至少要有一名構架設計師能夠把握項目的全局。

領導才幹：能夠推進各個團隊的技術進展，並能在壓力下做出關鍵性的決策而後將其貫徹究竟。要提升效率，構架設計師和項目經理必須緊密協做。構架設計師主要負責解決技術問題，項目經理主要負責解決行政管理問題。構架設計師必須有權在技術問題上做出決定。

溝通：能夠贏得他人的信任，以對其進行說服、激勵和指導。構架設計師不能靠命令進行領導，而必須要贏得項目中其它人員的贊同。爲了提升效率，構架設計師必須贏得項目團隊、項目經理、客戶、用戶羣體以及管理團隊的尊敬。

以目標爲中心、積極主動：不懈地追求成效。構架設計師是推進項目發展的技術動力，而不是空想家。在其職業生涯中，成功的構架設計師一直都要在捉摸不定和承受壓力的狀況下做出折衷決定。構架設計師僅僅有將注意力集中在該作的事情上，才幹在項目中取得成功。

專業：精通構架設計的理論、實踐和工具，並掌握多種參考構架、基本的可重用構架機制和模式（好比J2EE架構等）。具有系統設計員的所有技能，但涉及面更廣、抽象級別更高。

2、軟件架構、架構模式、參考模型、參考架構

1、對於軟件架構定義有很是多種，通用的定義是：某個軟件或計算機系統的軟件架構是該系統的一個或多個結構，他們由軟件元素，這些元素的外部可見屬性以及這些元素之間的關係組成。

這裏所說的某個元素的「外部可見屬性」是指其它元素對該元素所作的若是，如它所提供的服務、性能特徵、錯誤處理、共享資源的使用，等等。

其它的定義包含：架構是一種高層設計。架構是系統的總體結構。架構是一個軟件或系統的組件、組件之間的相互關係以及管理其設計和演變的原理和方針的結構。架構是組件和鏈接器。

2、架構模式是對元素和關係類型以及一組對其使用方式的限制的描寫敘述。

3、參考模型是一種考慮數據流的功能劃分。

4、參考架構是映射到軟件元素（它們相互協做，共同實現在參考模型中定義的功能）及元素之間數據流上的參考模型。

5、軟件架構、架構模式、參考模型、參考架構之間的關係：

軟件結構	關係	適用環境
分解	是一個子模塊；與之共享祕密	資源分配、項目結構化和規劃；信息隱藏、封裝；配置控制
使用	要求正確出現	設計子集；設計擴展
分層	要求正確的出現、使用服務、提供抽象	增量式開發；在「虛擬機」可移植性之上實現系統
類	是一個實例；共享訪問方法	在面向對象的設計系統中，從一個公共的模版中產生高速的、相近的實現
客戶機-server	與之通訊；依賴於	分佈式操做；關注點分離；性能分析；負載平衡
進程	與之併發執行、可能會與之併發執行；排除；優先於等	調度分析；性能分析
併發	在一樣的邏輯線程上執行	肯定存在資源爭用，線程可以交叉、鏈接、被建立或被殺死的位置
共享數據	產生數據；使用數據	性能；數據完整性；可改動性
部署	分配給；移植到	性能、可用性、安全性分析
實現	存儲在	配置控制、集成、測試活動
工做分配	分配到	項目管理、最佳利用專業技術、管理通用性

注：在＜Pattern-Oriented Software Architecture (面向模式的軟件體系架構) ＞中首次提出了8種體系結構模式：層（Layers）、管道和過濾器(Pipes and Filters) 、黑板(Black board )、代理者（Broker）、模型-視圖-控制器（Model-View-Controller）、表示-抽象-控制（Presentation-Abstraction-Control）、微核（Microkernel）、映像（Reflection）。

6、架構定義中指出系統由多種結構構成的，如下列出一些常見的結構。

7、質量屬性

系統從設計、實現到部署的整個過程當中考慮質量屬性的實現。質量屬性包含下列三類：

（1）、系統的質量屬性。（可用性、可改動性、性能、安全性、可測試性和易用性）

（2）、受架構影響的商業屬性。（上市時間、成本和收益、所但願的系統生命期的長短、目標市場、推出計劃、與老系統的集成）

（3）、與架構自己相關的一些質量屬性。（概念完整性、正確性與完整性、可構建性）

六個質量屬性的戰術列表：

3、設計架構

差點兒在咱們遇到的所有成功的面向對象系統中都具備但失敗的系統中缺乏的兩個特性是：存在一個強大的構架構想，應用管理良好的迭代式增量開發週期。功能、質量和商業需求的某個集合「塑造」了構架。咱們把這些塑造需求稱爲「構架驅動因素」。

構架設計必須按需求分析進行，但不需要在需求分析完畢後在開始構架設計。實際上，在肯定了關鍵的構架驅動因素後，就可以開始構架設計了。當設計了構架的足夠多的部分後，就可以開始開發骨架系統了。該骨架系統在上面進行迭代開發（以及其在不論什麼一個點交付的能力）的框架。組織結構對構架產生影響。

屬性驅動的設計(ADD)是一個用於設計構架以知足質量需求和功能需求的方法。ADD把一組質量屬性場景做爲輸入，並使用對質量屬性實現和構架之間的關係的瞭解，對構架進行設計。

ADD步驟：

（1）選擇要分解的模塊。

（2）依據這些步驟對模塊進行求精。

對需要進一步分解的每個模塊反覆上述步驟。

在設計架構過程當中可以重用架構，重用一些技術以方便來實現架構與設計。高層重用技術分類

高層重用

設計模式

框架

軟件架構

架構風格

架構設計風格

架構框架

架構平臺

設計模式：使用相互通訊的類和對象可爲常見的設計問題提供通用的解決方式。爲了幫助用戶掌握模式的概念並有效地設計模式，我一般爲設計模式的描寫敘述提供一個帶有比喻性的抽象。常見的設計模式有：Fvacade（外觀模式），它爲子系統中的一系列動做提供一個統一接口；Ovbserver（觀察者模式），詳細的設計模式內容參考GOF23設計模式。

框架：提供一組相互協做的類及執行時對象，用於生成某些特定領域的應用軟件。咱們可以依據特定應用的需求方便地對框架中的抽象和類進行定製，以重用框架的設計和代碼。

軟件架構：編制軟件也稱爲架構軟件。一個可操做的軟件內部應具備某種形式的架構。軟件架構技術中可重用的實體可以進一步地分爲4類：架構風格、架構設計風格、架構框架、架構平臺。

架構風格給出了精心設計的軟件全局的通用形態。好比，Shaw和Garlan提出了7種架構風格：管道和過濾器、面向對象的組織、隱式調用、分層系統、倉庫、狀態機、解釋器，及過程控制。

架構設計風格給出了軟件架構的設計方法論。Shaw將衆多的設計風格分類爲例如如下8種：功能分解、數據流、面向對象、狀態機、面向事情、過程控制、數據結構及決定表。

架構框架是來爲具體而完整的框架，它爲開發特定領域的應用系統使用了一系列多種架構設計風格。一個採用了某些設計風格的軟件架構製品，僅僅有當它具備完備的文檔，並具有包括一個特定的應用領域所需要的充分靈活性時才幹夠做爲軟件框架來重用。

架構平臺提供了一個可以適應多種應用系統的靈活的底層結構，架構平臺的設計目的便是爲了應用軟件的互操做性提供硬件平臺及操做系統平臺無關環境。咱們可以將它們用作底層結構，以促進對象級的協做和重用。對象管理組織(OMG)的通用對象請求代理體系結構（Common Object Request Broker Architecture，CORBA）便是一個演示樣例。

4、架構評估方法

軟件構架的評估方法：SAAM和ATAM。這裏僅僅具體說明ATAM方法。

ATAM一種進行構架評估的綜合方法，ATAM是評估軟件構架的一個健壯的方法。在該方法中，項目決策者和涉衆要清晰地闡述一個準確的質量屬性需求列表（以場景的方式），並說明與實現每個高優先場景相關的構架決策。而後，把這些決策肯定爲有風險決策或無風險決策，以找到構架中不論什麼存在問題的地方。

ATAM不是需求評估。

ATAM不是代碼評估。

ATAM不包含實際的系統測試。

ATAM不是一個準確的手段，但它識別了構架中可能存在風險的區域。這些風險包括在敏感點和權衡中。

ATAM活動的4個階段：

在第0階段（合做關係和準備）肯定細節：人員名單，時間，地點；評估小組獲取資料並進行初步瞭解分析。

第1階段，評估階段，決策者參與，小組開始信息收集與分析；耗時約1周。1～2週中斷期，評估小組進一步以非正式方式瞭解構架。

第2階段，評估階段，涉衆參與，分析繼續；約2天。

第3階段，興許階段，生成終於報告，進行評估活動總結；1周。

評估階段的步驟：

第1步：ATAM方法的表述。評估負責人向決策者表述ATAM方法，使你們理解其過程，瞭解角色佈局。

第2步：商業動機的表述。決策者介紹系統商業動機、重要功能、各類限制（不論什麼相關的技術、管理、經濟和政治限制）、商業目標和上下文、基本的涉衆、驅動因素等。

第3步：構架的表述。首席設計師或架構小組介紹構架，技術限制、所用模式等。

第4步：對構架方法進行分類。評估小組利用所有已知信息對構架方法進行分類。

第5步：生成質量屬性效用樹。生成質量屬性效用樹，捕獲具體的需求信息，爲每個場景分配一個級別，如（高，中），前者爲重要度，後者爲實現難易度，重點放在（高，高）的場景；此處場景具有刺激、環境、響應三要素就可以了。

第6步：分析構架方法。評估小組分析所有重要場景，設計師解釋怎樣支持該場景，檢查所用構架方法，分析風險點、權衡點、敏感點。

通過一段中斷期，第2階段開始，此時涉衆開始參與；首先仍然需要一個對ATAM方法的介紹，並使涉衆瞭解已有的成果。

第7步：集體討論並肯定場景的優先級。集體討論並分析場景的優先級，以瞭解更普遍的涉衆的想法；該過程可能產生新的場景；使用「有限票數法」投票肯定每個場景的優先級——此處不考慮實現難度。

第8步：分析構架方法。分析新的高優先級的場景，構架師解釋構架是怎麼知足各場景的。

第9步：結果表述。總結評估結果，評估負責人展現該結果。

5、軟件架構風險管理

1、怎樣識別軟件架構的風險

（1）需求的不斷變化

（2）架構師對於技術理解不足

（3）缺少對行業的研究

（4）經驗不足

（5）創造性的架構比重比較重

（6）沒有造成一套構架的規範

（7）架構可運行性差

2、怎樣規避軟件架構風險

固化需求

無缺的業務原型

完整架構規範

驗證架構的可運行性

80%的經驗架構+20%的創新架構

6、有用軟件體系結構

本部分是提供有用的指南和技術，以更快地獲得好的系統結構設計。咱們的哲學是不該該致力於設計理想化的系統結構，而是應該細緻地評估和權衡所有技術、市場、人員、成本方面的問題，從而獲取一個好的解決方式。

4種視圖+全局分析

1、4種視圖

1）、一個軟件體系結構有4種大相徑庭的視圖：概念視圖、模塊視圖、運行視圖、代碼視圖。

使用這個4種視圖提供了一種設計軟件系統結構的系統化方法，幫助架構師設置優先級，分析權衡，並保證沒有缺漏。

2）、不一樣視圖強調的不一樣project關注點：

在概念視圖中，問題和解決方式主要經過領域術語來考慮的。對於特定的軟件及硬件技術，它們應當是相對獨立的。概念視圖的工廠關注點包含：

系統怎樣知足需求？

商用構件如何組裝成整體，如何在功能層上與系統的其它部分交互？

領域特定的硬件和軟件怎樣融入系統？

功能是怎樣被切割並進入產品個版本號的？

系統怎樣與以前版本號的產品合併？它怎樣支持將來的版本號？

怎樣支持產品線？

怎樣將由需求或領域中所作的變更引發的影響最小化？

在模塊視圖中，概念視圖中的構件和鏈接子被映射爲子系統和模塊。在這裏，架構師強調的是怎樣用現有的軟件平臺以及技術實現概念的解決方式。基本的project關注點有例如如下幾點：

產品是怎樣映射到軟件平臺的？

使用了什麼樣的系統支持或系統服務？詳細是在什麼地方？

怎麼支持測試？

怎樣減小模塊間的依賴性？

怎樣將模塊與子系統的複用最大化？

當商用軟件、軟件平臺或標準發生變更時，採用何種技術在封裝產品時可以將它們與產品進行隔離？

運行視圖描寫敘述模塊怎樣映射到運行時平臺說提供的元素，以及這些又怎樣映射到硬件體系結構。運行視圖定義系統的運行時實體及其屬性，比方內存使用和硬件分配。對於運行視圖，其project關注點例如如下：

系統怎樣知足性能、恢復及又一次配置方面的需求？

怎樣平衡資源的使用（好比：負載平衡）？

怎樣達到必需的併發、複製及分佈，而只是度添加控制算法的複雜度？

怎樣使執行時平臺的改變所引發的影響到達最小？

在代碼體系結構視圖中，架構師決定運行視圖中的運行時實體怎樣映射到部署構件（好比：可運行構件），決定模塊視圖中的模塊怎樣映射到源構件，以及部署構件怎樣從源構件生成。代碼視圖中重要的project關注點例如如下：

怎樣減小產品升級的時間和費用？

怎樣管理產品版本號及公佈？

怎樣減小構造時間？

需要什麼工具支持開發環境？

怎樣支持集成與測試？

2、全局分析

全局分析是在定義概念、模塊、運行和代碼系統結構視圖以前進行的，並貫穿整個系統結構的設計過程。

全局分析從識別影響體系結構設計的因素來分紅3類：組織因素、技術因素、產品因素。

組織因素分紅5類：管理；員工技能、興趣、能力、缺點；過程與開發執行環境；開發進度；開發預算。

技術因素包含：通用和專用的硬件；操做系統、用戶界面、設計模式等軟件技術；模版和框架等體系結構技術；圖像、數據庫、數據格式、算法和技術之類的標準。

產品因素是描寫敘述了產品的功能需求、用戶可見的特徵和產品的性能等質量方面的需求。比方：功能特徵；用戶界面；性能；依賴性；錯誤監測、報告、修復；服務和價格等。

全局分析是在每一種體系結構設計視圖中都要進行的一種行爲。在全局分析過程當中創建的問題卡片要用在每一個視圖設計的核心設計任務中。在進行核心設計任務時，作出的決策應當可以返回到全局分析，以添加和改動因素、問題和策略。

總結策略：

問題	應用策略
進度緊迫	複用內部已有的、領域特性構件購買而不是創建使元素easy加入和刪除
技能不足	避免使用多線程封裝多進程
通用和領域特定硬件的改變	封裝領域特定硬件封裝通用硬件
軟件技術的改變	使用標準爲外部構件開發產品特定的接口
資源有限	限制活動線程個數用動態的內部線程見通訊聯繫
易用添加和刪除特性	按關聯尺度分離構件和模塊特性封裝到分開的構件分離用戶交互模塊
易用添加和刪除採集過程和算法	爲圖像處理使用靈活的流水線模塊爲採集和圖像處理引入構件分離用戶交互模塊
高吞吐量	把獨立的控制線程映射到進程使用新增的CPU
實時採集性能	從沒有臨界時間構件中分離出有臨界時間的爲模塊行爲開發準則靈活的分配模塊到進程使用單速分析來預言性能使用共享存儲進行流水線階段之間通訊
實現恢復	引入操做的恢復模塊把全部數據放到恢復穩定和easy達到的地方
實現診斷	制定一個錯誤處理策略下降錯誤處理的工做封裝診斷構件使用標準日誌服務
體系結構的完整性	保護模塊間的繼承分離公共接口構件
併發的開發工做	從源構件中分離開發構件保護運行視圖採用階段開發經過靜態庫來公佈層
限制可以使用的採集圖像類型	採用適當的抽象開發一個脫機的探測模擬器使用一個靈活的創建過程
多樣性開發和目標平臺	分離和封裝依賴目標平臺的代碼

7、特定領域框架

1、框架：一組類或組件的集合，它們爲一個特定領域提供了一組服務和功能。軟件架構的一種實例，它可以使設計的組件具備良好的互操做性。

2、框架分類

依據做用域可以將框架分爲系統基礎結構框架、中間件集成框架、企業應用框架。

系統基礎結構框架是一組可以支持系統基礎結構領域的高校可移植框架，好比可以支持操做系統、用戶界面、通訊及語言處理等，它們通常是由內部開發和使用的，有時也用做供其它應用使用的通用應用。

中間件集成框架的做用是加強軟件對基礎結構的模塊化處理能力、重用能力及擴展能力，從而能夠在分佈式環境中無縫執行。中間件集成的樣例有OmniBuilder框架和對象請求代理(ORB)。

企業應用框架處理的應用領域很是廣，如銀行、電信、製藥等，它們是領域應用的基石。企業應用中著名的實例有IBM SanFrancisco、企業資源規劃（ERP）。

框架類別	框架實例
企業應用框架	Amulet，IBM SanFrancisco，Asyn，LAMA，CORTAN，OMAC框架
中間件集成框架	GUI,QC Services Layer，PFC/Open，OmniBuilder，PFX,FrameData Feed Handler框架
系統基礎結構框架	Protocol Layer，ACE,OPTF,DynaFind，ARES,DORB框架

3、框架比較

應用框架調查的比較參數包含操做系統、程序設計語言、領域範疇等。

1）、操做系統：Windows、UNIX、Linux

2）、語言：C++、Java

3）、領域範疇

擁有框架最多的兩個領域是商務/金融和電信/網絡。

框架領域範疇

編號	領域範疇	框架列表
1	通用（無領域）	MaccApp，G++
2	通用GUI	GUI,Amulet，Visible Properties and Actions Framework
3	數據庫和數據管理	FRAMEWARE,PFX（持久性框架），ROA’D，QC Services Layer框架，Advanced Software Architecture Platform
4	商務和金融	Asyn，SanFrancisco,BOOF,PFC/Open Frame，Omni Builder，Rule Parsing，File Parsing，CSFramelets
5	保險	Asyn，SanFrancisco
6	醫療	HBOC應用框架，Medical Business Object框架，Advanced Software Architecture Platform,Philips New York Project（開發中）
7	教育和娛樂	Multimedia框架
8	電信和網絡	適應性面向對象事件過濾框架，Advanced Software Architecture Platform，CORTAN,Protocol Layer框架，ACE,SIGAL,DORB,Jadve
9	工業和製造業	OMAC,PrismTech BOF和CORBA服務
10	軟件開發	CLOS Meta Object Protocol，G++,OPTF,LAMA

8、企業應用架構模式

作企業應用開發需要了解一些企業應用開發基礎知識，比方分層架構、WEB表現、業務邏輯、數據庫映射、併發、會話、分佈策略等等。經過使用場景、解決方式、UML等手段具體介紹了設計模式（包含一些常用的設計模式GOF23）。如下這些模式是幹什麼的、它們解決什麼問題、它們是怎樣解決這個問題的。這樣，假設你碰到類似的問題，就可以從中找到對應的模式。可以爲你節約成本、縮短項目週期時間、避免風險，以確保項目可以完美的完畢。

1、三個基本層次：表現層、領域層、數據源層

層次	職責
表現層	提供服務，顯示信息（好比在Windows或HTML頁面中，處理用戶請求（鼠標點擊、鍵盤敲擊等），HTTP請求，命令行調用，批處理API）
領域層	邏輯，系統中真正的核心
數據源層	與數據庫，消息系統、事務管理器及其它軟件包通訊

關於依賴性的廣泛性原則：領域層和數據源層絕對不要依賴於表現層。

一旦選擇了處理節點，接下來就應該儘量使所有代碼保持在單一進程內完畢（多是在同一個節點上，也可能拷貝在集羣中的多個節點上）。除非不得已，不然不要把層次放在多個進程中完畢。因爲那樣作不但損失性能，而且添加複雜性，因爲必須添加類似如下的模式，如遠程外觀和傳輸數據對象。

複雜性增壓器：分佈、顯式多線程、範型差別、多平臺開發以及極限性能要求（如每秒100個事務以上）。

2、領域邏輯

領域邏輯的組織可以分紅三種主要模式：事務腳本、領域模型、表模塊。

三者之間的差異：

事務腳本是一個過程來控制一系列動做邏輯的運行。

領域模型再也不是由一個過程來控制用戶某動做的邏輯，而是由每一個對象都承擔一部分相關邏輯。這些對象可以當作是領域的不一樣組成部分。

表模塊僅僅有一個公共的合同類實例，而領域模型對數據庫中每一個合同都有一個對應的合同類的實例。

3、映射到關係數據庫

在使用領域模型的時候，它的讀取應該把相關聯的對象也一塊讀出來。好比，讀取一個合同，應該把合同涉及到的產品和定購廠商的對象載入到內存中。由時候爲了不這些沒有必要的連帶讀取，咱們可以使用【延遲載入】模型。

讀取數據的時候，性能問題可能回變得比較突出。這就致使了幾條經驗法則。

1）、儘量一次查詢多個記錄，不要一次查詢一個記錄，而後進行屢次查詢。可以一次查詢多條相關的記錄，好比使用聯合查詢。或者使用多條SQL語句。

2）避免屢次進入數據庫的方法是使用鏈接（Join），這樣就可以經過一次返回多個表。可以製做一個入口，讓入口完畢相關數據的一次性讀取。

3）數據庫中進行優化。DBA來優化數據庫。

映射到關係數據庫的時候，一般會遇到三種狀況：

1）本身選擇數據庫方案。

2）不得不映射到一個現有數據庫方案，這個方法不能改變。

3）不得不映射到一個現有數據庫方案，但這個方法是可以考慮改變的。

最簡單的狀況是本身選擇數據庫方案，並且不用遷就領域邏輯的複雜性。當已經存在一個數據庫方案的時候，應該逐步創建領域模型幷包含數據映射器，把數據保存到現有的數據庫中。

4、併發

併發問題：更新丟失和不一致讀。

併發問題，人們提出了各類不一樣的解決方式。對於企業應用來講，有兩個很重要的解決方式：一個是隔離，一個是不變性。

隔離是劃分數據，使得每一片數據均可能被一個運行單元訪問。比方文件鎖。

不變性是識別那些不變的數據，不用總考慮這些數據的併發問題而是普遍地共享它們。

當有一些可變數據沒法隔離的時候，會發生什麼樣的狀況呢？總的來講，咱們可以使用兩種形式的併發控制策略：樂觀併發控制和悲觀併發控制。

假設把樂觀鎖看做是關於衝突檢測的，那麼悲觀鎖就是關於衝突避免的。

假如Martin和David同一時候都要編輯Customer文件。假設使用樂觀鎖策略，他們兩我的都能獲得一份文件的拷貝，並且可以自由編輯文件。假設David第一個完畢了工做，那麼他可以毫無困難地更新他的改動。但是，當Martin想要提交他的改動時，併發控制策略就會開始起做用。源碼控制系統會檢測到在Martin的改動和David的改動之間存在着衝突，於是拒絕Martin的提交，並由Martin負責指出如何處理這樣的狀況。假設使用悲觀鎖策略，僅僅要有人先取出文件，其它人就不能對該文件進行編輯。所以，假如是Martin先取出了文件，那麼David就僅僅能在Martin完畢任務並提交以後才幹對該文件進行操做。

多種技術處理死鎖：一種是使用軟件來檢測死鎖的發生。還有一種是給每一個鎖都加上時間限制，一旦到達時間限制，所加的所就會失效，工做就會丟失。

軟件事務經常使用ACID的屬性來描寫敘述。

原子性（Atomicity）：在一個事務裏，動做序列的每一個步驟都必須是要麼全部成功，要麼全部的工做都將回滾。部分完畢不是一個事務概念。

一致性（Consistency）：在事務開始和完畢的時候，系統的資源都必須處於一致的、沒有被破壞的狀態。

隔離性（Isolation）：一個事務，直到它被成功提交以後，它的結果纔對其它所有的事務是可見的。

持久性（Durability）：一個已提交事務的不論什麼結果都必須是永久性的，即「在不論什麼崩潰的狀況的能保存下來」。

大多數企業應用是在數據庫方面涉及到事務的，但還有很是多狀況要進行事務控制，比方說哦消息隊列、打印機和ATM等。爲了處理最大的吞吐率，現代的事務處理系統被設計成保證事務儘量短，儘量不讓事務跨越多個請求；儘量晚打開事務。

5、分佈策略

按類模型進行分佈的方法不可行的主要緣由與計算機的基本特色有關。進程內的過程調用很快。兩個對立進程間的過程調用就慢了一個數量級。在不一樣機器間執行過程又要慢一兩個數量級，取決於網絡拓撲。

本地接口最好是細粒度接口。但細粒度不能很是好地用在遠程調用中。分佈對象設計第必定律：不要分佈使用對象，大多數狀況下是使用集羣系統。

6、應用集成的四種主要方式：文件傳輸、共享數據庫、遠程過程調用、消息傳遞。利用文件傳輸和共享數據庫，應用能夠共享它們的數據，但不能共享功能。遠程過程調用使應用能夠共享功能，但是這會讓應用緊耦合。消息傳遞使應用能夠共享功能，讓應用鬆耦合。執行消息傳遞，可使用可定製的格式頻繁地、立刻地、可靠地、異步地數據傳輸包。本書主要是環繞消息傳遞方式來集成應用，完畢企業集成模式、設計、構建及部署。書中也介紹了消息是如何傳遞的，咱們不需要全然理解，那個對我來講太難了。咱們需要熟悉WebSphere MQ、MSMQ、JMS等消息服務產品，而後利用它們能開發企業集成系統，特別是金融業、保險業企業集成系統。

應用之間的集成解決方式必須應對下面幾個基本挑戰：

■網絡是不可靠的。

■網絡速度慢。

■不論什麼兩個應用都是不一樣的。集成解決方式需要在使用不一樣編程語言、不一樣操做平臺和不一樣數據格式的系統之間傳送信息。

■改變是不免的。應用會隨着時間改變。

開發者使用下面四種主要方法克服上述挑戰：

一、）文件傳輸——一個應用寫文件，以後還有一個應用讀這個文件。爲此，應用之間需要協商文件名稱、文件的位置、文件格式、文件讀寫的時間以及誰負責刪除這個文件。

二、）共享數據庫——多個應用共享一樣的數據庫，這個數據庫位於獨立的物理數據庫中。由於不存在反覆保存的數據資料，所以沒必要將數據從一個應用傳給還有一個應用。

三、）遠程過程調用——一個應用開放其部分功能，使得其它應用能夠遠程訪問這些過程。它們之間的通訊是實時、同步的。

四、）消息傳遞—— 一個應用向公共消息通道中公佈一個消息，其它應用可以在以後某個時間從通道中得到這個消息。應用之間必須協商創建通道以及消息的格式。這樣的通訊是異步的。

每種方法均有其獨特的長處和不足。實際上，應用之間可經過多種方法集成，使得每個集成點都能充分利用最合適的方法。

消息傳遞開發商的產品大體劃分爲下面四類：

一、）操做系統。消息傳遞已經成爲開發商把必要的軟件基礎設施集成到操做系統或數據庫平臺中的共同需要。好比，Windows 2000和Windows XP操做系統包括了Microsoft消息排隊（MSMQ）服務軟件，經過COM組件和System.Messaging名字空間訪問，屬於.NET平臺的組成部分。Oracle提供了Oracle AQ.

二、）應用server。好比JMS、IBM WebSphere、BEA WebLogic

三、）EAI套件。好比IBM WebSphere MQ、Microsoft BizTalk、TIBCO、WebMethods、SeeBeyond、Vitria、CorssWolds。

四、）Web服務工具集。好比WS-Reliability、WS-ReiableMessaging、ebMs

9、UML、XML、.net/java平臺

企業應用系統眼下業界流行和通用的就是.Net平臺和Java平臺（J2EE）；關於二者的差異參考：http://www.cnblogs.com/heilix/archive/2009/01/17/1377555.html

10、幾種常見架構

軟件架構通用的服務模式

類工廠服務

緩存服務（內存服務）

配置服務

異常處理服務

日誌服務

加密服務

驗證服務和受權服務

消息隊列

部署服務

事務處理服務

幫助服務

數據驗證服務

1、 MVC

•M表示模型

•V表示視圖

•C表示控制器

2、C/S

•client向server發送數據請求

•server返回數據

•client處理數據的展現

•server需要處理通信、併發等等

server

•一個線程用來監聽來自client的鏈接

•用一個獨立的線程來處理一個client的鏈接

•線程池、線程重用

•併發控制

•負載均衡

進程間通信

•TCP/UDP進程間通信

•命名管道

•共享內存

•命名事件

•命令行參數傳遞（用於父子進程）

3、B/S

•Webserver

•應用server

•數據庫server

Webserver

•標準的Webserver

•簡化了應用server的開發

Webserver架構

•JAVA (JSP)

•.NET (ASP)

•LAMP

Linux+Apache+Mysql+Perl/PHP/Python,一組常用來搭建動態站點或者server的開源軟件,自己都是各自獨立的程序,但是因爲常被放在一塊兒使用,擁有了愈來愈高的兼容度,共同組成了一個強大的Web應用程序平臺。

HTTP

•基於TCP

•client發送HTTP Request

•server處理後，發送HTTP Response

•每次鏈接僅僅處理一個請求

•HTTP協議定義了Request和Response的內容格式（基於文本）

•HTTP是應用協議

•定義了GET、PUT、POST、REMOVE等操做

•操做的對象是資源，由URI定義

•無狀態

HTTP做爲傳輸協議來使用

•基於HTTP的Request和Response

•應用協議在Request和Response中定義

形式一

•http://...../update.php?version=1.0

•http://..../functioncall.php?method=xxx&arg=aaa&....

•可以使用GET和POST

•在Response中使用xml做爲返回

形式二

•使用POST

•在Request中使用XML指定方法名和參數

•在Response中使用XML做爲返回

•XML-RPC

形式三

SOAP, WebService

4、SOA

SOA 是一種 IT 體系結構樣式，支持將您的業務做爲連接服務或可反覆業務任務進行集成，可在需要時經過網絡訪問這些服務和任務。這個網絡可能全然包括在您的公司總部內，也可能分散於各地且採用不一樣的技術，經過對來自紐約、倫敦和香港的服務進行組合，可以讓終於用戶感受彷佛這些服務就安裝在本地桌面上同樣。需要時，這些服務能夠將本身組裝爲按需應用程序——即相互鏈接的服務提供者和使用者集合，彼此結合以完畢特定業務任務，使您的業務能夠適應不斷變化的狀況和需求.

5、SaaS

軟件即服務,它是一種基於互聯網提供軟件服務的應用模式。隨着互聯網技術的發展和應用軟件的成熟，SaaS做爲一種創新的軟件應用模式逐漸興起。

SaaS提供商爲企業搭建信息化所需要的所有網絡基礎設施及軟件、硬件運做平臺，並負責所有前期的實施、後期的維護等一系列服務，企業無需購買軟硬件、建設機房、招聘IT人員，就能夠經過互聯網使用信息系統。就像打開自來水龍頭就能用水同樣，企業依據實際需要，向SaaS提供商租賃軟件服務。

對於廣大中小型企業來講，SaaS是採用先進技術實施信息化的最好途徑。但SaaS毫不只適用於中小型企業，所有規模的企業都可以從SaaS中獲利。

眼下，SaaS已成爲軟件產業的一個重要力量。僅僅要SaaS的品質和可信度能繼續獲得證明，它的魅力就不會消退。

6、Open API

Open API實現技術

•SOAP

•XML-RPC

•REST

7、開源框架

Struts+Spring+Hibernate