軟件架構風格介紹

時間 2020-07-11

標籤軟件架構風格介紹欄目系統架構简体版

原文原文鏈接

文章轉自：https://www.cnblogs.com/wintersun/p/4869344.html

架構風格是一組原則。你能夠把它當作是一組爲系統家族提供抽象框架的粗粒度模式。架構風格能改進分塊，還能爲頻繁出現的問題提供解決方案，以此促進設計重用。html

常見的軟件體系結構風格涉及：前端

設計詞彙表是什麼？或者構件和鏈接器的類型是什麼？
可允許的結構模式是什麼？
基本的計算模型是什麼？
風格的基本不變性是什麼？
其使用的常見例子是什麼？
使用此風格的優缺點是什麼？
其常見特例是什麼？

軟件體系結構設計的一箇中心問題是可否重用軟件體系結構模式，或者採用某種軟件體系結構風格。有原則地使用軟件體系結構風格具備以下意義：程序員

它促進了設計的複用，使得一些通過實踐證明的解決方案可以可靠地解決新問題。
它可以帶來顯著的代碼複用，使得體系結構風格中的不變部分可共享同一個解決方案。
便於設計者之間的交流與理解。
經過對標準風格的使用支持了互操做性，以便於相關工具的集成。
在限定了設計空間的狀況下，可以對相關風格做出分析。
可以對特定的風格提供可視化支持。

與此同時，人們目前尚不能準確回答的問題是：shell

系統設計的哪一個要點能夠用風格來描述；
可否用系統的特性來比較不一樣的風格，如何肯定用不一樣的風格設計系統之間的互操做；
可否開發出通用的工具來擴展風格；
如何爲一個給定的問題選擇恰當的體系結構風格，或者如何經過組合現有的若干風格來產生一個新的風格。

M.Shaw等人根據此框架給出了管道與過濾器、數據抽象和麪向對象組織、基於事件的隱式調用、分層系統、倉庫系統及知識庫和表格驅動的解釋器等一些常見的軟件體系結構風格。數據庫

架構風格

客戶端-服務器
將系統分爲兩個應用，其中客戶端向服務器發送服務請求。編程

基於組件的架構
把應用設計分解爲可重用的功能、邏輯組件，這些組件的位置相互透明，只暴露明肯定義的通訊接口。windows

分層架構
把應用的關注點分割爲堆棧組（層）。後端

消息總線
指接收、發送消息的軟件系統，消息基於一組已知格式，以便系統無需知道實際接收者就能互相通訊。瀏覽器

N層/三層架構
用與分層風格差很少同樣的方式將功能劃分爲獨立的部分，每一個部分是一個層，處於徹底獨立的計算機上。緩存

面向對象
該架構風格是將應用或系統任務分割成單獨、可重用、可自給的對象，每一個對象包含數據，以及與對象相關的行爲。

分離表現層
將處理用戶界面的邏輯從用戶界面（UI）視圖和用戶操做的數據中分離出來。

面向服務架構（SOA）
是指那些利用契約和消息將功能暴露爲服務、消費功能服務的應用。

這些架構風格分別適用於特定領域：

通訊
SOA，消息總線，管道和過濾器

部署
客戶端/服務器，三層架構，N層架構

領域
領域模型，網關

交互
分離表現層

結構
基於組件的架構，面向對象，分層架構

下面介紹幾種常見的架構風格：

管道和過濾器風格

在管道/過濾器風格的軟件體系結構中，每一個構件都有一組輸入和輸出，構件讀輸入的數據流，通過內部處理，而後產生輸出數據流。這個過程一般經過對輸入流的變換及增量計算來完成，因此在輸入被徹底消費以前，輸出便產生了。所以，這裏的構件被稱爲過濾器，這種風格的鏈接件就像是數據流傳輸的管道，將一個過濾器的輸出傳到另外一過濾器的輸入。此風格特別重要的過濾器必須是獨立的實體，它不能與其它的過濾器共享數據，並且一個過濾器不知道它上游和下游的標識。一個管道/過濾器網絡輸出的正確性並不依賴於過濾器進行增量計算過程的順序。

圖2-1是管道/過濾器風格的示意圖。一個典型的管道/過濾器體系結構的例子是以Unix shell編寫的程序。Unix既提供一種符號，以鏈接各組成部分(Unix的進程)，又提供某種進程運行時機制以實現管道。另外一個著名的例子是傳統的編譯器。傳統的編譯器一直被認爲是一種管道系統，在該系統中，一個階段(包括詞法分析、語法分析、語義分析和代碼生成)的輸出是另外一個階段的輸入。

圖 2‑1管道/過濾器風格的體系結構

管道/過濾器風格的軟件體系結構具備許多很好的特色：

(1)使得軟構件具備良好的隱蔽性和高內聚、低耦合的特色；

(2)容許設計者將整個系統的輸入/輸出行爲當作是多個過濾器的行爲的簡單合成；

(3)支持軟件重用。重要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器均可被鏈接起來；

(4)系統維護和加強系統性能簡單。新的過濾器能夠添加到現有系統中來；舊的能夠被改進的過濾器替換掉；

(5)容許對一些如吞吐量、死鎖等屬性的分析；

(6)支持並行執行。每一個過濾器是做爲一個單獨的任務完成，所以可與其它任務並行執行。

可是，這樣的系統也存在着若干不利因素。

(1)一般致使進程成爲批處理的結構。這是由於雖然過濾器可增量式地處理數據，但它們是獨立的，因此設計者必須將每一個過濾器當作一個完整的從輸入到輸出的轉換。

(2)不適合處理交互的應用。當須要增量地顯示改變時，這個問題尤其嚴重。

(3)由於在數據傳輸上沒有通用的標準，每一個過濾器都增長了解析和合成數據的工做，這樣就致使了系統性能降低，並增長了編寫過濾器的複雜性

數據抽象與面向對象風格

