架構風格

腦圖連接：軟件架構

軟件體系結構風格是描述某一特定應用領域中系統組織方式的慣用模式。體系結構風格定義一個系統家族，即一個體繫結構定義一個詞彙表和一組約束。詞彙表中包含一些構件和鏈接件類型，而這組約束指出系統是如何將這些構件和鏈接件組合起來的。也就是說，架構體系都是以「構件」的思路進行軟件實現的。

體系結構風格反映了領域中衆多系統所共有的結構和語義特性，並指導如何將各個模塊和子系統有效地組織成一個完整的系統。對軟件體系結構風格的研究和實踐促進對設計的重用，一些通過實踐證明的解決方案也能夠可靠地用於解決新的問題。例如，若是某人把系統描述爲「客戶/服務器」模式，則沒必要給出設計細節，馬上就會明白系統是如何組織和工做的。

傳統的架構風格

依據David Calvert在1996年給出了一份架構風格/模式的清單，架構風格包括了：

• 數據流系統——批處理，管道-過濾器。
• 調用-返回系統——主程序和子程序，面向對象系統，分層。
• 獨立組件——通訊過程，事件系統。
• 虛擬機——解釋器，基於規則的系統。
• 以數據爲中心的系統（倉庫）——數據庫，超文本系統，黑板。

數據流風格

面向數據的架構風格，軟件的處理粒度是赤裸裸的「數據」，而不需對數據進行任何的「包裝」。

批處理序列

組件爲一系列固定順序的計算單元（獨立程序），組件間只經過數據傳遞交互。數據計算單元的執行必須在前一單元徹底結束後才能開始，數據以總體的方式傳遞。

管道/過濾器

每一個構件都有一組輸入和輸出，構件讀取輸入的數據流，通過內部處理，而後產生輸出數據流。這個過程一般經過對輸入流的變換及增量計算來完成，包括經過計算和增長信息豐富數據，經過濃縮和刪除精煉數據，經過改變記錄方式轉化數據，遞增地轉化數據等。在輸入被徹底消費以前，輸出便產生了。這裏構件被稱爲過濾器，鏈接件就是數據流傳輸的管道，將一個過濾器的輸出傳到另外一個過濾器的輸入。

此風格要求過濾器必須是獨立的實體，它不能與其它的過濾器共享數據，並且一個過濾器不知道它上游和下游的標識。一個管道/過濾器網絡輸出的正確性並不依賴於過濾器進行增量計算過程的順序。 

總結

優點：

• 使得軟構件具備良好的隱蔽性和高內聚、低耦合的特色；
• 構件之間的組合、重用十分簡單，易於拼接成業務功能塊；

限制：

• 不適合處理交互的應用。因爲業務功能塊是按照結構化的流程設計的，因此只適用於處理特定的邏輯流程。當須要增量地顯示改變時，這個問題尤其嚴重。
• 數據因爲沒有任何封裝，傳輸上沒有通用的標準，每一個過濾器都增長了解析和合成數據的工做，這樣就致使了系統性能降低，並增長了編寫過濾器的複雜性。

調用/返回風格

主程序 & 子程序

採用單線程控制，把問題劃分爲若干處理步驟，構件即爲主程序和子程序。子程序一般可合成爲模塊。過程調用做爲交互機制，即充當鏈接件。調用關係具備層次性，其語義邏輯表現爲子程序的正確性，取決於它調用的子程序的正確性。

面向對象

這種風格的構件是對象。對象是抽象數據類型的實例。在抽象數據類型中，數據的表示和它們的相應操做被封裝起來。對象的行爲體如今其接受和請求的動做。鏈接件即對象間交互的方式，對象是經過函數和過程的調用來交互的。這種結構風格中包含有封裝、交互、多態、集成和重用等特徵。

層次結構

層次系統組織成一個層次結構。鏈接件經過決定層間如何交互的協議來定義，拓撲約束包括對相鄰導間交互的約束。這個風格將大的問題分解爲若干個漸進的小問題，逐步解決，隱藏了不少複雜度。修改一層，最多影響兩層，而一般只能影響上層。上層必須知道下層的身份，不能調整層次之間的順序。

