[置頂] 軟件架構學習小結

時間 2019-11-11

原文原文鏈接

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

1、軟件架構師的職責html

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

一、架構師的職責主要體現程序員

架構師的職責就是設計一個公司系統的基礎架構，並提供關於怎樣創建和維護系統的指導方針。具體來說，架構師的職責主要體如今如下幾方面：算法

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

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

3）、協助項目經理制定項目計劃和控制項目進度。數據庫

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

5）、負責組織技術研究和攻關工做。設計模式

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

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

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

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

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

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

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

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

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

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

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

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

一、對於軟件架構定義有不少種，通用的定義是：某個軟件或計算機系統的軟件架構是該系統的一個或多個結構，他們由軟件元素，這些元素的外部可見屬性以及這些元素之間的關係組成。
這裏所說的某個元素的「外部可見屬性」是指其餘元素對該元素所作的假設，如它所提供的服務、性能特徵、錯誤處理、共享資源的使用，等等。

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

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

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

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

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

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

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

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

七、質量屬性

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

（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）需求的不斷變化

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

（3）缺少對行業的研究

（4）經驗不足

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

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

（7）架構可執行性差

二、如何規避軟件架構風險

固化需求

完善的業務原型

完整架構規範

驗證架構的可執行性

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

6、實用軟件體系結構

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

4種視圖+全局分析

一、4種視圖

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

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

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

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

系統如何知足需求？

商用構件怎樣組裝成總體，怎樣在功能層上與系統的其餘部分交互？

領域特定的硬件和軟件如何融入系統？

功能是如何被分割並進入產品個版本的？

系統如何與以前版本的產品合併？它如何支持將來的版本？

如何支持產品線？

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

在模塊視圖中，概念視圖中的構件和鏈接子被映射爲子系統和模塊。在這裏，架構師強調的是如何用現有的軟件平臺以及技術實現概念的解決方案。主要的工程關注點有以下幾點：

產品是如何映射到軟件平臺的？

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

怎麼支持測試？

如何下降模塊間的依賴性？

如何將模塊與子系統的複用最大化？

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

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

系統如何知足性能、恢復及從新配置方面的需求？

如何平衡資源的使用（例如：負載平衡）？

如何達到必需的併發、複製及分佈，而不過分增長控制算法的複雜度？

如何使運行時平臺的改變所引發的影響到達最小？

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

如何下降產品升級的時間和費用？

如何管理產品版本及發佈？

如何下降構造時間？

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

如何支持集成與測試？

二、全局分析

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

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

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

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

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

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

總結策略：

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

7、特定領域框架

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

二、框架分類

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

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

中間件集成框架的做用是加強軟件對基礎結構的模塊化處理能力、重用能力及擴展能力，從而可以在分佈式環境中無縫運行。中間件集成的例子有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框架

三、框架比較

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

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

2）、語言：C++、Java

3）、領域範疇

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

框架領域範疇

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

8、企業應用架構模式

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

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

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

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

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

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

二、領域邏輯

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

三者之間的區別：

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

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

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

三、映射到關係數據庫

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

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

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

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

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

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

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

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

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

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

四、併發

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

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

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

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

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

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

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

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

軟件事務常用ACID的屬性來描述。

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

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

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

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

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

五、分佈策略

按類模型進行分佈的方法不可行的主要緣由與計算機的基本特色有關。進程內的過程調用很是快。兩個對立進程間的過程調用就慢了一個數量級。在不一樣機器間運行過程又要慢一兩個數量級，取決於網絡拓撲。
本地接口最好是細粒度接口。但細粒度不能很好地用在遠程調用中。分佈對象設計第必定律：不要分佈使用對象，大多數狀況下是使用集羣系統。

六、應用集成的四種主要方式：

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

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

1.網絡是不可靠的。

2.網絡速度慢。

3.任何兩個應用都是不一樣的。集成解決方案須要在使用不一樣編程語言、不一樣操做平臺和不一樣數據格式的系統之間傳送信息。

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

開發人員使用如下四種主要方法克服上述挑戰：

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

二、）共享數據庫——多個應用共享相同的數據庫，這個數據庫位於獨立的物理數據庫中。因爲不存在重複保存的數據資料，所以沒必要將數據從一個應用傳給另外一個應用。

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

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

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

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

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

二、）應用服務器。例如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、幾種常見架構

-軟件架構通用的服務模式

-類工廠服務

-緩存服務（內存服務）

-配置服務

-異常處理服務

-日誌服務

-加密服務

-驗證服務和受權服務

-消息隊列

-部署服務

-事務處理服務

-幫助服務

-數據驗證服務

一、 MVC

M表示模型

V表示視圖

C表示控制器

二、C/S

客戶端向服務器發送數據請求

服務器返回數據

客戶端處理數據的展現

服務器須要處理通信、併發等等

服務器

一個線程用來監聽來自客戶端的鏈接

用一個獨立的線程來處理一個客戶端的鏈接

線程池、線程重用

併發控制

負載均衡

進程間通信

TCP/UDP進程間通信

命名管道

共享內存

命名事件

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

三、B/S

Web服務器

應用服務器

數據庫服務器

Web服務器

標準的Web服務器

簡化了應用服務器的開發

Web服務器架構

JAVA (JSP)

.NET (ASP)

LAMP

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

HTTP

基於TCP

客戶端發送HTTP Request

服務器處理後，發送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

四、SOA

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

五、SaaS

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

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

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

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

六、Open API

Open API實現技術

SOAP

XML-RPC

REST

七、開源框架

Struts+Spring+Hibernate