抽象數據類型概念對軟件系統有着重要做用，目前軟件界已廣泛轉向使用面向對象系統。這種風格創建在數據抽象和麪向對象的基礎上，數據的表示方法和它們的相應操做封裝在一個抽象數據類型或對象中。這種風格的構件是對象，或者說是抽象數據類型的實例。對象是一種被稱做管理者的構件，由於它負責保持資源的完整性。對象是經過函數和過程的調用來交互的。

圖2-2是數據抽象和麪向對象風格的示意圖。

圖 2‑2數據抽象和麪向對象風格的體系結構

面向對象的系統有許多的優勢，並早已爲人所知：

(1) 由於對象對其它對象隱藏它的表示，因此能夠改變一個對象的表示，而不影響其它的對象。

(2) 設計者可將一些數據存取操做的問題分解成一些交互的代理程序的集合。

可是，面向對象的系統也存在着某些問題：

(1)爲了使一個對象和另外一個對象經過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改全部其餘明確調用它的對象。

(2)必須修改全部顯式調用它的其它對象，並消除由此帶來的一些反作用。例如，若是A使用了對象B，C也使用了對象B，那麼，C對B的使用所形成的對A的影響多是料想不到的。

基於事件的隱式調用風格

基於事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中的其它構件中的過程在一個或多個事件中註冊，當一個事件被觸發，系統自動調用在這個事件中註冊的全部過程，這樣，一個事件的觸發就致使了另外一模塊中的過程的調用。

從體系結構上說，這種風格的構件是一些模塊，這些模塊既能夠是一些過程，又能夠是一些事件的集合。過程能夠用通用的方式調用，也能夠在系統事件中註冊一些過程，當發生這些事件時，過程被調用。

基於事件的隱式調用風格的主要特色是事件的觸發者並不知道哪些構件會被這些事件影響。這樣不能假定構件的處理順序，甚至不知道哪些過程會被調用，所以，許多隱式調用的系統也包含顯式調用做爲構件交互的補充形式。

支持基於事件的隱式調用的應用系統不少。例如，在編程環境中用於集成各類工具，在數據庫管理系統中確保數據的一致性約束，在用戶界面系統中管理數據，以及在編輯器中支持語法檢查。例如在某系統中，編輯器和變量監視器能夠登記相應Debugger的斷點事件。當Debugger在斷點處停下時，它聲明該事件，由系統自動調用處理程序，如編輯程序能夠卷屏到斷點，變量監視器刷新變量數值。而Debugger自己只聲明事件，並不關心哪些過程會啓動，也不關心這些過程作什麼處理。

隱式調用系統的主要優勢有：

(1)爲軟件重用提供了強大的支持。當須要將一個構件加入現存系統中時，只需將它註冊到系統的事件中。

(2)爲改進系統帶來了方便。當用一個構件代替另外一個構件時，不會影響到其它構件的接口。

隱式調用系統的主要缺點有：

(1)構件放棄了對系統計算的控制。一個構件觸發一個事件時，不能肯定其它構件是否會響應它。並且即便它知道事件註冊了哪些構件的構成，它也不能保證這些過程被調用的順序。

(2)數據交換的問題。有時數據可被一個事件傳遞，但另外一些狀況下，基於事件的系統必須依靠一個共享的倉庫進行交互。在這些狀況下，全局性能和資源管理便成了問題。

(3)既然過程的語義必須依賴於被觸發事件的上下文約束，關於正確性的推理存在問題。

層次系統風格

層次系統組織成一個層次結構，每一層爲上層服務，並做爲下層客戶。在一些層次系統中，除了一些精心挑選的輸出函數外，內部的層只對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機(在另外一些層次系統中層是部分不透明的)。鏈接件經過決定層間如何交互的協議來定義，拓撲約束包括對相鄰層間交互的約束。

這種風格支持基於可增長抽象層的設計。這樣，容許將一個複雜問題分解成一個增量步驟序列的實現。因爲每一層最多隻影響兩層，同時只要給相鄰層提供相同的接口，容許每層用不一樣的方法實現，一樣爲軟件重用提供了強大的支持。

圖2-3是層次系統風格的示意圖。層次系統最普遍的應用是分層通訊協議。在這一應用領域中，每一層提供一個抽象的功能，做爲上層通訊的基礎。較低的層次定義低層的交互，最低層一般只定義硬件物理鏈接。

圖 2‑3層次系統風格的體系結構

層次系統有許多可取的屬性：

(1)支持基於抽象程度遞增的系統設計，使設計者能夠把一個複雜系統按遞增的步驟進行分解；

(2)支持功能加強，由於每一層至多和相鄰的上下層交互，所以功能的改變最多影響相鄰的上下層；

(3)支持重用。只要提供的服務接口定義不變，同一層的不一樣實現能夠交換使用。這樣，就能夠定義一組標準的接口，而容許各類不一樣的實現方法。

可是，層次系統也有其不足之處：

(1)並非每一個系統均可以很容易地劃分爲分層的模式，甚至即便一個系統的邏輯結構是層次化的，出於對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來；

(2)很難找到一個合適的、正確的層次抽象方法。

倉庫風格

在倉庫風格中，有兩種不一樣的構件：中央數據結構說明當前狀態，獨立構件在中央數據存貯上執行，倉庫與外構件間的相互做用在系統中會有大的變化。

控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一傳統型數據庫；另外一方面，若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。

圖2-4是黑板系統的組成。黑板系統的傳統應用是信號處理領域，如語音和模式識別。另外一應用是鬆耦合代理數據共享存取。

圖 2‑4黑板系統的組成

咱們從圖2-4中能夠看出，黑板系統主要由三部分組成：

(1)知識源。知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通信，它們之間的交互只經過黑板來完成。

(2)黑板數據結構。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源經過不斷地改變黑板數據來解決問題。

(3)控制。控制徹底由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。

C2風格

