系列文章

一、程序員進階架構師的基礎知識【計算機基礎】
二、程序員進階架構師的基礎知識【操作系統】
三、程序員進階架構師的基礎知識【計算機網絡基礎】
四、程序員進階架構師的專業知識【軟件工程基礎】
五、程序員進階架構師的專業知識【UML建模工具】
六、程序員進階架構師的專業知識【系統分析】
七、程序員進階架構師的專業知識【系統設計】
八、程序員進階架構師的專業知識【架構設計】
九、程序員進階架構師的專業知識【架構質量及評估】
十、程序員進階架構師的專業知識【軟件測試及維護】

文章目錄

• 系列文章
• 前言
• 生命周期
• 4+1視圖
• 基于架構的軟件設計方法ABSD
• 特定領域軟件體系架構DSSA
• 架構風格
• • 數據流風格
  • 調用返回風格
  • 獨立構件風格
  • 虛擬機風格
  • 倉庫風格
  • C2風格
  • 二層/三層架構風格
  • • C/S架構
    • B/S架構
    • 多層架構優缺點
  • SOA架構
  • 微服務架構

前言

軟件架構設計主要關注軟件構件的結構、屬性、交互作用，并通過多種視圖全面描述特定系統的架構。何為構件？構件可以小到一個類，也可以是一個系統、中間件。多種視圖可以使不同角色的人員站在不同角度了解系統。本文圍繞著架構設計的生命周期、架構的設計方法以及架構的風格以及架構的質量屬性等幾個方面進行說明，描述架構設計的工作以及如何設計出高質量的架構。

生命周期

《軟件工程》中有寫到軟件開發的生命周期，架構設計同樣有生命周期，他兩之間是相互交叉、包容的,通常架構設計處于分析和詳細設計中間，也就是說對整個系統的需求以及整體結構確定后就可以對系統的架構進行設計。軟件架構設計的生命周期：

需求分析：根據需求模型構建架構模型，保證模型轉移的可追蹤性。

設計階段：分析系統的組成要素與相互關系，通過體系結構描述語言ADL和4+1視圖的描述架構。

實現階段：制定項目的組織結構，實現配置化管理，通過置頂向下逐步求精的方式完成構件開發。

構件組裝階段：根據系統的整體邏輯組裝構件，構建完整的系統。

部署階段：部署應用。

后開發階段：演化、迭代、復用。

4+1視圖

體系結構描述語言ADL目前常用的就是UML建模語言。 "4+1"視圖從5個不同的視角包括邏輯視圖、進程視圖、物理視圖、 開發視圖和場景視圖來描述系統架構。每一個視圖只關心系統的一個側面，只有5個視圖結合在一起才能反映系統架構的全部內容。

• 場景（用例）視圖： 從外部世界的角度描述系統的功能。 所有其他視圖都依靠該來指導它們，這就是將模型稱為4+1的原因。該視圖通常包含用例圖，描述和概述圖。
• 邏輯視圖：描述系統各部分的抽象描述，主要支持功能性需求。用于系統的組成部分以及各組成部分之間的交互方式。該視圖通常包含類圖，對象圖，狀態圖和協作圖。
• 進程（過程）視圖：描述系統中的進程或活動。細化到某個構件中，如果存在業務流程需要被可視化時，使用此視圖描述。進程架構需要考慮一些非功能性需求，如可用性、性能。該視圖通常包含活動圖。
• 開發視圖：描述系統的各部分如何被組織為模塊和組件。該視圖通常包含包圖和組件圖。
• 物理視圖：描述如何將邏輯視圖、進程（過程）視圖、開發視圖中所展示的抽象部分如何映射到最終部署的系統中。該視圖通常包含部署圖。

基于架構的軟件設計方法ABSD

ABSD方法由構成體系結構的（商業、質量）非功能需求和功能需求驅動的。ABSD方法采用視角與視圖來描述軟件架構，采用用例來描述功能需求，采用質量場景來描述質量需求。
使用ABSD方法三個基礎：

