匯總：嵌入式軟件框架設(shè)計(jì)常用模式

嵌入式軟件因?yàn)橛布Y源限制，可能存在驅(qū)動(dòng)與應(yīng)用耦合的情況，但對(duì)于大型項(xiàng)目，資源充裕的情況下，復(fù)雜的業(yè)務(wù)邏輯、后續(xù)擴(kuò)展維護(hù)的需要，必須采用分層和模塊化思維，這種思想就是架構(gòu)模式。一般分7種架構(gòu)模式：

① 分層架構(gòu)

② 多層架構(gòu)

③ 管道 - 過濾器架構(gòu)

④ 客戶端 - 服務(wù)器架構(gòu)

⑤ 模型 - 視圖 - 控制器架構(gòu)

⑥ 事件驅(qū)動(dòng)架構(gòu)

⑦ 微服務(wù)架構(gòu)

其中加粗部分屬于個(gè)人覺得適合在嵌入式系統(tǒng)應(yīng)用的架構(gòu)(模式)，實(shí)際開發(fā)中一般是多種模式嵌套，確保軟件隔離解耦。

一、分層架構(gòu)模式

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

1、上下文

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

2、問題

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

3、方案

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

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

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

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

4、弱點(diǎn)

分層會(huì)導(dǎo)致性能下降。這種模式不適合高性能應(yīng)用程序，因?yàn)榻?jīng)過架構(gòu)中的多層來實(shí)現(xiàn)一個(gè)業(yè)務(wù)請(qǐng)求的效率是不高的。還會(huì)增加系統(tǒng)的前期成本和復(fù)雜性。

5、用途

我們應(yīng)該將這種方式應(yīng)用于小型簡單的應(yīng)用程序。

點(diǎn)評(píng)

原文是針對(duì)互聯(lián)網(wǎng)軟件，對(duì)于嵌入式可以分為業(yè)務(wù)層、公共組件層、系統(tǒng)適配層、硬件驅(qū)動(dòng)層。軟件分層思想是個(gè)基礎(chǔ)概念，也許在嵌入式軟件中體現(xiàn)不明顯，是因?yàn)橛布Y源限制有所取舍。

二、多層模式

方案：

許多系統(tǒng)的執(zhí)行結(jié)構(gòu)被組織成一系列邏輯組件分組。每個(gè)分組被稱為一個(gè)層。

1、上下文

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

2、問題

我們?nèi)绾螌⑾到y(tǒng)分割到多個(gè)計(jì)算上獨(dú)立的執(zhí)行結(jié)構(gòu)：由一些通信媒介連接的軟件和硬件組?

3、弱點(diǎn)

大量前期成本和復(fù)雜性。

4、用途

用在分布式系統(tǒng)中。

點(diǎn)評(píng)

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

三、管道-過濾器架構(gòu)

軟件架構(gòu)中反復(fù)出現(xiàn)的一種模式是管道 - 過濾器(pipe-filter)模式。

1、上下文

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

2、問題

這些系統(tǒng)需要被分割成可復(fù)用的松耦合的組件，組件之間擁有簡單通用的交互機(jī)制。這樣它們就可以靈活地相互結(jié)合。這些通用松耦合的組件就很容易復(fù)用。獨(dú)立的組件可以并行執(zhí)行。

3、方案

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

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

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

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

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

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

4、弱點(diǎn)

不太適合交互性的系統(tǒng)，因?yàn)樗鼈兊霓D(zhuǎn)換特性。

過多的解析和反解析會(huì)導(dǎo)致性能損失，也會(huì)增加編寫過濾器本身的復(fù)雜性。

5、用途

管道 - 過濾器架構(gòu)用于各種應(yīng)用程序，特別是簡化單項(xiàng)處理的任務(wù)。

點(diǎn)評(píng)

看起來比較類似廣播與接收的模式，在無操作系統(tǒng)消息隊(duì)列機(jī)制，基于單片機(jī)裸機(jī)開發(fā)時(shí)可以使用，所有分時(shí)任務(wù)共享一個(gè)廣播隊(duì)列，接收時(shí)選擇自身感興趣的進(jìn)行處理，或者對(duì)廣播消息進(jìn)行刪除截?cái)嗪罄m(xù)操作。

四、客戶端-過濾器架構(gòu)

1、上下文

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

2、問題

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

3、方案

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

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

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

4、弱點(diǎn)

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

5、用途

對(duì)于有許多組件(客戶端)發(fā)送請(qǐng)求到另外一些提供服務(wù)的組件(服務(wù)器)的系統(tǒng)，我們可以使用客戶端 - 服務(wù)器模式來建模這個(gè)系統(tǒng)的一部分：在線應(yīng)用程序，例如電子郵件、共享文檔或銀行服務(wù)。