C2體系結構風格能夠歸納爲：經過鏈接件綁定在一塊兒的按照一組規則運做的並行構件網絡。C2風格中的系統組織規則以下：

(1)系統中的構件和鏈接件都有一個頂部和一個底部；

(2)構件的頂部應鏈接到某鏈接件的底部，構件的底部則應鏈接到某鏈接件的頂部，而構件與構件之間的直接鏈接是不容許的；

(3)一個鏈接件能夠和任意數目的其它構件和鏈接件鏈接；

(4)當兩個鏈接件進行直接鏈接時，必須由其中一個的底部到另外一個的頂部。

圖2-5是C2風格的示意圖。圖中構件與鏈接件之間的鏈接體現了C2風格中構建系統的規則。

圖 2‑5 C2風格的體系結構

C2風格是最經常使用的一種軟件體系結構風格。從C2風格的組織規則和結構圖中，咱們能夠得出，C2風格具備如下特色：

(1)系統中的構件可實現應用需求，並能將任意複雜度的功能封裝在一塊兒；

(2)全部構件之間的通信是經過以鏈接件爲中介的異步消息交換機制來實現的；

(3)構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。

二層C/S咱們再也不介紹了，直接說三層C/S

三層C/S的基本硬件結構

傳統的二層C/S結構存在如下幾個侷限：

l 它是單一服務器且以局域網爲中心的，因此難以擴展至大型企業廣域網或Internet；

l 受限於供應商；

l 軟、硬件的組合及集成能力有限；

l 難以管理大量的客戶機。

所以，三層C/S結構應運而生。三層C/S結構是將應用功能分紅表示層、功能層和數據層三部分。其解決方案是：對這三層進行明確分割，並在邏輯上使其獨立。原來的數據層做爲DBMS已經獨立出來，因此關鍵是要將表示層和功能層分離成各自獨立的程序，而且還要使這兩層間的接口簡潔明瞭。

將上述三層功能裝載到硬件的方法基本上有三種(如圖所示)。其中表示層配置在客戶機中，而數據層配置在服務器中。

通常狀況是隻將表示層配置在客戶機中，與二層C/S結構相比，其程序的可維護性要好得多，是其餘問題並未獲得解決。客戶機的負荷過重，其業務處理所需的數據要從服務器傳給客戶機，因此係統的性能容易變壞。

若是將功能層和數據層分別放在不一樣的服務器中，則服務器和服務器之間也要進行數據傳送。可是，因爲在這種形態中三層是分別放在各自不一樣的硬件系統上的，因此靈活性很高，可以適應客戶機數目的增長和處理負荷的變更。例如，在追加新業務處理時，能夠相應增長裝載功能層的服務器。所以，系統規模越大這種形態的優勢就越顯著。

值得注意的是：三層C/S結構各層間的通訊效率若不高，即便分配給各層的硬件能力很強，其做爲總體來講也達不到所要求的性能。此外，設計時必須慎重考慮三層間的通訊方法、通訊頻度及數據量。這和提升各層的獨立性同樣是三層C/S結構的關鍵問題。

三層C/S的功能

1.表示層

表示層是應用的用戶接口部分，它擔負着用戶與應用間的對話功能。它用於檢查用戶從鍵盤等輸入的數據，顯示應用輸出的數據。爲使用戶能直觀地進行操做，一般要使用圖形用戶接口(GUI)，操做簡單、易學易用。在變動用戶接口時，只需改寫顯示控制和數據檢查程序，而不影響其餘兩層。檢查的內容也只限於數據的形式和值的範圍，不包括有關業務自己的處理邏輯。

圖形界面的結構是不固定的，這便於之後能靈活地進行變動。例如，在一個窗口中不是放入幾個功能，而是按功能分割窗口，以便使每一個窗口的功能簡潔單純。在這層的程序開發中主要是使用可視化編程工具。

2. 功能層

功能層至關於應用的本體，它是將具體的業務處理邏輯地編入程序中。例如，在製做訂購合同的時要計算合同金額，按照定好的格式配置數據、打印訂購合同，而處理所需的數據則要從表示層或數據層取得。表示層和功能層之間的數據交往要儘量簡潔。例如，用戶檢索數據時，要設法將有關檢索要求的信息一次傳送給功能層(參見圖2)，而由功能層處理過的檢索結果數據也一次傳送給表示層。在應用設計中，必定要避免進行一次業務處理，在表示層和功能層間進行多幾回數據交換的笨拙設計。

一般，在功能層中包含有：確認用戶對應用和數據庫存取權限的功能以及記錄系統處理日誌的功能。這層的程序多半是用可視化編程工具開發的，也有使用COBOL和C語言的。

3. 數據層

數據層就是DBMS，負責管理對數據庫數據的讀寫。DBMS必須能迅速執行大量數據的更新和檢索。如今的主流是關係數據庫管理系統(RDBMS)。所以，通常從功能層傳送到數據層的要求大都使用SQL語言。

三層C/S結構的優勢

1。具備靈活的硬件系統構成

對於各個層能夠選擇與其處理負荷和處理特性相適應的硬件。這是一個與系統可縮放性直接相關的問題。例如，最初用一臺Unix工做站做爲服務器，將數據層和功能層都配置在這臺服務器上。隨着業務的發展，用戶數和數據量逐漸增長，這時就能夠將Unix工做站做爲功能層的專用服務器，另外追加一臺專用於數據層的服務器。若業務進一步擴大，用戶數進一步增長，則能夠繼續增長功能層的服務器數目，用以分割數據庫。清晰、合理地分割三層結構並使其獨立，可使系統構成的變動很是簡單。所以，被分紅三層的應用基本上不須要修正。

2。提升程序的可維護性

三層C/S結構中，應用的各層能夠並行開發，各層也能夠選擇各自最適合的開發語言。

3。利於變動和維護應用技術規範

由於是按層分割功能，因此各個程序的處理邏輯變得十分簡單。

4。進行嚴密的安全管理