• 第一個基礎是功能的分解。在功能分解中，ABSD方法使用模塊的內聚和耦合技術。
• 第二個基礎是通過選擇架構風格來實現質量和商業需求。
• 第三個基礎是軟件模板的使用。設計的過程中可以采用之前的軟件模板進行復用。
  每個方法論都有對應的開發模型，比如結構化開發對應瀑布模型，面向對象開發方法對應噴泉模型。ABSD方法的開發模型是ABSDM，ABSDM把整個基于軟件體系結構的過程分為體系結構需求、設計、文檔化、復審、演化等6個子過程，得到細化，知道能產生構件和類。模型如下：
  
  其中需求包括功能性需求和非功能性需求；體系結構文檔化過程的主要輸出結果是體系結構規格說明和測試體系結構需求的質量設計說明書這兩個文檔；體系結構復審是一個迭代過程。目的是標識出潛在的風險盡早發現體系結構設計中的缺陷和錯誤。在一個主版本的軟件體系結構設計之后，要安排一次由外部人員(用戶代表和領域專家)參加的復審。下圖為具體過程：
  

特定領域軟件體系架構DSSA

特定領域軟件架構是在一個特定應用領域中，為一組應用提供組織結構參考的標準軟件體系結構。
DSSA通常是一個具有三個層次的系統模型，包括領域開發環境(領域架構師)、領域特定應用開發環境(應用工程師)和應用執行環境(操作員)。其基本活動為：

• 領域分析：獲得領域模型。領域模型描述領域中系統之間共同的需求，即領域需求。
• 領域設計：獲得特定領域軟件架構。DSSA描述領域模型中表示需求的解決方案。
• 領域實現：依據領域模型和DSSA開發組織可重用信息，并對基礎軟件架構進行實現。

其中參與角色有:領域專家、領域分析人員、領域設計人員、領域實現人員。

架構風格

軟件體系結構風格是描述某一特定應用領域中系統組織方式的慣用模式。從建筑角度來說有中式風格、英式風格、哥特式風格等，軟件角度同樣如此，同一領域的軟件在體系結構中也有多種風格。
軟件體系結構風格中定義了一個系統家族，每個風格有一個詞匯表和一組約束。詞匯表中包含一些構件和連接件類型。約束指出系統是如何將這些構件和連接件組合起來的。
體系結構風格反映了領域中眾多系統所共有的結構和語義特性，并指導如何將各個模塊和子系統有效地組織成一個完整的系統。

數據流風格

所有的數據按照流的形式在執行過程中前進，不存在結構的反復和重構，在流動過程中，數據經過序列間的數據處理組件進行處理，然后將處理結果向后傳送，最后進行輸出。就像工廠中的汽車流水線一樣，汽車零部件在流水線的各個節點上被加工，最終輸出所需要的結果(一部完整的汽車)。
數據流動方式：

• 數據自由流動：構件之間隨意傳輸數據，這樣的流動方式可能會出現死循環。
• 數據近線性流動：構件之間只向后傳輸數據。
• 數據有限循環流動：構件之間傳輸數據可以存在2、3次的反復流動。
  

數據流風格中包含兩種風格：

• 批處理：批處理風格的每一步處理都是獨立的，并且每一步是順序執行的。只有當前一步處理完，后一步處理才能開始。數據必須是完整的，以整體的方式傳遞。如日志分析、計費程序等。
• 管道過濾器：與批處理一樣都是順序執行。每個構件都有一組輸入和輸出，前一個輸出是后一個輸入，增量傳送。如傳統的編譯器、 UNIX管道等。下圖為編譯器執行
  

批處理管道過濾器

整體數據傳送	增量
構件粒度大	構件粒度小
延遲高、實時性差	實時性好
無并發	可并發

調用返回風格

系統中采用了調用與返回機制，開發中用到最多的風格。調用返回風格中包含三種風格：

• 主程序/子程序：主程序發起調用，子程序返回結果，主程序的正確性取決于它調用的子程序的正確性。如開發語言。
• 面向對象：數據的表示和它們的相應操作被封裝起來，對象的行為體現在其接受和請求的動作中。對象具有封裝性，一個對象的改變不會影響其他對象。如面向對象開發語言。
• 分層：只能見到與自己鄰接的層，每層為上一層提供服務，使用下一層的服務，修改某一層，最多影響其相鄰的上下兩層(通常只能影響上層)。上層必須知道下層的身份，不能調整層次之間的順序。如TCP/IP協議，B/S、 C/S、MVC等。

獨立構件風格

獨立構件風格主要包括:進程通信和事件驅動。

• 進程通信：進程間消息傳遞的方式可以是點對點、異步或同步方式，以及遠程過程(方法)調用等。
• 事件驅動：當某個事件被觸發時，系統自動調用注冊在這個事件中的所有過程。這是一種隱式調用的方式，優點是為軟件復用提供了強大的支持，為構件的維護和演化帶來了方便，其缺點是構件放棄了對系統計算的控制。如斷點調試、新聞，公眾號等的訂閱信息。
  
  事件驅動特點：

