萬字體系結構風格，只知道 MVC 的你太 LOW 了

注：本文爲軟件體系結構風格課程筆記，圖大多PPT上圖片，部分圖片找不到出處，侵權刪

軟件體系結構與軟件體系結構風格

軟件體系結構：系統的框架結構，用較高的層次描述各部分之間的關係與接口
軟件體系結構風格：不同的結構有些差別，但是不同的系統設計方案總有共性，於是我們進一步抽象總結，把共性抽取出來，形成了具有代表性的可廣泛接受的體系結構風格，形成複用的體系結構，是從設計方案的 大力度重用

管道過濾器體系結構風格
面向對象體系結構風格
事件驅動體系結構風格
分層體系結構風格
C2體系結構風格（理論化）
數據共享體系結構風格
解釋器體系結構風格（系統執行通過解釋器執行）
反饋控制環體系結構風格（鍋爐溫度控制和機器人機械臂懸臂角度控制）
C/S體系結構風格
B/S體系結構風格
公共對象請求對象代理體系結構風格（分佈式應用系統學術化描述）
正交體系結構風格（數學的正交概念對軟件體系結構進行分割，使得模塊獨立）
基於層次消息總線體系結構風格（大型消息系統解耦）
MVC體系結構風格（前端後端都可以用）
異構體系風格集成（學校官網）

核心概念

構件（功能相關的組件，模塊）
連接件（連接方式：直接調用，代理連接，消息系統，事件機制等）
約束（誰和誰可以連接，連接過程中的限制條件拓撲結構限制，不形成依賴環等；語義限制：給定必須的參數等）

一丶管道過濾器體系結構風格

管道：輸入輸出數據流的通路
過濾器：負責對數據的加工處理，都需要有輸入和輸出端口，儘量滿足一下兩點

每個filter獨立，filter之間不需要交互
filter之間儘量與順序無關

1. 應用

Web應用

Web應用：任何用戶訪問任何界面都需要一些建權等操作（如身份檢測等等）
[下圖爲引用，侵權刪除]

Web常見的過濾器：

字符集編碼檢查
Header數據檢查
重定向
身份驗證過濾器（Authentication Filters）
數據壓縮過濾器（Data compression Filters）
加密過濾器（Encryption Filters）
觸發資源訪問事件過濾器
圖像轉換過濾器（Image Conversion Filters）
日誌記錄和審覈過濾器（Logging and Auditing Filters）
MIME-TYPE 鏈過濾器（MIME-TYPE Chain Filters）
標記化過濾器（Tokenizing Filters）
XSL/T 過濾器（XSL/T Filters），轉換 XML 內容

JAVA,C#的編譯模式

2. 優缺點

簡單
易擴展，進化
複用高
併發，子任務併發
清晰拓撲，便於系統分析
不適合設計交互式
難以進行錯誤處理

二丶面向對象體系結構風格

相關的操作數據封裝抽象

優缺點

操作數據封裝，內聚獨立性
繼承，利於複用
依賴，調用必須知道對方標識與名詞
連鎖，一個改變，一系列都要改

三丶事件驅動體系結構風格

事件與處理系統有映射關係
根據事件聲明和發展狀態來驅動整個應用運行

事件驅動系統構建提夠了

一個過程集合
一組事件

應用模型

發佈/訂閱模型

關注與發送
訂單的運送

點對點模型

處理超售等

存儲轉發模型

不直接處理而是保存稍後處理

請求/響應模型

網頁的請求與響應

優缺點

發佈事件和處理不需要互相知道
複用
利於升級
放棄了計算的控制權，完全由處理系統決定
數據傳輸問題

四丶分層體系結構風格

系統根據功能內聚爲一個層次，高層使用低層的接口，

應用

三層架構

IBM定義的三層Web英語架構，表現層，業務邏輯層，數據存儲/資源層

安卓操作系統
應用層，應用框架層，庫/運行時，Linux內核

優缺點

只給相鄰層提供接口
功能變化之多影響量詞
利於升級
很難正確劃分，也並不是所有的系統都可以按照層次劃分
系統性能下降
調試需要跨層

五丶C2體系結構風格

六丶數據共享體系結構風格

兩種主要元素：構建+中央數據單元（核心）

控制策略兩種類型

傳統數據庫（一般是外部事件驅動）
黑板（來自數據狀態驅動）

黑板

黑板系統主要包括3部分：

知識源是主要的信息來源
知識源在邏輯上和物理上都是獨立的
知識源只與產生它們的應用有關
通過中央數據單元與知識源的配合完成相關業務邏輯
這一過程對外部環境是透明的
中央數據單元
黑板系統的運行完全依賴於中央數據單元的狀態變化
中央數據單元反映了業務邏輯的求解狀態
在多個知識源之間，中央數據單元起到了通信機制的作用
控制單元
由中央數據單元的狀態來驅動的
知識源的執行導致了中央數據單元的狀態發生變化
控制單元根據預先定義的策略，啓動相應的知識源，以完成系統的控制任務

經常被用於

信號處理，例如：語音和模式識別，
自然語言處理領域中也有廣泛的應用，例如：機器翻譯和句法分析

生活中如自然/科學類期刊

中央數據單元：期刊
知識源：科研人員/研究所
控制單元：評審機制

優缺點

便於共享，不關心來源
將構建作爲知識點添加到系統來
利於升級
不同知識需要一致
需要同步和加鎖機制來保證完整性和一致性