點(diǎn)評(píng)

這個(gè)好像只適合互聯(lián)網(wǎng)軟件。

五、模型-視圖-控制器架構(gòu)(MVC)

1、上下文

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

2、問題

用戶界面功能如何獨(dú)立于應(yīng)用程序功能，同時(shí)還還對(duì)用戶輸入或底層應(yīng)用程序數(shù)據(jù)的更改做出響應(yīng)?

當(dāng)?shù)讓討?yīng)用程序數(shù)據(jù)更改時(shí)，如何創(chuàng)建、維護(hù)和協(xié)調(diào)用戶界面的多個(gè)視圖?

3、方案

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

? 模型，包含應(yīng)用程序的數(shù)據(jù)。

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

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

4、弱點(diǎn)

對(duì)于簡單的用戶界面，其復(fù)雜性并不值得這么做。

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

5、用途

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

點(diǎn)評(píng)

這模式一般用在支持顯示的場(chǎng)景，底層對(duì)數(shù)據(jù)的維護(hù)管理，與界面顯示分離，這樣當(dāng)業(yè)務(wù)需求、顯示部分變更對(duì)底層基礎(chǔ)影響較小，似乎是軟件分層模式的特例。

六、事件驅(qū)動(dòng)架構(gòu)

1、上下文

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

2、問題

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

3、方案

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

4、弱點(diǎn)

性能和錯(cuò)誤恢復(fù)可能是問題。

5、用途

使用這個(gè)方案的電商應(yīng)用程序?qū)⒐ぷ魅缦拢?

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)更改為已核準(zhǔn)或已取消。

點(diǎn)評(píng)

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

七、微服務(wù)架構(gòu)

1、上下文

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

2、問題

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

3、方案

將應(yīng)用程序構(gòu)建成服務(wù)套件。每個(gè)服務(wù)都是獨(dú)立部署和可擴(kuò)展的，擁有自己的 API 邊界。不同的服務(wù)可以用不同的編程語言編寫，管理它們自己的數(shù)據(jù)庫，由不同的團(tuán)隊(duì)開發(fā)。

4、弱點(diǎn)

系統(tǒng)設(shè)計(jì)必須能容忍服務(wù)失敗，需要更多的系統(tǒng)監(jiān)控。服務(wù)編排和事件協(xié)作開銷比較大。

5、用途

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

點(diǎn)評(píng)

在嵌入式軟件開發(fā)中，比較適合某個(gè)相對(duì)獨(dú)立的功能，在適配其基礎(chǔ)接口后，將一個(gè)復(fù)雜功能模塊化，外部輸入?yún)?shù)，模塊內(nèi)部執(zhí)行，結(jié)束后輸出結(jié)果或者觸發(fā)回調(diào)，該功能對(duì)外接口簡單，外部無需過多關(guān)注內(nèi)部實(shí)現(xiàn)，便于軟件解耦和維護(hù)。(轉(zhuǎn)自嵌入式系統(tǒng))

框架設(shè)計(jì)中的常用模式

模板方法模式

模板方法模式是框架中最常用的設(shè)計(jì)模式。其根本的思維是將算法由框架固定，而將算法中詳細(xì)的操作交給二次開發(fā)者達(dá)到。例如一個(gè)設(shè)備初始化的邏輯，框架代碼如下：

DownloadFPGA和InitKeyPad都是CBaseDevice定義的虛函數(shù)，二次開發(fā)者創(chuàng)建一個(gè)繼承于CBaseDevice的子類，詳細(xì)來達(dá)到這兩個(gè)接口?？蚣芏x了調(diào)用的次序和錯(cuò)誤的處理方式，二次開發(fā)者沒須關(guān)懷，也沒權(quán)決定。

文章相對(duì)比較長，字?jǐn)?shù)比較多，大家可以先打開頭像關(guān)注我，之后慢慢看，///插播一條：我自己在今年年初錄制了一套還比較系統(tǒng)的入門單片機(jī)教程，想要的同學(xué)找我拿就行了免費(fèi)的，私信我就可以哦~點(diǎn)我頭像左下角黑色字體加我也能領(lǐng)取哦。最近比較閑，帶做畢設(shè)，帶學(xué)生參加省級(jí)或以上比賽///

創(chuàng)建型模式