特點描述

分離的交互	事件發布者并不會意識到事件訂閱者的存在
一對多通信	采用發布/訂閱消息傳遞，一個特定時間可以影響多個訂閱者
基于事件的觸發器	由事件觸發過程調用
異步	支持異步操作

虛擬機風格

虛擬機風格主要有解釋器風格和規則系統風格兩種

• 解釋器：解釋器通常包括一個完成解釋工作的解釋引擎、一個將被解釋的代碼的存儲區、一個記錄解釋引擎當前工作狀態的數據結構，以及一個源代碼被解釋執行進度的數據結構。缺點是執行效率比較低。如JVM。傳統編譯器會產生可執行文件而解釋器不會。
  

• 規則系統：基于規則的系統包括規則集、規則解釋器、規則選擇器和工作內存。一般用在人工智能領域和DSS中。
  

倉庫風格

倉庫風格包含一個數據倉庫和若干其他構件，數據倉庫位于該體系結構的中心，其他構件訪問該數據倉庫并對其數據進行增刪改等操作。主要有數據庫系統、黑板和超文本系統三種風格。

• 數據庫系統：構件分為中央共享數據源、獨立處理單元。構件控制中央共享數據。如IDE集成開發環境。

• 黑板：黑板系統包括知識源、黑板和控制三個部分。

  • 知識源包括若干獨立計算的不同單元，提供解決問題的知識。知識源響應黑板的變化，也只修改黑板。
  • 黑板是一個全局數據庫，包含問題域解空間的全部狀態，是知識源相互作用的唯一媒介;
  • 知識源響應是通過黑板狀態的變化來控制的。
    

  黑板系統通常應用在對于解決問題沒有確定性算法的軟件中。如語音識別，信號處理。

• 超文本系統：超文本系統通常應用在靜態頁面中。

C2風格

C2體系結構風格屬于一個分層結構，通過連接件綁定在一起按照一組規則運作的并行構件網絡。C2風格中的系統組織規則如下：

系統中的構件和連接件都有一個頂部和一個底部。

構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部。而構件與構件之間的直接連接是不允許的。

—個連接件可以和任意數目的其他構件和連接件連接。

當兩個連接件進行直接連接時，必須由其中一個的底部到另一個的頂部。

二層/三層架構風格

C/S架構

二層 C/S 架構由客戶機和數據庫服務器組成，客戶機直接與數據庫服務器交互。主要缺點有：

服務器的負荷太重，難以管理大量的客戶機，系統的性能容易變壞。

數據安全性不好。因為客戶端程序可以直接訪問數據庫服務器，那么，在客戶端計算機上的其他程序也可想辦法訪問數據庫服務器，從而使數據庫的安全性受到威脅。

與二層C/S架構相比，在三層 C/S 架構中增加了應用服務器，可以使整個應用邏輯駐留在應用服務器上，而只有表現層在客戶機上。三層C/S 結構將應用功能分成表示層、功能層和數據層三個部分。

• 表示層是應用的用戶接口部分，它擔負著用戶與應用間的對話功能。它用于檢查用戶從鍵盤等輸入的數據，并顯示應用輸出的數據。在變更用戶接口時，只需改寫顯示控制和數據檢查程序，而不影響其他兩層。檢查的內容也只限于數據的形式和取值的范圍，不包括有關業務本身的處理邏輯。
• 功能層相當于應用的本體，它是將具體的業務處理邏輯編入程序中。而處理所需的數據則要從表示層或數據層取得。表示層和功能層之間的數據交往要盡可能簡潔。
• 數據層就是數據庫管理系統，負責管理對數據庫數據的讀寫。數據庫管理系統必須能迅速執行大量數據的更新和檢索。因此，一般從功能層傳送到數據層的要求大都使用 SQL 語言。

與二層C/S架構相比，三層 C/S 架構具有以下優點：

允許合理的劃分三層的功能，在邏輯上保持相對獨立性，從而使整個系統的邏輯結構更為清晰，能提高系統的可維護性和可擴展性。

允許更靈活的、有效的選用相應的平臺和硬件系統，使之在處理負荷能力上與處理特性上分別適應于清晰的三層架構上，并且這些平臺可以具有良好的升級性和開放性。

系統的各層可以并行開發并且可以選擇適合各自的開發語言，使之能并行高效的開發達到較高的性價比，對每一層處理邏輯的開發和維護也會更容易些。

