天天看點

架構師備戰(四)-軟體架構設計(一) 軟體架構風格概念

作者:IT動力

在講到軟體架構的概念時,首先我們要了解到,架構是在做什麼樣的事情,它在整個軟體開發周期中所屬什麼樣的位置。

之前學習軟體工程時,我們學到了開發模型,裡面涉及到需求分析,概要設計,詳細設計,編碼,測試。但事實上,沒有提到架構這個東西。

為什麼這麼重要的東西沒有在軟體開發模型展現呢,其實是因為軟體架構的興起是滞後于軟體開發模型的。比如瀑布模型,是用結構化的方式設計的,也就是面向過程的程式,那時候是沒有涉及到架構的概念的。

其實架構設計就放在原來的需求分析之後,軟體設計之前。因為需求分析比較偏向于業務的(一般需求來自于客戶的業務),而軟體設計是偏向技術,就是利用技術去完成需求所定義的内容。這個之間就很可能出現斷代鴻溝,因為客戶方更懂業務,需求分析是大量跟客戶做對接,而技術人員就是拿着這個需求規格說明說去實作,但是技術人員不懂業務,就可能出現一個需求規格書轉化為技術的過程會出現問題,因為各自的技術人員實作出來的東西不一樣。

是以就需要架構設計這個環節,架構師需要了解需求,然後将需求砍成多個闆塊,然後把每個闆塊去完成一部分需求,進而簡化需求。

架構師備戰(四)-軟體架構設計(一) 軟體架構風格概念

1、軟體架構相關概念

軟體架構風格概念

軟體架構風格是描述某一特定應用領域中系統組織方式的慣用模式(也叫做架構模式)。架構風格定義一個系統家族,即一個體系結構定義一個詞彙表和一組限制。詞彙表中包含一些建構和連接配接件類型,而這組限制指出系統是如何将這些建構和連接配接件組合起來的。

軟體架構概念

軟體架構為軟體系統提供了一個結構,行為和屬性的進階抽象,由構成系統的元素描述,這些元素的互相作用,指導元素內建的模式以及這些模式的限制組成。

軟體架構是項目幹系人進行交流的手段,明确了對系統實作的限制條件,決定了開發和維護組織的組織結構,制約着系統的品質屬性。

軟體架構使推理和控制的更改更加簡單,有助于循序漸進的原型設計,可以作為教育訓練的基礎。

軟體架構是可傳遞和可複用的模型,通過研究軟體架構可以預測軟體的品質。

2、軟體架構的發展曆史

架構師備戰(四)-軟體架構設計(一) 軟體架構風格概念
  • 無架構階段:主要使用彙編語言,并且基本使用指令,沒有架構的概念
  • 萌芽階段:開始做程式結構設計,做面向過程開發,比如由順序,分支,循環等結構
  • 初級階段:開始使用統一模組化語言(UML)
  • 進階階段:使用4+1視圖,做面向對象的設計了

3、軟體架構模組化

  • 結構模型(靜态):以架構的建構、連接配接件和其他概念來刻畫結構
  • 架構模型:不太側重描述結構的細節而更側重于整體的結構
  • 動态模型:系統的“大顆粒”的行為性質
  • 過程模型:建構系統的步驟和過程
  • 功能模型:由一組功能建構按層次組成,下層向上層提供服務

以上概念了解即可,不是重點

架構師備戰(四)-軟體架構設計(一) 軟體架構風格概念
  • 開發視圖:對應了UML的實作視圖,主要針對的是程式設計人員,關注的是軟體管理,也就是源代碼
  • 程序視圖:對應了UML的程序視圖,主要針對的是系統內建人員,關注的是性能的可擴充性、吞吐量等。其實就是關注的并發
  • 邏輯視圖:對應了UML的邏輯視圖,針對的是最終使用者,關注的是功能需求,也就是系統有哪些功能
  • 實體視圖:對應了UML的部署試圖,針對的是系統網絡工程人員,關注的是系統的拓撲、安裝、通信等。其實就是關注軟體到硬體的映射關系
  • 場景:對應了UML的用例視圖,展示了系統的外部人員與系統的互動

其實架構的4+1視圖也是一個化繁為簡的過程,就是從不同次元去看問題,進而簡化問題。

4、軟體架構風格(重要)

  • 軟體架構的一個核心問題是能否達到架構級的軟體複用
  • 架構風格反應了領域中衆多系統所共有的結構和語義特征,并知道如何将各個建構有效地組織成一個完整的系統
  • 架構風格定義了用于描述系統的術語表和一組指導建構系統的規則