越關鍵的應用，用戶的識別和存取權限設定愈重要。在三層C/S結構中，識別用戶的機構是按層來構築的，對應用和數據的存取權限也能夠按層進行設定。例如，即便外部的入侵者突破了表示層的安全防線，若在功能層中備有另外的安全機構，系統也能夠阻止入侵者進入其餘部分。

此外，系統管理簡單，可支持異種數據庫，有很高的可用性。

C/S和B/S 的優缺點比較

C/S和B/S是當今世界開發模式技術架構的兩大主流技術。C/S是美國 Borland公司最先研發，B/S是美國微軟公司研發。目前，這兩項技術以被世界各國所掌握，國內公司以C/S和B/S技術開發出產品也不少。這兩種技術都有本身必定的市場份額和客戶羣，各家企業都說本身的管理軟件架構技術功能強大、先進、方便，都能舉出各自的客戶羣體，都有一大羣文人墨客爲本身搖旗吶喊，廣告滿天飛，可謂仁者見仁，智者見智。

一、C/S架構軟件的優點與劣勢

（1）、應用服務器運行數據負荷較輕。

最簡單的C/S體系結構的數據庫應用由兩部分組成，即客戶應用程序和數據庫服務器程序。兩者可分別稱爲前臺程序與後臺程序。運行數據庫服務器程序的機器，也稱爲應用服務器。一旦服務器程序被啓動，就隨時等待響應客戶程序發來的請求；客戶應用程序運行在用戶本身的電腦上，對應於數據庫服務器，可稱爲客戶電腦，當須要對數據庫中的數據進行任何操做時，客戶程序就自動地尋找服務器程序，並向其發出請求，服務器程序根據預約的規則應答，送回結果，應用服務器運行數據負荷較輕。

（2）、數據的儲存管理功能較爲透明。

在數據庫應用中，數據的儲存管理功能，是由服務器程序和客戶應用程序分別獨立進行的，前臺應用能夠違反的規則，而且一般把那些不一樣的（無論是已知仍是未知的）運行數據，在服務器程序中不集中實現，例如訪問者的權限，編號能夠重複、必須有客戶才能創建定單這樣的規則。全部這些，對於工做在前臺程序上的最終用戶，是「透明」的，他們無須過問（一般也沒法干涉）背後的過程，就能夠完成本身的一切工做。在客戶服務器架構的應用中，前臺程序不是很是「瘦小」，麻煩的事情都交給了服務器和網絡。在C/S體系的下，數據庫不能真正成爲公共、專業化的倉庫，它受到獨立的專門管理。

（3）、C/S架構的劣勢是高昂的維護成本且投資大。

首先，採用C/S架構，要選擇適當的數據庫平臺來實現數據庫數據的真正「統一」，使分佈於兩地的數據同步徹底交由數據庫系統去管理，但邏輯上兩地的操做者要直接訪問同一個數據庫纔能有效實現，有這樣一些問題，若是須要創建「實時」的數據同步，就必須在兩地間創建實時的通信鏈接，保持兩地的數據庫服務器在線運行，網絡管理工做人員既要對服務器維護管理，又要對客戶端維護和管理，這須要高昂的投資和複雜的技術支持，維護成本很高，維護任務量大。

其次，傳統的C/S結構的軟件須要針對不一樣的操做系統系統開發不一樣版本的軟件，因爲產品的更新換代十分快，代價高和低效率已經不適應工做須要。在JAVA這樣的跨平臺語言出現以後，B/S架構更是猛烈衝擊C/S，並對其造成威脅和挑戰。

二、B/S架構軟件的優點與劣勢

（1）、維護和升級方式簡單。

目前，軟件系統的改進和升級愈來愈頻繁，B/S架構的產品明顯體現着更爲方便的特性。對一個稍微大一點單位來講，系統管理人員若是須要在幾百甚至上千部電腦之間來回奔跑，效率和工做量是可想而知的，但B/S架構的軟件只須要管理服務器就好了，全部的客戶端只是瀏覽器，根本不須要作任何的維護。不管用戶的規模有多大，有多少分支機構都不會增長任何維護升級的工做量，全部的操做只須要針對服務器進行；若是是異地，只須要把服務器鏈接專網便可，實現遠程維護、升級和共享。因此客戶機愈來愈「瘦」，而服務器愈來愈「胖」是未來信息化發展的主流方向。從此，軟件升級和維護會愈來愈容易，而使用起來會愈來愈簡單，這對用戶人力、物力、時間、費用的節省是顯而易見的，驚人的。所以，維護和升級革命的方式是「瘦」客戶機，「胖」服務器。

（2）、成本下降，選擇更多。

你們都知道windows在桌面電腦上幾乎一統天下，瀏覽器成爲了標準配置，但在服務器操做系統上windows並非處於絕對的統治地位。如今的趨勢是凡使用B/S架構的應用管理軟件，只需安裝在Linux服務器上便可，並且安全性高。因此服務器操做系統的選擇是不少的，無論選用那種操做系統都可讓大部分人使用windows做爲桌面操做系統電腦不受影響，這就使的最流行免費的Linux操做系統快速發展起來，Linux除了操做系統是免費的之外，連數據庫也是免費的，這種選擇很是盛行。

（3）、應用服務器運行數據負荷較重。

因爲B/S架構管理軟件只安裝在服務器端（Server）上，網絡管理人員只須要管理服務器就好了，用戶界面主要事務邏輯在服務器（Server）端徹底經過WWW瀏覽器實現，極少部分事務邏輯在前端（Browser）實現，全部的客戶端只有瀏覽器，網絡管理人員只須要作硬件維護。可是，應用服務器運行數據負荷較重，一旦發生服務器「崩潰」等問題，後果不堪設想。所以，許多單位都備有數據庫存儲服務器，以防萬一。

C/S 與 B/S 區別

Client/Server是創建在局域網的基礎上的，Browser/Server是創建在廣域網的基礎上的。

