1、實用軟件體系結構php
本部分是提供實用的指南和技術,以更快地獲得好的系統結構設計。咱們的哲學是不該該致力於設計理想化的系統結構,而是應該仔細地評估和權衡全部技術、市場、人員、成本方面的問題,從而獲取一個好的解決方案。html
4種視圖+全局分析java
一、4種視圖算法
1)、一個軟件體系結構有4種大相徑庭的視圖:概念視圖、模塊視圖、執行視圖、代碼視圖。sql
使用這個4種視圖提供了一種設計軟件系統結構的系統化方法,幫助架構師設置優先級,分析權衡,並保證沒有缺漏。數據庫
2)、不一樣視圖強調的不一樣工程關注點:編程
在概念視圖中,問題和解決方案主要經過領域術語來考慮的。對於特定的軟件及硬件技術,它們應當是相對獨立的。概念視圖的工廠關注點包括:設計模式
系統如何知足需求?緩存
商用構件怎樣組裝成總體,怎樣在功能層上與系統的其餘部分交互?服務器
領域特定的硬件和軟件如何融入系統?
功能是如何被分割並進入產品個版本的?
系統如何與以前版本的產品合併?它如何支持將來的版本?
如何支持產品線?
如何將由需求或領域中所作的變更引發的影響最小化?
在模塊視圖中,概念視圖中的構件和鏈接子被映射爲子系統和模塊。在這裏,架構師強調的是如何用現有的軟件平臺以及技術實現概念的解決方案。主要的工程關注點有以下幾點:
產品是如何映射到軟件平臺的?
使用了什麼樣的系統支持或系統服務?具體是在什麼地方?
怎麼支持測試?
如何下降模塊間的依賴性?
如何將模塊與子系統的複用最大化?
當商用軟件、軟件平臺或標準發生變更時,採用何種技術在封裝產品時能夠將它們與產品進行隔離?
執行視圖描述模塊如何映射到運行時平臺說提供的元素,以及這些又如何映射到硬件體系結構。執行視圖定義系統的執行時實體及其屬性,好比內存使用和硬件分配。對於執行視圖,其工程關注點以下:
系統如何知足性能、恢復及從新配置方面的需求?
如何平衡資源的使用(例如:負載平衡)?
如何達到必需的併發、複製及分佈,而不過分增長控制算法的複雜度?
如何使運行時平臺的改變所引發的影響到達最小?
在代碼體系結構視圖中,架構師決定執行視圖中的執行時實體如何映射到部署構件(例如:可執行構件),決定模塊視圖中的模塊如何映射到源構件,以及部署構件如何從源構件生成。代碼視圖中重要的工程關注點以下:
如何下降產品升級的時間和費用?
如何管理產品版本及發佈?
如何下降構造時間?
須要什麼工具支持開發環境?
如何支持集成與測試?
二、全局分析
全局分析是在定義概念、模塊、執行和代碼系統結構視圖以前進行的,並貫穿整個系統結構的設計過程。
全局分析從識別影響體系結構設計的因素來分紅3類:組織因素、技術因素、產品因素。
組織因素分紅5類:管理;員工技能、興趣、能力、缺點;過程與開發運行環境;開發進度;開發預算。
技術因素包括:通用和專用的硬件;操做系統、用戶界面、設計模式等軟件技術;模版和框架等體系結構技術;圖像、數據庫、數據格式、算法和技術之類的標準。
產品因素是描述了產品的功能需求、用戶可見的特徵和產品的性能等質量方面的需求。好比:功能特徵;用戶界面;性能;依賴性;錯誤監測、報告、修復;服務和價格等。
全局分析是在每一種體系結構設計視圖中都要進行的一種行爲。在全局分析過程當中創建的問題卡片要用在每個視圖設計的核心設計任務中。在進行核心設計任務時,作出的決策應當能夠返回到全局分析,以增長和修改因素、問題和策略。
總結策略:
問題 | 應用策略 |
進度緊迫 | 複用內部已有的、領域特性構件 購買而不是創建 使元素容易添加和刪除 |
技能不足 | 避免使用多線程 封裝多進程 |
通用和領域特定硬件的改變 | 封裝領域特定硬件 封裝通用硬件 |
軟件技術的改變c | 使用標準 爲外部構件開發產品特定的接口 |
資源有限 | 限制活動線程個數 用動態的內部線程見通訊聯繫 |
易用增長和刪除特性 | 按關聯尺度分離構件和模塊 特性封裝到分開的構件 分離用戶交互模塊 |
易用增長和刪除採集過程和算法 | 爲圖像處理使用靈活的流水線模塊 爲採集和圖像處理引入構件 分離用戶交互模塊 |
高吞吐量 | 把獨立的控制線程映射到進程 使用新增的CPU |
實時採集性能 | 從沒有臨界時間構件中分離出有臨界時間的 爲模塊行爲開發準則 靈活的分配模塊到進程 使用單速分析來預言性能 使用共享存儲進行流水線階段之間通訊 |
實現恢復 | 引入操做的恢復模塊 把所有數據放到恢復穩定和容易達到的地方 |
實現診斷 | 制定一個錯誤處理策略 減小錯誤處理的工做 封裝診斷構件 使用標準日誌服務 |
體系結構的完整性 | 保護模塊間的繼承 分離公共接口構件 |
併發的開發工做 | 從源構件中分離開發構件 保護執行視圖 採用階段開發 經過靜態庫來發布層 |
限制可以使用的採集圖像類型 | 採用適當的抽象開發一個脫機的探測模擬器 使用一個靈活的創建過程 |
多樣性開發和目標平臺 | 分離和封裝依賴目標平臺的代碼 |
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框架 |
三、框架比較
應用框架調查的比較參數包括操做系統、程序設計語言、領域範疇等。
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 |
3、企業應用架構模式
作企業應用開發須要瞭解一些企業應用開發基礎知識,好比分層架構、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
4、UML、XML、.net/java平臺
企業應用系統目前業界流行和通用的就是.Net平臺和Java平臺(J2EE);關於二者的區別參考:http://www.cnblogs.com/heilix/archive/2009/01/17/1377555.html
5、幾種常見架構
-軟件架構通用的服務模式
-類工廠服務
-緩存服務(內存服務)
-配置服務
-異常處理服務
-日誌服務
-加密服務
-驗證服務和受權服務
-消息隊列
-部署服務
-事務處理服務
-幫助服務
-數據驗證服務
一、 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