軟體架構到底有哪些風格呢?

  • 資料流風格
    • 批處理序列、管道-過濾器。比如我們的Flink做批量流處理,實時流處理,就是資料流風格
  • 調用/傳回風格
    • 主程式/子程式、面向對象、層次結構。我們的B/S架構風格,提供一個restful接口,發送請求也就傳回。
  • 獨立建構風格
    • 程序通信、事件驅動系統(隐式調用)。事件驅動系統現在也是很多
  • 虛拟機風格
    • 解釋器、基于規則的系統。比如工作流引擎就是解釋器。比如風控系統,需要編寫大量風控規則來攔截風險交易,就是基于規則的系統。
  • 倉庫風格
    • 資料庫系統、超文本系統、黑闆系統。現在是系統肯定離不開資料庫。

這幾種架構風格不會涵蓋所有的架構風格,因為當時有些架構風格還沒産生,現在又沒有專門的歸類,是以存在不屬于這幾種風格的架構風格。

是以雖然我們有很多分類,但是我們使用時,基本都是混合使用,一個系統一般都包含多種風格。

4.1、資料流風格

架構師備戰(四)-軟體架構設計(一) 軟體架構風格概念

過濾器:對應了我們平常的函數,方法這些

管道:就是連接配接過濾器的東西,可以了解為一些調用的機制,就是管道

其實批處理和管道-過濾器的示意圖都是差不多的,隻是批處理是一般處理事後資料,一批一批的處理。并且批處理的資料必須是完整的,以整體的方式傳遞。

管道-過濾器一般是可以進行實時的流處理,一般針對單條資料,單個單個的處理。支援流式資料處理,也就是處理資料流。

一般類似Flink這樣的架構就是批流一體的處理架構,既可以批量處理資料(一般是處理事後/非實時的資料),也可以進行流式處理資料(一般是事中/實時)。

批處理序列

構件為一系列固定順序的計算單元,構件之間隻通過資料傳遞互動。每個處理步驟是一個獨立的程式,每一步必須再其前一步結束後開始。資料必須是完整的,以整體的方式傳遞。

管道-過濾器

每個構件都有一組輸入和輸出,構件讀取輸入的資料流,經過内部處理,然後産生輸出資料。

這個過程冗長是通過輸入資料流的變換或計算來完成的,包括通過計算和增加資訊以豐富資料,通過濃縮和删除以精簡資料,通過改變記錄方式以轉化資料和遞增的轉換資料等。

這裡的構件稱為過濾器,連接配接件就是資料流傳輸的管道,将一個過濾器的輸出傳到另一個過濾器的輸入。

早期編譯器就是采用在這種架構,要一步一步的處理,均可考慮采用此架構風格。因為早期代碼是一步一步往下處理,是以早期編譯器使用這種處理方式。

4.2、調用/傳回風格

調用/傳回風格是應用最為廣泛的架構風格,每一個系統都逃不開調用/傳回風格。一般都是定義一個接口,供前端調用,然後傳回資料給前端,這就是調用/傳回。是以它無處不在。

主程式/子程式

單線程控制,把問題劃分為若幹個處理步驟,構件即為主程式和子程式,子程式通常可合成為子產品。

過程調用作為互動機制,即充當連接配接件的角色。調用關系具有層次性,其語義邏輯表現為主程式的正确性取決于它滴哦安永的子程式的正确性。

面向對象

構件是對象,對象是抽象資料類型的執行個體。在抽象資料類型中,資料的表示和它們的相應操作被封裝起來,對象的行為展現在其接受和請求的動作。

連接配接件即是對象互動的方式,對象是通過函數或過程的調用來互動的。

層次結構

構件組織成一個層次結構,連接配接件通過決定層次間如何互動的協定來定義。每層為上一層提供服務,使用下一層的服務,隻能見到與自己相鄰的層。

通過層次結構,可以将大的問題分解為若幹個漸進的小問題逐漸解決,可以隐藏問題的複雜度。修改某一層,最多影響其相鄰的兩層(通常隻能影響上層)。

優點

  • 這種風格支援基于可增加抽象層的設計,允許将一個複雜問題分解為一個增量步驟序列實作。
  • 不同的層次處于不同的抽象級别,越靠近底層,抽象級别越高,越靠近頂層,抽象級别越低
  • 由于每一層最多隻影響兩層,同時隻要給鄰居層提供相同的接口,允許每層用不同的方法實作,同樣為軟體複用提供了強大的支援。

缺點

  • 并不是每個系統都可以很容易的劃分為分層的模式
  • 很難找到一個合适的,正确的層次抽象方法

分層思想