（1）硬件環境不一樣：

C/S 通常創建在專用的網絡上，小範圍裏的網絡環境，局域網之間再經過專門服務器提供鏈接和數據交換服務。

B/S 創建在廣域網之上的，沒必要是專門的網絡硬件環境，例如電話上網，租用設備，信息本身管理，有比C/S更強的適應範圍，通常只要有操做系統和瀏覽器就行。

（2）、對安全要求不一樣

C/S 通常面向相對固定的用戶羣，對信息安全的控制能力很強。通常高度機密的信息系統採用C/S 結構適宜，能夠經過B/S發佈部分可公開信息。

B/S 創建在廣域網之上，對安全的控制能力相對弱，面向是不可知的用戶羣。

（3）、對程序架構不一樣

C/S 程序能夠更加註重流程，能夠對權限多層次校驗，對系統運行速度能夠較少考慮。

B/S 對安全以及訪問速度的多重的考慮，創建在須要更加優化的基礎之上。比C/S有更高的要求，B/S結構的程序架構是發展的趨勢，從MS的。Net系列的BizTalk 2000 Exchange 2000等，全面支持網絡的構件搭建的系統。SUN和IBM推的JavaBean構件技術等，使B/S更加成熟。

（4）、軟件重用不一樣

C/S 程序能夠不可避免的總體性考慮，構件的重用性不如在B/S要求下的構件的重用性好。

B/S 對的多重結構，要求構件相對獨立的功能。可以相對較好的重用。就如買來的餐桌能夠再利用，而不是作在牆上的石頭桌子。

（5）、系統維護不一樣

系統維護是軟件生存週期中，開銷大，至關重要。C/S 程序因爲總體性，必須總體考察，處理出現的問題以及系統升級難，多是再作一個全新的系統。 B/S 構件組成方面構件個別的更換，實現系統的無縫升級。系統維護開銷減到最小，用戶從網上本身下載安裝就能夠實現升級。

（6）、處理問題不一樣

C/S 程序能夠處理用戶面固定，而且在相同區域，安全要求高的需求，與操做系統相關，應該都是相同的系統。 B/S 創建在廣域網上，面向不一樣的用戶羣，分散地域，這是C/S沒法做到的，與操做系統平臺關係最小。

（7）、用戶接口不一樣

C/S 可能是創建在Window平臺上，表現方法有限，對程序員廣泛要求較高。 B/S 創建在瀏覽器上，有更加豐富和生動的表現方式與用戶交流，而且大部分難度減低，下降開發成本。

（8）、信息流不一樣

C/S 程序通常是典型的中央集權的機械式處理，交互性相對低。 B/S 信息流向可變化， B－B、 B－C、 B－G等信息流向的變化，更像交易中心。

基於層次消息總線的架構風格

JB/HMB風格的基本特徵

目前對軟件體系結構的研究集中在如下方面：各類體系結構風格的彙編和總結、體系結

構描述語言(architectural description languages，簡稱ADLS)、體系結構的形式化基礎、體系結構分析技術、基於體系結構的軟件開發、體系結構恢復和再工程、支持體系結構設計的工具和環境及特定領域的軟件體系結構等。青鳥工程在「九五」期間，對基於構件構架模式的軟件工業化生產技術進行了研究，並實現了青鳥軟件生產線系統151。以青鳥軟件生產線的實踐爲背景，提出了基於層次消息總線的軟件體系結構(Jade bird hierarchical message bus based style，如下簡稱JB/HMB風格)，設計了相應的體系結構描述語言，開發了支持軟件體系結構設計的輔助工具集，並研究了採用JB/HMB風格進行應用系統開發的過程框架。

JB/HMB風格的提出基於如下的實際背景：

(1) 隨着計算機網絡技術的發展，特別是分佈式構件技術的日漸成熟和構件互操做標準的出現，如CORBA，DCOM和EJB等，加速了基於分佈式構件的軟件開發趨勢，具備分佈和併發特色的軟件系統已成爲一種廣泛的應用需求。

(2) 基於事件驅動的編程模式已在圖形用戶界面程序設計中得到普遍應用。在此以前的

程序設計中，一般使用一個大的分支語句(switch Statement)控制程序的轉移，對不一樣的輸人狀況分別進行處理，程序結構不甚清晰。基於事件驅動的編程模式在對多個不一樣事件響應的狀況下，系統自動調用相應的處理函數，程序具備清晰的結構。

(3) 計算機硬件體系結構和總線的概念爲軟件體系結構的研究提供了很好的借鑑和啓發，

在統一的體系結構框架下(即總線和接口規範)，系統具備良好的擴展性和適應性。任何計算機廠商生產的配件，甚至是在設計體系結構時根本沒有預料到的配件，只要遵循標準的接口規範，均可以方便地集成到系統中，對系統功能進行擴充，甚至是即插即用(即運行時刻的系統演化)。正是標準的總線和接口規範的制定，以及標準化配件的生產，促進了計算機硬件的產業分工和蓬勃發展。

JB/HMB風格基於層次消息總線、支持構件的分佈和併發，構件之間經過消息總線進行通信，如圖所示。消息總線是系統的鏈接件，負責消息的分派、傳遞和過濾以及處理結果的返回。各個構件掛接在消息總線上，向總線登記感興趣的消息類型。構件根據須要發出消息，由消息總線負責把該消息分派到系統中全部對此消息感興趣的構件，消息是構件之間通信的惟一方式，構件接收到消息後，根據自身狀態對消息進行響應，並經過總線返回處理結果。因爲構件經過總線進行鏈接，並不要求各個構件具備相同的地址空間或侷限在一臺機器上。該風格能夠較好地刻畫分佈式併發系統，以及基於CORBA，DCOM和EJB規範的系統。

如圖所示，系統中的複雜構件能夠分解爲比較低層的子構件，這些子構件經過局部消息

