嵌入式軟件因為硬件資源限制，可能存在驅動與應用耦合的情況，但對于大型項目，資源充裕的情況下，復雜的業務邏輯、后續擴展維護的需要，必須采用分層和模塊化思維，這種思想就是架構模式。一般分7種架構模式：

①分層架構

②多層架構

③管道 - 過濾器架構

④客戶端 - 服務器架構

⑤模型 - 視圖 - 控制器架構

⑥事件驅動架構

⑦微服務架構

其中加粗部分屬于個人覺得適合在嵌入式系統應用的架構（模式），實際開發中一般是多種模式嵌套，確保軟件隔離解耦。

一、分層架構模式

最常見的架構模式就是分層架構，大部分分層架構主要由四層組成：展現層、業務層、持久層和數據庫層，如下圖所示：

1、上下文

復雜的系統都會經歷獨立的發展和衍化系統各個部分的需要。出于這個原因，系統開發者需要對關注點進行清晰且條理分明的分離，以便系統的各個模塊可以獨立地開發和維護。

2、問題

軟件需要以這樣一種方式分割：各個模塊可以獨自開發和衍化，各自部分之間的交互非常少，支持可移植性、可修改性和復用性。

3、方案

為了實現關注點分離，分層模式將軟件分割成各個單元（稱為“層”）。每一層都是一組模塊，提供了一組高內聚的服務。其使用必須是單向的。層將一組軟件作為一個完整的分區，每個分區暴露一個公開接口。

? 第一個概念是，每一層都有特定的角色和職責。例如，展現層負責處理所有的用戶界面。分層架構的這種關注點分離，讓構建高效的角色和職責非常簡單。

?第二個概念是，分層架構模式是一個技術性的分區架構，而非一個領域性的分區架構。它們是由組件組成的，而不是領域。

?最后一個概念是，分層架構中的每一層都被標記為封閉或者開放。封閉層意味著請求從一層移到另一層，它必須通過它正下面的這一層才能達到下面這一層的再下一層。請求不能跳過任何層。

4、弱點

分層會導致性能下降。這種模式不適合高性能應用程序，因為經過架構中的多層來實現一個業務請求的效率是不高的。還會增加系統的前期成本和復雜性。

5、用途

我們應該將這種方式應用于小型簡單的應用程序。

點評

原文是針對互聯網軟件，對于嵌入式可以分為業務層、公共組件層、系統適配層、硬件驅動層。軟件分層思想是個基礎概念，也許在嵌入式軟件中體現不明顯，是因為硬件資源限制有所取舍。

二、多層模式

方案：

許多系統的執行結構被組織成一系列邏輯組件分組。每個分組被稱為一個層。

1、上下文

在一個分布式部署中，通常需要將系統的基礎設施分到不同的子集中。

2、問題

我們如何將系統分割到多個計算上獨立的執行結構：由一些通信媒介連接的軟件和硬件組？

3、弱點

大量前期成本和復雜性。

4、用途

用在分布式系統中。

點評

個人能力限制，暫不明白在嵌入式軟件中的用法和使用范圍。

三、管道-過濾器架構

軟件架構中反復出現的一種模式是管道 - 過濾器（pipe-filter）模式。

1、上下文

許多系統需要轉換從輸入到輸出的離散數據流。許多類型轉換在實踐中重復出現，因此將其創建成獨立的可復用的部分，這是比較理想的。

2、問題

這些系統需要被分割成可復用的松耦合的組件，組件之間擁有簡單通用的交互機制。這樣它們就可以靈活地相互結合。這些通用松耦合的組件就很容易復用。獨立的組件可以并行執行。

3、方案

這種架構中的管道構成了過濾器之間的通信通道。第一個概念是，由于性能原因，每個管道都是非定向的和點對點的，接受來自一個源的輸入并經常直接輸出到另外一個源。

在這種模式中，有如下四種過濾器。

? producer（source）：一個過程的起點。

? transformer (map)：對一些或所有數據進行轉換。

? tester (reduce)：測試一個或多個條件。

? consumer (sink)：終點。

4、弱點

不太適合交互性的系統，因為它們的轉換特性。

過多的解析和反解析會導致性能損失，也會增加編寫過濾器本身的復雜性。

5、用途

管道 - 過濾器架構用于各種應用程序，特別是簡化單項處理的任務。

點評

看起來比較類似廣播與接收的模式，在無操作系統消息隊列機制，基于單片機裸機開發時可以使用，所有分時任務共享一個廣播隊列，接收時選擇自身感興趣的進行處理，或者對廣播消息進行刪除截斷后續操作。

四、客戶端-過濾器架構

1、上下文

有許多共享資源和服務是大量分布式的客戶端希望訪問的，希望控制訪問或服務質量。

2、問題

通過管理一組共享資源和服務，我們可以通過分解公共服務并在單個位置或少數位置進行修改來提高可修改性和復用性。我們想要通過在將資源本身分布在多個物理服務器上的同時集中控制這些資源和服務，來提高可伸縮性和可用性。