優勢：

• 支持基於抽象程度遞增的系統設計，使設計者能夠把一個複雜系統按遞增的步驟進行分解；
• 支持重用。只要提供的服務接口定義不變，同一層的不一樣實現能夠交換使用。

獨立構件風格

面向消息的通信架構（進程間通訊）

構件是獨立的過程，鏈接件是消息傳遞。這種風格的特色是構件一般是命名過程（進程），消息傳遞的方式能夠是點到點、異步和同步方式及遠過程調用（RPC）等。在這種架構中，消息的傳遞目標是顯式聲明的——明確指向另一個構件。

事件驅動架構

構件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中其餘構件中的過程在一個或多個事件中註冊，當一個事件被觸發，系統自動調用在這個事件中註冊的處理機制。一個事件的觸發就致使了另外一個模塊中過程的調用——這自己屬於一種異步機制的實現（實際上有些事件的響應是以同步方式實現的）。

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

構件之間交互的鏈接件每每是以過程之間的隱式調用（Implicit Invocation）來實現的。基於事件的隱式調用風格的主要優勢是爲軟件重用提供了強大的支持，爲構件的維護和演化帶來了方便；其缺點是構件放棄了對系統計算的控制。

優勢：

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

缺點：

• 構件放棄了對系統計算的控制。一個構件觸發一個事件時，不能肯定其它構件是否會響應它。並且即便它知道事件註冊了哪些構件的構成，它也不能保證這些過程被調用的順序；
• 既然過程的語義必須依賴於被觸發事件的上下文約束。

虛擬機

解釋器

一個解釋器一般包括完成解釋工做的解釋引擎，一個包含將被解釋的代碼的存儲區，一個記錄解釋引擎當前工做狀態的數據結構，以及一個記錄源代碼被解釋執行的進度的數據結構。具備解釋器風格的軟件中含有一個虛擬機，能夠仿真硬件的執行過程和一些關鍵應用；其缺點是執行效率較低。

基於規則的系統

基於規則的系統包括規則集、規則解釋器、規則/數據選擇器及工做內存。

倉庫風格

在倉庫風格中，有兩種不一樣的構件：中央數據結構（倉庫）說明當前狀態，獨立構件在中央數據存貯上執行。

數據庫架構（共享數據）

數據庫架構是倉庫風格最多見的形式。構件主要有兩大類，一個是中央共享數據源，保存當前系統的數據狀態；另外一個是多個獨立處理元素，處理元素對數據元素進行操做。例如二層C/S架構中不一樣的服務項對服務數據庫的訪問模型。

黑板架構

黑板架構包括知識源、黑板和控制3個部分。

• 知識源包括若干獨立計算的不一樣單元，提供解決問題的（與應用程序相關的）知識，知識源響應黑板上的變化，也只修改黑板  ==> 獨立算法模塊；
• 黑板是一個全局數據庫，包含問題域解空間的所有狀態。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源經過不斷地改變黑板數據來解決問題。
• 控制邏輯：控制徹底由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。

黑板一般應用在對於解決問題沒有肯定性算法的系統中，例如信號處理、問題規劃及編譯器優化等軟件系統的設計中。

超文本系統

構件以網狀鏈接方式相互鏈接，用戶能夠在構件之間進行按照人類的聯想思惟方式任意跳轉到相關構件。超文本是一種非線性的網狀信息組織方法，它以結點爲基本單位，鏈做爲結點之間的聯想式關聯。超文本系統一般應用在互聯網領域。

 

---

不一樣的人劃分過不一樣的架構模型，而往往以爲，若是拿來兩本書中所描述的架構模型，他們說的徹底不在一個維度上，由於分類方式不一樣，獲得的結果也不一樣，甚至同一套模型，在兩本書裏也獲得了不一樣的名字……