總線進行鏈接，這種複雜的構件稱爲複合構件。若是子構件仍然比較複雜，能夠進一步分解。

如此分解下去，整個系統造成了樹狀的拓撲結構，樹結構的末端結點稱爲葉結點，它們是系統中的原子構件，再也不包含子構件，原子構件的內部能夠採用不一樣於JB/HMB的風格，例如數據流風格、面向對象風格及管道/過濾器風格等，這些屬於構件的內部實現細節。但要集成到JB/HMB風格的系統中，必須知足JB/HMB風格的構件模型的要求，主要是在接口規約方面的要求。另外，整個系統也能夠做爲一個構件，經過更高層的消息總線，集成更大的系統中。因而，能夠採用統一的方式刻畫整個系統和組成系統的單個構件。

構建模型

系統和組成系統的成分一般是比較複雜的，難以從一個視角得到對它們的完整理解，因

此一個好的軟件工程方法每每從多個視角對系統進行建模，通常包括系統的靜態結構、動態行爲和功能等方面。例如，在Rumbaugh等人提出的OMT(object modeling technology)方法中，

採用了對象模型、動態模型和功能模型刻畫系統的以上3個方面。

借鑑上述思想，爲知足體系結構設計的須要，JB/HMB風格的構件模型包括了接口、靜態結構和動態行爲3個部分，如圖所示。

在圖中所示的構件模型中，左上方是構件的接口部分，一個構件能夠支持多個不一樣的接口，每一個接口定義了一組輸入和輸出的消息，刻畫了構件對外提供的服務以及要求的環境服務，體現了該構件同環境的交互.右上方是用帶輸出的有限狀態自動機刻畫的構件行爲，構件接收到外來消息後，根據當前所處的狀態對消息進行響應，並可能致使狀態的變遷.下方是複合構件的內部結構定義，複合構件是由更簡單的子構件經過局部消息總線鏈接而成的.消息總線爲整個系統和各個層次的構件提供了統一的集成機制。

構件接口

在體系結構設計層次上，構件經過接口定義了同外界的信息傳遞和承擔的系統責任，構件接口表明了構件同環境的所有交互內容，也是惟一的交互途徑.除此以外，環境不該對構件作任何其餘與接口無關的假設，例如實現細節等。JB/HMB風格的構件接口是一種基於消息的互聯接口，能夠較好地支持體系結構設計。

構件之間經過消息進行通信，接口定義了構件發出和接收的消息集合.同通常的互聯接口相比.JB/HMB的構件接口具備兩個顯著的特色.首先，構件只對消息自己感興趣，並不關心消息是如何產生的，消息的發出者和接收者沒必要知道彼此的狀況，這樣就切斷了構件之間的直接聯繫，下降了構件之間的藕合強度，進一步加強了構件的複用潛力，並使得構件的替換變得更爲容易。另外，在通常的互聯接口定義的系統中，構件之間的鏈接是在要求的服務和提供的服務之間進行固定的匹配，而在JB/HMB的構件接口定義的系統中，構件對外來消息的響應，不但同接收到的消息類型相關，並且同構件當前所處的狀態相關.構件對外來消息進行響應後，可能會引發狀態的變遷.所以，一個構件在接收到一樣的消息後，在不一樣時刻所處的不一樣狀態下，可能會有不一樣的響應。

消息是關於某個事件發生的信息，上述接口定義中的消息分爲兩類:(i)構件發出的消息，通知系統中其餘構件某個事件的發生或請求其餘構件的服務；(ii)構件接收的消息，對系統中某個事件的響應或提供其餘構件所需的服務.接口中的每一個消息定義了構件的一個端口，具備互補端口的構件能夠經過消息總線進行通信，互補端口指的是除了消息進出構件的方向不一樣以外，消息名稱、消息帶有的參數和返回結果的類型徹底相同的兩個消息. 當某個事件發生後，系統或構件發出相應的消息，消息總線負責把該消息傳遞到對此消息感興趣的構件.按照響應方式的不一樣，消息可分爲同步消息和異步消息.同步消息是指消息的發送者必須等待消息處理結果返回才能夠繼續運行的消息類型.異步消息是指消息的發送者沒必要等待消息處理結果的返回便可繼續執行的消息類型.常見的同步消息包括(通常的)過程調用。

消息總線

JB/HMB風格的消息總線是系統的鏈接件，構件向消息總線登記感興趣的消息，造成構件-消息響應登記表.消息總線根據接收到的消息類型和構件一消息響應登記表的信息，定位並傳遞該消息給相應的響應者，並負責返回處理結果.必要時，消息總線還對特定的消息進行過濾和阻塞.下圖給出了採用對象類符號表示的消息總線的結構。

運行時的演化

在許多重要的應用領域中，例如金融、電力、電信及空中交通管制等，系統的持續可用性是一個關鍵性的要求，運行時刻的系統演化可減小因關機和從新啓動而帶來的損失和風險。此外，愈來愈多的其餘類型的應用軟件也提出了運行時刻演化的要求，在沒必要對應用軟件進行從新編譯和加載的前提下，爲最終用戶提供系統定製和擴展的能力。JBI/HMB風格方便地支持運行時刻的系統演化，主要體如今如下3個方面：

(1) 動態增長或刪除構件。在JB/HMB風格的系統中，構件接口中定義的輸人和輸出消息刻畫了一個構件承擔的系統責任和對外部環境的要求，構件之間經過消息總線進行通信，彼此並不知道對方的存在。所以只要保持接口不變，構件就能夠方便地替換。一個構件加人到系統中的方法很簡單，只需向系統登記其所感興趣的消息便可。但刪除一個構件可能會引發系統中對於某些消息沒有構件響應的異常狀況，這時能夠採起兩種措施：一是阻塞那些沒有構件響應的消息，二是首先使系統中的其餘構件或增長新的構件對該消息進行響應，而後再刪除相應的構件。系統中可能增刪改構件的狀況包括：當系統功能須要擴充時，往系統中增長新的構件。當對系統功能進行裁剪，或當系統中的某個構件出現問題時，須要刪除系統中的某個構件。用帶有加強功能或修正了錯誤的構件新版本代替原有的舊版本。