3、方案

在客戶端 - 服務器模式中，組件和連接器具有特定的行為。

稱為“客戶端”的組件將請求發送到稱為“服務器”的組件，然后等待回復。

服務器組件接收到客戶端的請求并向其發送回復。

4、弱點

服務器會成為性能瓶頸和單點故障位置。在系統建成后，關于功能位置（在客戶端還是在服務器）的決策通常是復雜的而且變動成本很大。

5、用途

對于有許多組件（客戶端）發送請求到另外一些提供服務的組件（服務器）的系統，我們可以使用客戶端 - 服務器模式來建模這個系統的一部分：在線應用程序，例如電子郵件、共享文檔或銀行服務。

點評

這個好像只適合互聯網軟件。

五、模型-視圖-控制器架構（MVC）

1、上下文

用戶界面通常是一個交互性應用程序的最頻繁被修改的部分。用戶通常希望從不同的視角查看數據，例如柱狀圖或者餅圖。這些表示形式都應該反映數據當前的狀態。

2、問題

用戶界面功能如何獨立于應用程序功能，同時還還對用戶輸入或底層應用程序數據的更改做出響應？

當底層應用程序數據更改時，如何創建、維護和協調用戶界面的多個視圖？

3、方案

模型 - 視圖 - 控制器（model-view-controller，即 MVC）模式將應用程序功能分為以下三種類型的組件：

?模型，包含應用程序的數據。

?視圖，顯示部分底層數據并與用戶交互。

?控制器，在模型和視圖之間進行中介并管理狀態更改的通知。

4、弱點

對于簡單的用戶界面，其復雜性并不值得這么做。

模型、視圖和控制器抽象可能不適用于某些用戶界面工具包。

5、用途

MVC 是網站或移動應用程序開發用戶界面常用的一種架構模式。

點評

這模式一般用在支持顯示的場景，底層對數據的維護管理，與界面顯示分離，這樣當業務需求、顯示部分變更對底層基礎影響較小，似乎是軟件分層模式的特例。

六、事件驅動架構

1、上下文

需要提供計算和信息資源來處理傳入的應用程序生成的獨立異步事件，這種方式可以隨著需求的增加而擴展。

2、問題

構建分布式系統，這個系統可以服務異步到達的事件相關信息，并且能從簡單小型擴展到復雜大型。

3、方案

為事件處理部署獨立的事件進程或處理器。到達的事件進入隊列。調度程序根據調度策略從隊列中拉取事件并將它們分配到合適的事件處理器。

4、弱點

性能和錯誤恢復可能是問題。

5、用途

使用這個方案的電商應用程序將工作如下：

Order Service 創建一個 Order，這個訂單處于待定狀態，然后發布一個OrderCreated事件。

? Customer Service 接收到這個事件并嘗試為這個 Order 扣除信用。然后發布一個 Credit Reserved 事件或者CreditLimitExceeded（超出信用限額）事件。

? Order Service 接收到 Customer Service 發送的事件并將訂單狀態更改為已核準或已取消。

點評

這個在嵌入式軟件很容易理解，所謂事件就是硬件檢測到中斷信息。嵌入式軟件基本都有體現這個思想，一個while死循環，等待事件觸發，比如外部按鍵中斷、串口接收中斷、或者內部定時器超時中斷等。這種框架有益于外設擴展，理論上互不干擾。

七、微服務架構

1、上下文

部署基于服務器的企業應用程序，支持各種瀏覽器和原生移動客戶端。應用程序通過執行業務邏輯、訪問數據庫、與其它系統交換信息并返回響應來處理客戶端請求。這個應用程序可能會暴露一個第三方 API。

2、問題

一體化應用程序會變得過于龐大和復雜，無法得到有效支持和部署來實現最優的分布式資源利用，例如在云環境中。

3、方案

將應用程序構建成服務套件。每個服務都是獨立部署和可擴展的，擁有自己的 API 邊界。不同的服務可以用不同的編程語言編寫，管理它們自己的數據庫，由不同的團隊開發。

4、弱點

系統設計必須能容忍服務失敗，需要更多的系統監控。服務編排和事件協作開銷比較大。

5、用途

許多使用場景都可以應用微服務架構，特別是那些涉及大量數據管道的場景。例如，一個微服務系統對關于一個公司的零售店銷售的報表系統會比較理想。數據展現過程的每一步都會被一個微服務處理：數據收集、清理、規范化、濃縮、聚合、報告等。

點評

在嵌入式軟件開發中，比較適合某個相對獨立的功能，在適配其基礎接口后，將一個復雜功能模塊化，外部輸入參數，模塊內部執行，結束后輸出結果或者觸發回調，該功能對外接口簡單，外部無需過多關注內部實現，便于軟件解耦和維護。（轉自嵌入式系統）