我梳理了本身目前所理解到的全部架構模型，並按照本身的理解程度，從新進行了分類獲得了一組架構圖，如今寫下了。但願你們能多提意見。我不必定徹底贊同大家的觀點，但真理老是越辯越清，辯論不傷和睦，只爲共同進步！

基於鏈接件的架構風格劃分

前面已經提到，「架構」是一種基於「組件」的軟件體系模型。在這個模型中，存在兩類基本的元素：構件 + 鏈接件。很明確的，構件是計算單元（實體）；而鏈接件則存在多種的形式——構件間如何實現鏈接和交互，是各類架構在處理問題上的本質區別（或者說是問題模型的區別）。

數據流風格

鏈接件即爲傳輸的數據，而構件之間只經過數據傳遞交互。「管道/過濾器」風格相比於「批處理」，其鏈接件（即「管道」）是以流的形式傳輸的數據，而不是一個完整的數據體。

調用/返回風格

過程調用做爲交互機制，即充當鏈接件的角色。構件之間經過主動或被動的顯示調用執行交互。

主程序/子程序風格中，構件即爲主程序和子程序。面向對象更沒的說，構件即爲不一樣的對象。而分層架構模型則是將不一樣層次的功能集合做爲構件，構件間經過接口調用，實現交互。

還有兩種流行的架構模式，也能夠劃歸到「主程序-子程序」的返回/調用風格中——「插件式」的微內核架構和RPC（遠程過程調用）。

主程序/子程序的架構風格通常是經過本地管道執行調用，插件架構經過系統級<dlfcn>調用插件模塊，RPC執行調用的方式是經過socket。鏈接件實現通訊的方式可能不一樣，但在宏觀上，他們都在調用其餘模塊的已有功能塊。

獨立構件風格

鏈接件是消息或事件，以顯示或隱式的方式在構件間傳遞交互。

「進程通訊」架構中，構件一般是命名過程（所謂過程，即功能實現，能夠是函數、程序體或類對象），鏈接件是消息傳遞，傳遞方式能夠是點對點、同步或異步的方式，以及RPC遠程過程（方法）調用等。

事件驅動的系統，也稱爲「基於事件的隱式調用」架構，構件不直接調用一個過程，而是觸發或廣播一個或多個事件。鏈接件即爲事件（消息的一種表現形式）。之因此成爲事件，是由於它會自動觸發其餘構件的處理動做，改變構件的狀態和行爲。從宏觀上看，構件之間是經過「隱式調用」實現交互的。

思考

我的認爲，「獨立構架風格」已經帶有很強的「場景」適用性了——因爲獨立構件風格中的鏈接件是以「消息或事件」的形式存在的，而通常狀況下進程內部不多（或者說非必須）經過消息傳遞信號【固然這也不必定，若是須要多個層次或對象間的調用，好比GUI中的事件機制】，每每「獨立架構」風格是用在進程間或分佈式環境中的通信機制上的。

C2風格（Component and Connector）

C2是針對通訊領域的一種場景架構模型。C2架構應該說是對獨立架構的一種拓展，或是從新定義——它以「消息」的概念替代了傳統意義上的鏈接件，同時將消息處理節點從構件中獨立出來做爲一種基本類型，稱爲「鏈接件」。

• 構件：消息處理的實體；
• 消息：包括通知消息和請求消息，分別以自上而下和自下而上的方式傳遞；
• 鏈接件：負責消息路由與廣播，同時也對消息進行過濾。

另外，它還定義了構件與鏈接件的交互規則，以下圖所示：

而這種交互方式，同「基於消息的進程間通信架構」和「事件驅動架構」同樣，幾乎定格成了一種默認形式，在全部的通信體系中都有所應用。故而稱之爲「風格」也不爲過。

基於場景的架構風格劃分

相比於特定領域架構模型，它沒有特定的問題域，而是在不一樣的領域中，可能存在共性的應用場景，大體可分爲虛擬機、倉庫、C二、微內核等架構風格。

特定領域架構模型

常見的領域包括：分佈式、消息通訊、WebService、企業級架構等。