由于框架通常都波及到各種不同子類對(duì)象的創(chuàng)建，創(chuàng)建型模式是經(jīng)常運(yùn)用的。例如一個(gè)繪圖軟件的框架，有一個(gè)基類定義了圖形對(duì)象的接口，基于它能夠派生出橢圓，矩形，直線各種子類。當(dāng)用戶繪制一個(gè)圖形時(shí)，框架就要實(shí)例化該子類。這時(shí)候能夠用工廠方法，原型方法等等。

音訊訂閱模式

音訊訂閱模式是最常用的別離數(shù)據(jù)和界面的方式。界面開發(fā)者只須要注冊(cè)須要的數(shù)據(jù)，當(dāng)數(shù)據(jù)變化時(shí)框架就會(huì)將數(shù)據(jù)“推”到界面。界面開發(fā)者能夠沒須關(guān)注數(shù)據(jù)的來源和內(nèi)部組織形式。

音訊訂閱模式最常見的問題是同步模式下怎么樣處理重入和超時(shí)。作為框架設(shè)計(jì)者，一定要考慮好這個(gè)問題。所謂重入，是二次開發(fā)者在音訊的回調(diào)函數(shù)中執(zhí)行訂閱/取消訂閱的操作，這會(huì)破壞音訊訂閱的機(jī)制。所謂超時(shí)是指二次開發(fā)者的音訊回調(diào)函數(shù)處理時(shí)長過長，導(dǎo)致其他音訊沒法響應(yīng)。最簡略的辦法是運(yùn)用異步模式，讓訂閱者和數(shù)據(jù)發(fā)布者在獨(dú)立進(jìn)程/線程中運(yùn)行。假如不具備此條件，則必需作為框架的重要約定，禁二次開發(fā)者產(chǎn)生此類問題。

裝飾器模式

裝飾器模式賦予了框架在后期增加功能的才能?？蚣芏x裝飾器的抽象基類，而由詳細(xì)的達(dá)到者達(dá)到，動(dòng)態(tài)地添加到框架中。

舉一個(gè)游戲中的例子，圖形繪制引擎是一個(gè)獨(dú)立的模塊，假如能夠繪制人物的靜止，跑動(dòng)等圖像。假如策劃決定在游戲中增加一種叫“隱身衣”的道具，要求穿著此道具的玩家在屏幕上顯示的是若有若沒的半透明圖像。應(yīng)該怎么樣設(shè)計(jì)圖像引擎來適應(yīng)后期的游戲升級(jí)呢?

當(dāng)隱身衣被裝備后，就向圖像引擎添加一個(gè)過濾器。這是個(gè)極度簡化的例子，現(xiàn)實(shí)中的游戲引擎要比這個(gè)復(fù)雜。裝飾器模式還常見用于數(shù)據(jù)的前置和后置處理上。

框架的缺少點(diǎn)

一個(gè)好的框架能夠大大提高產(chǎn)品的開發(fā)效率和質(zhì)量，但也有它的缺少點(diǎn)。

1.框架一般都比較復(fù)雜，設(shè)計(jì)和達(dá)到一個(gè)好的框架須要相當(dāng)?shù)臅r(shí)長。所以，一般獨(dú)有在框架能夠被屢次反復(fù)應(yīng)用的時(shí)候合適，這時(shí)候，前提投入的老本會(huì)得到豐厚的回報(bào)。

2.框架規(guī)定了一系列的接口和規(guī)則，這雖然簡化了二次開發(fā)工作，但同時(shí)也要求二次開發(fā)者必需記住很多規(guī)定，假如違反了這些規(guī)定，就不能正常工作。但是由于框架屏蔽了大量的領(lǐng)域細(xì)節(jié)，相對(duì)而言，其進(jìn)修老本還是大大降低了的。

3.框架的升級(jí)對(duì)已有產(chǎn)品可能會(huì)造成嚴(yán)重的影響，導(dǎo)致須要完整的回歸測(cè)試。對(duì)這個(gè)問題有兩個(gè)辦法。第一是對(duì)框架自身進(jìn)行嚴(yán)格的測(cè)試，有必要建設(shè)完善的單元測(cè)試庫，同時(shí)開發(fā)示例項(xiàng)目，拿來測(cè)試框架的所有功能。第二則是運(yùn)用靜態(tài)鏈接，讓已有產(chǎn)品不輕易跟隨升級(jí)。當(dāng)然，假如已有產(chǎn)品有較好的回歸測(cè)試伎倆，就更好。

4.性能損失。由于框架對(duì)系統(tǒng)進(jìn)行了抽象，增加了系統(tǒng)的復(fù)雜性。諸如多態(tài)這樣的伎倆運(yùn)用也會(huì)普遍的降低系統(tǒng)的性能。但是從整體上來看，框架能夠保證系統(tǒng)的性能處于一個(gè)較高的水平。