利用功能層可以隔開表示層和數據層，未授權的表示層用戶難以繞過功能層利用數據庫工具或非法的黑客手段訪問數據層，為嚴格的安全管理奠定了基礎。

B/S架構

B/S架構是三層 C/S架構的一種實現方式，其具體結構為“瀏覽器/web服務器/數據庫服務器”。其特點為：

B/S 架構主要是利用不斷成熟的 WWW 瀏覽器技術，結合瀏覽器的多種腳本語言，用通用瀏覽器就實現了原來需要復雜的專用軟件才能實現的強大功能，并節約了開發成本。

在 B/S 模式的計算機應用系統中，應用(程序)在一定程度上具有集中特征。在 B/S 結構中，除了數據庫服務器外，應用程序以網頁形式存放于 Web 服務器上，用戶運行某個應用程序時只需在客戶端上的瀏覽器中鍵入相應的網址，調用 Web 服務器上的應用程序并對數據庫進行操作完成相應的數據處理工作，最后將結果通過瀏覽器顯示給用戶。

基于 B/S 架構的軟件，系統安裝、修改和維護全在服務器端解決。用戶在使用系統時，僅需要一個瀏覽器就可運行全部的模塊，真正達到了“零客戶端”的功能，很容易在運行時自動升級。

多層架構優缺點

優點缺點

開發人員可以只關注整個結構中的其中某一層	嚴格的分層可能導致性能問題，具體取決于層數
可以很容易的用新的實現來替換原有層次的實現	建立清晰的分層架構并不總是很容易
可以降低層與層之間的依賴
有利于標準化
利于各層邏輯的復用
擴展性強。不同層負責不同的層面
安全性高。用戶端只能通過邏輯層來訪問數據層，減少了入口點，把很多危險的系統功能都屏蔽了
項目結構更清楚，分工更明確，有利于后期的維護和升級

SOA架構

SOA是一個組件模型，它將應用程序的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實現服務的硬件平臺、操作系統和編程語言。這使在系統中構建的服務可以有統一和通用的方式進行交互。
服務總線ESB是SOA的一種實現方式，ESB在面向服務的架構中起到的是總線作用，將各種服務進行連接與整合，其功能如下：

• 描述服務的元數據和服務注冊管理。
• 在服務請求者和提供者之間傳遞數據，以及對這些數據進行轉換的能力，并支持由實踐中總結出來的一些模式如同步模式、異步模式等。
• 發現、路由、匹配和選擇的能力，以支持服務之間的動態交互，解耦服務請求者和服務提供者。高級一些的能力包括對安全的支持、服務質量保證、可管理性和負載平衡等。

SOA架構中的關鍵技術:

• SOAP：簡單對象訪問協議，Simple Object Access Protocol。
• WSDL：Web服務描述語言，Web Services Description Language。
• UDDI：統一描述、發現和集成，Universal Description Discovery and Integration。

WSDL用來描述服務，UDDI用來注冊和查找服務，而SOAP作為傳輸層，用來在消費者和服務者之間傳送消息，一個消費者可以在UDDI注 冊表查找服務，取得服務的WSDL描述，然后通過SOAP來調用該服務。

微服務架構

微服務是一種架構風格，將單體應用劃分成一組小的服務，服務之間相互協作實現業務功能，每個服務運行在獨立的進程中，服務間采用輕量級的通信機制協作(通常是HTTP/JSON)，每個服務圍繞業務能力進行構建，并且 能夠通過自動化機制獨立地部署。 微服務中很少有集中式的服務管理，每個服務可以使用不同的語言開發，使 用不同的存儲技術。

微服務中的基本組件：

• 服務描述。常用的服務描述方式包括RESTful API、XML配置和IDL文件三種。
• 注冊中心。服務者發布服務，消費者訂閱服務。返回服務列表、通知變更。
• 服務框架。通信協議、數據傳輸方式等。
• 服務監控。指標收集(請求耗時、每秒服務請求量等)、數據展示。
• 服務追蹤。追蹤服務經過的鏈路，以便進行追蹤與故障定位。
• 服務治理。節點管理、負載均衡、制定服務路由規則、服務容錯等。

微服務優缺點

優點缺點

每個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。	很難在不采用分布式事務的情況下跨服務實現功能。
微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。	測試工作更加困難。
微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。	跨服務實現要求團隊之間的緊密協作。
微服務能使用不同的語言開發。	部署復雜。
去中心化。每個微服務都有自己的存儲能力，可以有自己的數據庫。也可以有統一數據庫。

總結

以上是生活随笔為你收集整理的八、软考·系统架构师——架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。