(2) 動態改變構件響應的消息類型。相似地，構件能夠動態地改變對外提供的服務(即接收的消息類型)，這時應經過消息總線對發生的改變進行從新登記。

(3) 消息過濾。利用消息過濾機制，能夠解決某些構件集成的不匹配問題，詳見「消息過濾」一節。消息過濾經過阻塞構件對某些消息的響應，提供了另外一種動態改變構件對消息進行響應的方式。

JB/HMB風格的優勢

以上討論了JB/HMB風格的各組成要素，下面對JB/HMB風格的主要特色做總結。

(1) 從接口、結構和行爲方面對構件進行刻畫。在JB/HMB風格中，構件的描述包括接口、靜態結構和動態行爲3個方面。接口：構件能夠提供一個或多個接口，每一個接口定義了一組發送和接收的消息集合，刻畫了構件對外提供的服務以及要求的環境服務，接口之間能夠經過繼承表達類似性。

靜態結構：複合構件是由子構件經過局部消息總線鏈接而成的，造成該複合構件的內部結構。

動態行爲：構件行爲經過帶輸出的有限狀態機刻畫，構件接收到外來消息後，不但根

據消息類型，並且根據構件當前所處的狀態對消息進行響應，並致使狀態的變遷。

基於層次消息總線：消息總線是系統的鏈接件，負責消息的傳遞、過濾和分派，以及

處理結果的返回。各個構件掛接在總線上，向系統登記感興趣的消息。構件根據須要發出消息，由消息總線負責把該消息分派到系統中對此消息感興趣的全部構件。構件接收到消息後，根據自身狀態對消息進行響應，並經過總線返回處理結果。因爲構件經過總線進行鏈接，並不要求各個構件具備相同的地址空間或侷限在一臺機器上，系統具備併發和分佈的特色。系統和複合構件能夠逐層分解，子構件經過(局部)消息總線相連。每條消息總線分別屬於系統和各層次的複合構件，咱們把這種特徵的總線稱爲層次消息總線。在系統開發方面，因爲各層次的總線局部在相應的複合構件中，所以能夠更好地支持系統的構造性和演化性。

統一描述系統和組成系統的構件：組成系統的構件經過消息總線進行鏈接，複雜構

件又能夠分解爲比較簡單的子構件，經過局部消息總線進行鏈接，若是子構件仍然比較複雜，

能夠進一步分解。系統呈現出樹狀的拓撲結構。另外，整個系統也能夠做爲一個構件，集成到更大的系統中。因而，就能夠對整個系統和組成系統的各層構件採用統一的方式進行描述。

支持運行時刻的系統演化：系統的持續可用性是許多重要的應用系統的一個關鍵性

要求，運行時刻的系統演化可減小因關機和從新啓動而帶來的損失和風險。JB/HMB風格方便地支持運行時刻的系統演化，主要包括動態增長或刪除構件、動態改變構件響應的消息類型和消息過濾。

REST架構風格

首先，REST是Web自身的架構風格。REST也是Web之因此取得成功的技術架構方面因素的總結。REST是世界上最成功的分佈式應用架構風格（成功案例：Web，還不夠嗎？）。它是爲運行在互聯網環境的分佈式超媒體系統量身定製的。互聯網環境與企業內網環境有很是大的差異，最主要的差異是兩個方面：

可伸縮性需求沒法控制：併發訪問量可能會暴漲，也可能會暴跌。
安全性需求沒法控制：沒法控制客戶端發來的請求的格式，極可能會是惡意的請求。

而所謂的「超媒體系統」，即，使用了超文本的系統。能夠把「超媒體」理解爲超文本+媒體內容。

REST是HTTP/1.1協議等Web規範的設計指導原則，HTTP/1.1協議正是爲實現REST風格的架構而設計的。新的Web規範，其設計必須符合REST的要求，不然整個Web的體系架構會由於引入嚴重矛盾而崩潰。這句話不是危言聳聽，作個類比，假如蘇州市政府贊成在市區著名園林的附近大型土木，建造大量具備後現代風格的摩天大樓，那麼不久以後世界聞名的蘇州園林美景將不復存在。

上述這些關於「REST是什麼」的描述，能夠總結爲一句話：REST是全部Web應用都應該遵照的架構設計指導原則。固然，REST並非法律，違反了REST的指導原則，仍然可以實現應用的功能。可是違反了REST的指導原則，會付出不少代價，特別是對於大流量的網站而言。

要深刻理解REST，須要理解REST的五個關鍵詞：

資源（Resource）
資源的表述（Representation）
狀態轉移（State Transfer）
統一接口（Uniform Interface）
超文本驅動（Hypertext Driven）

什麼是資源？

資源是一種看待服務器的方式，即，將服務器看做是由不少離散的資源組成。每一個資源是服務器上一個可命名的抽象概念。由於資源是一個抽象的概念，因此它不只僅能表明服務器文件系統中的一個文件、數據庫中的一張表等等具體的東西，能夠將資源設計的要多抽象有多抽象，只要想象力容許並且客戶端應用開發者可以理解。與面向對象設計相似，資源是以名詞爲核心來組織的，首先關注的是名詞。一個資源能夠由一個或多個URI來標識。URI既是資源的名稱，也是資源在Web上的地址。對某個資源感興趣的客戶端應用，能夠經過資源的URI與其進行交互。

什麼是資源的表述？

資源的表述是一段對於資源在某個特定時刻的狀態的描述。能夠在客戶端-服務器端之間轉移（交換）。資源的表述能夠有多種格式，例如HTML/XML/JSON/純文本/圖片/視頻/音頻等等。資源的表述格式能夠經過協商機制來肯定。請求-響應方向的表述一般使用不一樣的格式。

