幾種適合嵌入式軟件的架構模式

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

市面上常見(jiàn)的架構模式有以下幾種：

· 分層架構

· 多層架構

· 管道 - 過(guò)濾器架構

· 客戶(hù)端 - 服務(wù)器架構

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

· 事件驅動(dòng)架構

· 微服務(wù)架構

其中加粗部分屬于適合在嵌入式系統應用的架構（模式），實(shí)際開(kāi)發(fā)中一般是多種模式嵌套，確保軟件隔離解耦。

分層架構模式

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

1、上下文

復雜的系統都會(huì )經(jīng)歷獨立的發(fā)展和衍化系統各個(gè)部分的需要。出于這個(gè)原因，系統開(kāi)發(fā)者需要對關(guān)注點(diǎn)進(jìn)行清晰且條理分明地分離，以便系統的各個(gè)模塊可以獨立地開(kāi)發(fā)和維護。

2、問(wèn)題

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

3、方案

為了實(shí)現關(guān)注點(diǎn)分離，分層模式將軟件分割成各個(gè)單元（稱(chēng)為“層”）。每一層都是一組模塊，提供了一組高內聚的服務(wù)。其使用必須是單向的。將一組軟件作為一個(gè)完整的分區，每個(gè)分區暴露一個(gè)公開(kāi)接口。

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

? 第二個(gè)概念是，分層架構模式是一個(gè)技術(shù)性的分區架構，而非一個(gè)領(lǐng)域性的分區架構。它們是由組件組成的，而不是領(lǐng)域。

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

4、弱點(diǎn)

分層會(huì )導致性能下降。這種模式不適合高性能應用程序，因為經(jīng)過(guò)架構中的多層來(lái)實(shí)現一個(gè)業(yè)務(wù)請求的效率是不高的。還會(huì )增加系統的前期成本和復雜性。

5、用途

我們應該將這種方式應用于小型簡(jiǎn)單的應用程序。

多層模式

許多系統的執行結構被組織成一系列邏輯組件分組。每個(gè)分組被稱(chēng)為一個(gè)層。

1、上下文

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

2、問(wèn)題

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

3、弱點(diǎn)

大量前期成本和復雜性。

4、用途

用在分布式系統中。

管道-過(guò)濾器架構

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

1、上下文

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

2、問(wèn)題

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

3、方案

這種架構中的管道構成了過(guò)濾器之間的通信通道。第一個(gè)概念是，由于性能原因，每個(gè)管道都是非定向的和點(diǎn)對點(diǎn)的，接受來(lái)自一個(gè)源的輸入并經(jīng)常直接輸出到另外一個(gè)源。

在這種模式中，有如下四種過(guò)濾器。

? producer（source）：一個(gè)過(guò)程的起點(diǎn)。

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

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

? consumer (sink)：終點(diǎn)。

4、弱點(diǎn)

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

過(guò)多的解析和反解析會(huì )導致性能損失，也會(huì )增加編寫(xiě)過(guò)濾器本身的復雜性。

5、用途

管道 - 過(guò)濾器架構用于各種應用程序，特別是簡(jiǎn)化單項處理的任務(wù)。

客戶(hù)端-過(guò)濾器架構

1、上下文

有許多共享資源和服務(wù)是大量分布式的客戶(hù)端希望訪(fǎng)問(wèn)的，希望控制訪(fǎng)問(wèn)或服務(wù)質(zhì)量。

2、問(wèn)題

通過(guò)管理一組共享資源和服務(wù)，我們可以通過(guò)分解公共服務(wù)并在單個(gè)位置或少數位置進(jìn)行修改來(lái)提高可修改性和復用性。我們想要通過(guò)在將資源本身分布在多個(gè)物理服務(wù)器上的同時(shí)集中控制這些資源和服務(wù)，來(lái)提高可伸縮性和可用性。

3、方案

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

稱(chēng)為“客戶(hù)端”的組件將請求發(fā)送到稱(chēng)為“服務(wù)器”的組件，然后等待回復。

服務(wù)器組件接收到客戶(hù)端的請求并向其發(fā)送回復。

4、弱點(diǎn)

服務(wù)器會(huì )成為性能瓶頸和單點(diǎn)故障位置。在系統建成后，關(guān)于功能位置（在客戶(hù)端還是在服務(wù)器）的決策通常是復雜的而且變動(dòng)成本很大。

5、用途

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

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

1、上下文

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

2、問(wèn)題

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

當底層應用程序數據更改時(shí)，如何創(chuàng )建、維護和協(xié)調用戶(hù)界面的多個(gè)視圖？

3、方案

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

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

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

? 控制器，在模型和視圖之間進(jìn)行中介并管理狀態(tài)更改的通知。

4、弱點(diǎn)

對于簡(jiǎn)單的用戶(hù)界面，其復雜性并不值得這么做。

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

5、用途

MVC 是網(wǎng)站或移動(dòng)應用程序開(kāi)發(fā)用戶(hù)界面常用的一種架構模式。

事件驅動(dòng)架構

1、上下文

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

2、問(wèn)題

構建分布式系統，這個(gè)系統可以服務(wù)異步到達的事件相關(guān)信息，并且能從簡(jiǎn)單小型擴展到復雜大型。

3、方案

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

4、弱點(diǎn)

性能和錯誤恢復可能是問(wèn)題。

5、用途

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

Order Service 創(chuàng )建一個(gè) Order，這個(gè)訂單處于待定狀態(tài)，然后發(fā)布一個(gè)OrderCreated事件。

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

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

微服務(wù)架構

1、上下文

部署基于服務(wù)器的企業(yè)應用程序，支持各種瀏覽器和原生移動(dòng)客戶(hù)端。應用程序通過(guò)執行業(yè)務(wù)邏輯、訪(fǎng)問(wèn)數據庫、與其它系統交換信息并返回響應來(lái)處理客戶(hù)端請求。這個(gè)應用程序可能會(huì )暴露一個(gè)第三方 API。

2、問(wèn)題

一體化應用程序會(huì )變得過(guò)于龐大和復雜，無(wú)法得到有效支持和部署來(lái)實(shí)現最優(yōu)的分布式資源利用，例如在云環(huán)境中。

3、方案

將應用程序構建成服務(wù)套件。每個(gè)服務(wù)都是獨立部署和可擴展的，擁有自己的 API 邊界。不同的服務(wù)可以用不同的編程語(yǔ)言編寫(xiě)，管理它們自己的數據庫，由不同的團隊開(kāi)發(fā)。

4、弱點(diǎn)

系統設計必須能容忍服務(wù)失敗，需要更多的系統監控。服務(wù)編排和事件協(xié)作開(kāi)銷(xiāo)比較大。

5、用途

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

聲明：本文素材來(lái)源網(wǎng)絡(luò )，版權歸原作者所有。如涉及作品版權問(wèn)題，請與我聯(lián)系刪除。