架構師備戰(四)-軟體架構設計(一) 軟體架構風格概念

是以現在我們的架構設計一般都是要分層調用的,比如背景的接口的controller(控制器層)調用service(業務層),再調用dao層(資料處理層)然後再一層一層的傳回。這就是分層的思想在裡面。

但是有些系統也不适合分層,因為分層太多了可能導緻效率,性能。是以一般我們的後端分層都是三層,再加上前端調用,前端又有MVVM模式,是以一般在3-7層。函數調用一般不會超過7層。

4.3、獨立構件風格

封裝構件的時候,保證構件的獨立性。其實就是不直接關聯呗。比如我們的消息中間件進行解耦。或者某個事件進行處理,通過事件監聽器來處理,進而降低關聯性。再比如我們系統間的調用,使用RPC來解耦,調用遠端就像調用本地一樣,也是一種解耦機制。

程序通信

構件是獨立的過程,連接配接件是消息傳遞。構件通常命名過程,雄安錫傳遞的方式可以是點對點,異步或同步方式,以及RPC【遠端過程(方法)調用】等。

事件驅動系統(隐式調用)

構件不直接調用一個過程,而是通過廣播一個或多個事件。

構件中的過程在一個或多個事件中注冊,當某個事件被出發時,系統自動調用在事件中注冊的所有過程。一個事件的出發就導緻另一個子產品中的過程調用。

這種風格中的構件時匿名的過程,它們之間互動的連接配接件往往是以過程之間的隐式調用來實作的。

優點

主要的優點是為軟體複用提供了強大的支援,為構件的維護和演化帶來了友善。

缺點

缺點是構件放棄了對系統計算的控制

4.4、虛拟機風格

一般是适用于存在自定義的場景,比如自定義風控規則,然後解釋器來解析規則代碼.

解釋器

解釋器通常包括一個完成解釋工作的解釋引擎,一個包含被解釋的代碼的存儲區,一個記錄解釋器引擎目前工作狀态的資料結構,以及一個記錄源代碼被解釋器執行的進度的資料結構。

具有解釋器風格的軟體中有含有一個虛拟機,可以仿真硬體的執行過程和一些關鍵應用。

缺點是執行效率比較低

基于規則的系統

基于規則的系統包括規則集,規則解釋器,規則/資料選擇器和工作記憶體,一般用在人工智能領域和DSS中。一般還有風控規則引擎系統,決策流引擎系統等。

4.5、倉庫風格

倉庫風格中構件分為兩種:一種是中央資料結構,儲存系統的目前狀态。另一種是獨立構件,對中央資料存儲進行操作。

其實就是有一個中心倉庫, 然後有一堆的處理部件,這些部件都對這個中心倉庫進行處理.比如我們的資料庫,其實本身就是一個資料庫系統.

資料庫系統

其實就是我們平常使用的資料庫mysql, oracle等

黑闆系統

架構師備戰(四)-軟體架構設計(一) 軟體架構風格概念

包括知識源、黑闆和控制三部分。

知識源包括如果獨立計算的不同單元,提供解決問題的知識。知識源響應黑闆的變化,也隻修改黑闆。

黑闆是一個全局資料庫,包含問題域解空間的全部狀态,是知識源互相作用的唯一媒介。知識源響應是通過黑闆狀态的變化來控制的。

黑闆系統通常應用在對于解決問題沒有确定性算法的軟體中(信号處理,問題劃分,語音識别和編譯器優化等)

其實黑闆系統看上去與資料庫系統一樣,因為就是按照資料庫系統思想去做的,是以也不奇怪.

為什麼叫黑闆系統呢, 思想就是來自現實中教學的黑闆, 它會把一個公共的資料區域, 不但作為存儲的位置, 而且作為一種資料傳遞, 控制的一種機制.

比如老師, 學生通過黑闆交換資料, 也就是老師把意見解除安裝黑闆上, 學生也把意見寫在黑闆上.是以有一些資料傳遞共享的思想在裡面.

超文本系統

構件以網狀連結方式互動連接配接,使用者可以在構件之間進行按照人類的聯想思維方式任意跳轉到相關構件。

超文本是一種非線性的網狀資訊組織方法,它以節點為基本機關,鍊作為節點之間的聯想式關聯。超文本系統通常應用在網際網路領域。

現代內建編譯環境一般采用這種結構風格。

5、小結

架構風格其實是很重要的知識,我們先了解這五種架構風格, 我們之前提到除了這物種風格之外, 還有一些沒有收錄在這幾種風格之内的, 下一次會去做一個了解. 學無止境,繼續加油!

繼續閱讀