什麼是狀態轉移？

狀態轉移（state transfer）與狀態機中的狀態遷移（state transition）的含義是不一樣的。狀態轉移說的是：在客戶端和服務器端之間轉移（transfer）表明資源狀態的表述。經過轉移和操做資源的表述，來間接實現操做資源的目的。

什麼是統一接口？

REST要求，必須經過統一的接口來對資源執行各類操做。對於每一個資源只能執行一組有限的操做。以HTTP/1.1協議爲例，HTTP/1.1協議定義了一個操做資源的統一接口，主要包括如下內容：

7個HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS
HTTP頭信息（可自定義）
HTTP響應狀態代碼（可自定義）
一套標準的內容協商機制
一套標準的緩存機制
一套標準的客戶端身份認證機制

REST還要求，對於資源執行的操做，其操做語義必須由HTTP消息體以前的部分徹底表達，不能將操做語義封裝在HTTP消息體內部。這樣作是爲了提升交互的可見性，以便於通訊鏈的中間組件實現緩存、安全審計等等功能。

什麼是超文本驅動？

「超文本驅動」又名「將超媒體做爲應用狀態的引擎」（Hypermedia As The Engine Of Application State，來自Fielding博士論文中的一句話，縮寫爲HATEOAS）。將Web應用看做是一個由不少狀態（應用狀態）組成的有限狀態機。資源之間經過超連接相互關聯，超連接既表明資源之間的關係，也表明可執行的狀態遷移。在超媒體之中不只僅包含數據，還包含了狀態遷移的語義。以超媒體做爲引擎，驅動Web應用的狀態遷移。經過超媒體暴露出服務器所提供的資源，服務器提供了哪些資源是在運行時經過解析超媒體發現的，而不是事先定義的。從面向服務的角度看，超媒體定義了服務器所提供服務的協議。客戶端應該依賴的是超媒體的狀態遷移語義，而不該該對因而否存在某個URI或URI的某種特殊構造方式做出假設。一切都有可能變化，只有超媒體的狀態遷移語義可以長期保持穩定。

理解REST風格的架構所具備的6個的主要特徵：

面向資源（Resource Oriented）
可尋址（Addressability）
連通性（Connectedness）
無狀態（Statelessness）
統一接口（Uniform Interface）
超文本驅動（Hypertext Driven）

這6個特徵是REST架構設計優秀程度的判斷標準。其中，面向資源是REST最明顯的特徵，即，REST架構設計是以資源抽象爲核心展開的。可尋址說的是：每個資源在Web之上都有本身的地址。連通性說的是：應該儘可能避免設計孤立的資源，除了設計資源自己，還須要設計資源之間的關聯關係，而且經過超連接將資源關聯起來。無狀態、統一接口是REST的兩種架構約束，超文本驅動是REST的一個關鍵詞，在前面都已經解釋過，就再也不贅述了。

從架構風格的抽象高度來看，常見的分佈式應用架構風格有三種：

分佈式對象（Distributed Objects，簡稱DO）

架構實例有CORBA/RMI/EJB/DCOM/.NET Remoting等等

遠程過程調用（Remote Procedure Call，簡稱RPC）

架構實例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等

表述性狀態轉移（Representational State Transfer，簡稱REST）

架構實例有HTTP/WebDAV

DO和RPC這兩種架構風格在企業應用中很是廣泛，而REST則是Web應用的架構風格，它們之間有很是大的差異。

REST與DO的差異在於：

REST支持抽象（即建模）的工具是資源，DO支持抽象的工具是對象。在不一樣的編程語言中，對象的定義有很大差異，因此DO風格的架構一般都是與某種編程語言綁定的。跨語言交互即便能實現，實現起來也會很是複雜。而REST中的資源，則徹底中立於開發平臺和編程語言，可使用任何編程語言來實現。
DO中沒有統一接口的概念。不一樣的API，接口設計風格能夠徹底不一樣。DO也不支持操做語義對於中間組件的可見性。
DO中沒有使用超文本，響應的內容中只包含對象自己。REST使用了超文本，能夠實現更大粒度的交互，交互的效率比DO更高。
REST支持數據流和管道，DO不支持數據流和管道。
DO風格一般會帶來客戶端與服務器端的緊耦合。在三種架構風格之中，DO風格的耦合度是最大的，而REST的風格耦合度是最小的。REST鬆耦合的源泉來自於統一接口+超文本驅動。

REST與RPC的差異在於：

REST支持抽象的工具是資源，RPC支持抽象的工具是過程。REST風格的架構建模是以名詞爲核心的，RPC風格的架構建模是以動詞爲核心的。簡單類比一下，REST是面向對象編程，RPC則是面向過程編程。
RPC中沒有統一接口的概念。不一樣的API，接口設計風格能夠徹底不一樣。RPC也不支持操做語義對於中間組件的可見性。
RPC中沒有使用超文本，響應的內容中只包含消息自己。REST使用了超文本，能夠實現更大粒度的交互，交互的效率比RPC更高。
REST支持數據流和管道，RPC不支持數據流和管道。
由於使用了平臺中立的消息，RPC風格的耦合度比DO風格要小一些，可是RPC風格也經常會帶來客戶端與服務器端的緊耦合。支持統一接口+超文本驅動的REST風格，能夠達到最小的耦合度。

比較了三種架構風格之間的差異以後，從面向實用的角度來看，REST架構風格能夠爲Web開發者帶來三方面的利益：

簡單性

採用REST架構風格，對於開發、測試、運維人員來講，都會更簡單。能夠充分利用大量HTTP服務器端和客戶端開發庫、Web功能測試/性能測試工具、HTTP緩存、HTTP代理服務器、防火牆。這些開發庫和基礎設施早已成爲了平常用品，不須要什麼火箭科技（例如神奇昂貴的應用服務器、中間件）就能解決大多數可伸縮性方面的問題。