七丶解釋器體系結構風格

用了彌合程序語義和計算機硬件之間的間隙
主要是構建虛擬機

應用

JAVA的編譯過程會有解釋器（源程序到機器碼）

如果是使用頻繁的那麼會採用一次性編譯，不是的就會採用解釋器逐條翻譯，拿到一條運行一條，JIT編譯的過程很慢，但後續可以直接跑了
腳本語言Awk，Perl
遊戲中往往爲了增加靈活性使用Lua
比如魔獸世界可以使用Lua腳本來改變地圖等，Lua語言被解釋成魔獸世界到底變成什麼
安卓虛擬機
安卓內嵌了一個解釋器使得同一個事物在不同平臺不同型號顯示不同

優缺點

提高移植能力，跨平臺
可以對未實現的硬件仿真
使用了特定語言和自定義操作規則，增加了系統運行的開銷
解釋器系統難以設計和設計

八丶反饋控制環體系結構風格

程序執行過程能夠從外部環境提取一些反應自身的數據，來較真後續執行的參數，反饋控制環是連續循環的反饋

開車，你看到開歪了，調整角度，繼續開車

在反饋控制環系統中，主要包括以下3個部分：

過程，指操縱過程變量的相關機制
數據元素：
輸入變量
控制變量
操縱變量
相關參考值
控制器
收集反饋
根據反饋修正變量
繼續驅動運行

應用

機器學習：自動駕駛

智能體：自動駕駛軟件
環境：傳感器探測的環境
狀態：環境各對象
行爲：軟件決定如何行駛

機器人控制

九丶C/S體系結構風格

客戶機/服務器

十丶B/S體系結構風格

瀏覽器/服務器

十一丶公共對象請求代理體系結構風格

CORBA ：Common Object Request Broker Architecture
完全按照CORBA原則設計的並不多，只要用於體系結構的研究領域
OMG對象管理組織（Object Management Group）負責管理，在異構分佈式環境下，可以利用CORBA來實現應用程序之間的交互操作

跟代理對象打交道，讓代理對象去與真正的交互，可以屏蔽細節，簡化編程

CORBA主要構成

CORBA規範主要包括：

對象請求代理ORB
對象適配器(Object Adapter，OA)
接口定義語言IDL ( Interface description language )
接口存儲(Interface Repository，IR)
ORB內部的相關協議

CORBA體系結構的核心是ORB：

Object Request Broker
ORB作爲“軟件總線”用來連接網絡上的不同應用對象

十二丶正交體系結構風格

正交線性無關，不交互
正交體系結構的基本思想是：

線索：按照功能的正交相關性，將系統垂直地劃分爲若干個子系統，每個子系統用一條線索來實現
構件：每條線索由多個具有不同層次功能和抽象級別的構件組成

公共的頂層：用於觸發各條線索運行
公共的底層：包含了各條線索需要的數據

十三丶層次消息總線體系結構風格

理論：消息驅動的編程方法和計算機硬件總線概念

在構件之間，消息是唯一的通信方式

構件發出請求消息，然後總線把請求消息分派到系統中所有對此感興趣的構件（構件可以生成也可以消費消息）
在接收到請求消息後，構件將根據自身狀態對其進行響應，並通過總線返回處理結果

層次：存在某個構建本身也是個消息總線體系結構風格

貓抓老鼠

貓將自己的位置發送在消息總線上，而老鼠要躲避貓，消息總線將這個消息告訴老鼠

消息總線任務

消息登記：在基於消息的系統中，構件需要向消息總線登記自己所感興趣的消息，不關心該消息是由哪個構件發出的
消息分派和傳遞：消息總線負責在構件之間傳遞消息，根據構件—消息響應登記表把消息分派給對其感興趣的構件，並返回處理結果
消息過濾：在不同的構件中，同一消息可能使用了不同的名字，不同的消息也可能使用了相同的名字，在構件集成時，需要對消息進行過濾

應用

ESB消息總線

[下圖爲引用侵權刪除鏈接地址 ]

優缺點

支持構建分佈式存儲和併發運行
系統更加靈活，擴展性更高，每個構件都可以分開部署
可以對未實現的硬件仿真
增加了系統運行的開銷，速度變慢
設計更加複雜

十四丶MVC體系結構風格

圖片鏈接

模型，是應用程序的核心，封裝了問題的核心數據、邏輯關係和計算功能，提供了處理問題的操作過程
視圖，是模型的表示，提供了交互界面，爲用戶顯示模型信息
控制器，負責處理用戶與系統之間的交互，爲用戶提供操作接口

優缺點

多個視圖與一個模型相對應，變化-傳播機制確保了所有相關視圖都能夠及時地獲取模型變化信息，從而使所有視圖和控制器同步，便於維護
具有良好的移植性，由於模型獨立於視圖，因此，可以方便地實現不同部分的移植
系統被分割爲三個獨立的部分，當功能發生變化時，改變其中的一個部分就能夠滿足要求
增加了系統設計和運行複雜性
視圖與控制器連接過於緊密，妨礙了二者的獨立重用
視圖訪問模型的效率比較低

十五丶異構集成

從根本上來說，不同體系結構風格有各自的優點和缺陷，應該根據具體情況來選擇系統的框架結構，以解決實際問題

基於HMB的異構體系結構：

整體框架採用HMB，各個複合構件分別採用HMB結構、管道/過濾器結構和數據共享結構