嵌入式軟件因為硬件資源限制，可能存在驅動與應用耦合的情況，但對于大型項目，資源充裕的情況下，復雜的業(yè)務邏輯、后續(xù)擴展維護的需要，必須采用分層和模塊化思維，這種思想就是架構模式。一般分7種架構模式：
① 分層架構
② 多層架構
③ 管道 - 過濾器架構
④ 客戶端 - 服務器架構
⑤ 模型 - 視圖 - 控制器架構
⑥ 事件驅動架構
⑦ 微服務架構
其中加粗部分屬于個人覺得適合在嵌入式系統(tǒng)應用的架構(模式)，實際開發(fā)中一般是多種模式嵌套，確保軟件隔離解耦。
一、分層架構模式
最常見的架構模式就是分層架構，大部分分層架構主要由四層組成：展現(xiàn)層、業(yè)務層、持久層和數(shù)據(jù)庫層，如下圖所示：
1、上下文
復雜的系統(tǒng)都會經(jīng)歷獨立的發(fā)展和衍化系統(tǒng)各個部分的需要。出于這個原因，系統(tǒng)開發(fā)者需要對關注點進行清晰且條理分明的分離，以便系統(tǒng)的各個模塊可以獨立地開發(fā)和維護。
2、問題
軟件需要以這樣一種方式分割：各個模塊可以獨自開發(fā)和衍化，各自部分之間的交互非常少，支持可移植性、可修改性和復用性。
3、方案
為了實現(xiàn)關注點分離，分層模式將軟件分割成各個單元(稱為“層”)。每一層都是一組模塊，提供了一組高內(nèi)聚的服務。其使用必須是單向的。層將一組軟件作為一個完整的分區(qū)，每個分區(qū)暴露一個公開接口。
? 第一個概念是，每一層都有特定的角色和職責。例如，展現(xiàn)層負責處理所有的用戶界面。分層架構的這種關注點分離，讓構建高效的角色和職責非常簡單。
? 第二個概念是，分層架構模式是一個技術性的分區(qū)架構，而非一個領域性的分區(qū)架構。它們是由組件組成的，而不是領域。
? 最后一個概念是，分層架構中的每一層都被標記為封閉或者開放。封閉層意味著請求從一層移到另一層，它必須通過它正下面的這一層才能達到下面這一層的再下一層。請求不能跳過任何層。
4、弱點
分層會導致性能下降。這種模式不適合高性能應用程序，因為經(jīng)過架構中的多層來實現(xiàn)一個業(yè)務請求的效率是不高的。還會增加系統(tǒng)的前期成本和復雜性。
5、用途
我們應該將這種方式應用于小型簡單的應用程序。
點評
原文是針對互聯(lián)網(wǎng)軟件，對于嵌入式可以分為業(yè)務層、公共組件層、系統(tǒng)適配層、硬件驅動層。軟件分層思想是個基礎概念，也許在嵌入式軟件中體現(xiàn)不明顯，是因為硬件資源限制有所取舍。
二、多層模式
方案：
許多系統(tǒng)的執(zhí)行結構被組織成一系列邏輯組件分組。每個分組被稱為一個層。
1、上下文
在一個分布式部署中，通常需要將系統(tǒng)的基礎設施分到不同的子集中。
2、問題
我們?nèi)绾螌⑾到y(tǒng)分割到多個計算上獨立的執(zhí)行結構：由一些通信媒介連接的軟件和硬件組?
3、弱點
大量前期成本和復雜性。
4、用途
用在分布式系統(tǒng)中。
點評
個人能力限制，暫不明白在嵌入式軟件中的用法和使用范圍。
三、管道-過濾器架構
軟件架構中反復出現(xiàn)的一種模式是管道 - 過濾器(pipe-filter)模式。
1、上下文
許多系統(tǒng)需要轉換從輸入到輸出的離散數(shù)據(jù)流。許多類型轉換在實踐中重復出現(xiàn)，因此將其創(chuàng)建成獨立的可復用的部分，這是比較理想的。
2、問題
這些系統(tǒng)需要被分割成可復用的松耦合的組件，組件之間擁有簡單通用的交互機制。這樣它們就可以靈活地相互結合。這些通用松耦合的組件就很容易復用。獨立的組件可以并行執(zhí)行。
3、方案
這種架構中的管道構成了過濾器之間的通信通道。第一個概念是，由于性能原因，每個管道都是非定向的和點對點的，接受來自一個源的輸入并經(jīng)常直接輸出到另外一個源。
在這種模式中，有如下四種過濾器。
? producer(source)：一個過程的起點。
? transformer (map)：對一些或所有數(shù)據(jù)進行轉換。
? tester (reduce)：測試一個或多個條件。
? consumer (sink)：終點。
4、弱點
不太適合交互性的系統(tǒng)，因為它們的轉換特性。
過多的解析和反解析會導致性能損失，也會增加編寫過濾器本身的復雜性。
5、用途
管道 - 過濾器架構用于各種應用程序，特別是簡化單項處理的任務。
點評
看起來比較類似廣播與接收的模式，在無操作系統(tǒng)消息隊列機制，基于單片機裸機開發(fā)時可以使用，所有分時任務共享一個廣播隊列，接收時選擇自身感興趣的進行處理，或者對廣播消息進行刪除截斷后續(xù)操作。
四、客戶端-過濾器架構
1、上下文
有許多共享資源和服務是大量分布式的客戶端希望訪問的，希望控制訪問或服務質(zhì)量。
2、問題
通過管理一組共享資源和服務，我們可以通過分解公共服務并在單個位置或少數(shù)位置進行修改來提高可修改性和復用性。我們想要通過在將資源本身分布在多個物理服務器上的同時集中控制這些資源和服務，來提高可伸縮性和可用性。
3、方案
在客戶端 - 服務器模式中，組件和連接器具有特定的行為。
稱為“客戶端”的組件將請求發(fā)送到稱為“服務器”的組件，然后等待回復。
服務器組件接收到客戶端的請求并向其發(fā)送回復。
4、弱點
服務器會成為性能瓶頸和單點故障位置。在系統(tǒng)建成后，關于功能位置(在客戶端還是在服務器)的決策通常是復雜的而且變動成本很大。
5、用途
對于有許多組件(客戶端)發(fā)送請求到另外一些提供服務的組件(服務器)的系統(tǒng)，我們可以使用客戶端 - 服務器模式來建模這個系統(tǒng)的一部分：在線應用程序，例如電子郵件、共享文檔或銀行服務。
點評
這個好像只適合互聯(lián)網(wǎng)軟件。
五、模型-視圖-控制器架構(MVC)
1、上下文
用戶界面通常是一個交互性應用程序的最頻繁被修改的部分。用戶通常希望從不同的視角查看數(shù)據(jù)，例如柱狀圖或者餅圖。這些表示形式都應該反映數(shù)據(jù)當前的狀態(tài)。
2、問題
用戶界面功能如何獨立于應用程序功能，同時還還對用戶輸入或底層應用程序數(shù)據(jù)的更改做出響應?
當?shù)讓討贸绦驍?shù)據(jù)更改時，如何創(chuàng)建、維護和協(xié)調(diào)用戶界面的多個視圖?
3、方案
模型 - 視圖 - 控制器(model-view-controller，即 MVC)模式將應用程序功能分為以下三種類型的組件：
? 模型，包含應用程序的數(shù)據(jù)。
? 視圖，顯示部分底層數(shù)據(jù)并與用戶交互。
? 控制器，在模型和視圖之間進行中介并管理狀態(tài)更改的通知。
4、弱點
對于簡單的用戶界面，其復雜性并不值得這么做。
模型、視圖和控制器抽象可能不適用于某些用戶界面工具包。
5、用途
MVC 是網(wǎng)站或移動應用程序開發(fā)用戶界面常用的一種架構模式。
點評
這模式一般用在支持顯示的場景，底層對數(shù)據(jù)的維護管理，與界面顯示分離，這樣當業(yè)務需求、顯示部分變更對底層基礎影響較小，似乎是軟件分層模式的特例。
六、事件驅動架構
1、上下文
需要提供計算和信息資源來處理傳入的應用程序生成的獨立異步事件，這種方式可以隨著需求的增加而擴展。
2、問題
構建分布式系統(tǒng)，這個系統(tǒng)可以服務異步到達的事件相關信息，并且能從簡單小型擴展到復雜大型。
3、方案
為事件處理部署獨立的事件進程或處理器。到達的事件進入隊列。調(diào)度程序根據(jù)調(diào)度策略從隊列中拉取事件并將它們分配到合適的事件處理器。
4、弱點
性能和錯誤恢復可能是問題。
5、用途
使用這個方案的電商應用程序將工作如下：
Order Service 創(chuàng)建一個 Order，這個訂單處于待定狀態(tài)，然后發(fā)布一個OrderCreated事件。
? Customer Service 接收到這個事件并嘗試為這個 Order 扣除信用。然后發(fā)布一個 Credit Reserved 事件或者CreditLimitExceeded(超出信用限額)事件。
? Order Service 接收到 Customer Service 發(fā)送的事件并將訂單狀態(tài)更改為已核準或已取消。
點評
這個在嵌入式軟件很容易理解，所謂事件就是硬件檢測到中斷信息。嵌入式軟件基本都有體現(xiàn)這個思想，一個while死循環(huán)，等待事件觸發(fā)，比如外部按鍵中斷、串口接收中斷、或者內(nèi)部定時器超時中斷等。這種框架有益于外設擴展，理論上互不干擾。
七、微服務架構
1、上下文
部署基于服務器的企業(yè)應用程序，支持各種瀏覽器和原生移動客戶端。應用程序通過執(zhí)行業(yè)務邏輯、訪問數(shù)據(jù)庫、與其它系統(tǒng)交換信息并返回響應來處理客戶端請求。這個應用程序可能會暴露一個第三方 API。
2、問題
一體化應用程序會變得過于龐大和復雜，無法得到有效支持和部署來實現(xiàn)最優(yōu)的分布式資源利用，例如在云環(huán)境中。
3、方案
將應用程序構建成服務套件。每個服務都是獨立部署和可擴展的，擁有自己的 API 邊界。不同的服務可以用不同的編程語言編寫，管理它們自己的數(shù)據(jù)庫，由不同的團隊開發(fā)。
4、弱點
系統(tǒng)設計必須能容忍服務失敗，需要更多的系統(tǒng)監(jiān)控。服務編排和事件協(xié)作開銷比較大。
5、用途
許多使用場景都可以應用微服務架構，特別是那些涉及大量數(shù)據(jù)管道的場景。例如，一個微服務系統(tǒng)對關于一個公司的零售店銷售的報表系統(tǒng)會比較理想。數(shù)據(jù)展現(xiàn)過程的每一步都會被一個微服務處理：數(shù)據(jù)收集、清理、規(guī)范化、濃縮、聚合、報告等。
點評
在嵌入式軟件開發(fā)中，比較適合某個相對獨立的功能，在適配其基礎接口后，將一個復雜功能模塊化，外部輸入?yún)?shù)，模塊內(nèi)部執(zhí)行，結束后輸出結果或者觸發(fā)回調(diào)，該功能對外接口簡單，外部無需過多關注內(nèi)部實現(xiàn)，便于軟件解耦和維護。(轉自嵌入式系統(tǒng))
框架設計中的常用模式
模板方法模式
模板方法模式是框架中最常用的設計模式。其根本的思維是將算法由框架固定，而將算法中詳細的操作交給二次開發(fā)者達到。例如一個設備初始化的邏輯，框架代碼如下：
DownloadFPGA和InitKeyPad都是CBaseDevice定義的虛函數(shù)，二次開發(fā)者創(chuàng)建一個繼承于CBaseDevice的子類，詳細來達到這兩個接口。框架定義了調(diào)用的次序和錯誤的處理方式，二次開發(fā)者沒須關懷，也沒權決定。
文章相對比較長，字數(shù)比較多，大家可以先打開頭像關注我，之后慢慢看，///插播一條：我自己在今年年初錄制了一套還比較系統(tǒng)的入門單片機教程，想要的同學找我拿就行了免費的，私信我就可以哦~點我頭像左下角黑色字體加我也能領取哦。最近比較閑，帶做畢設，帶學生參加省級或以上比賽///
創(chuàng)建型模式
由于框架通常都波及到各種不同子類對象的創(chuàng)建，創(chuàng)建型模式是經(jīng)常運用的。例如一個繪圖軟件的框架，有一個基類定義了圖形對象的接口，基于它能夠派生出橢圓，矩形，直線各種子類。當用戶繪制一個圖形時，框架就要實例化該子類。這時候能夠用工廠方法，原型方法等等。
音訊訂閱模式
音訊訂閱模式是最常用的別離數(shù)據(jù)和界面的方式。界面開發(fā)者只須要注冊須要的數(shù)據(jù)，當數(shù)據(jù)變化時框架就會將數(shù)據(jù)“推”到界面。界面開發(fā)者能夠沒須關注數(shù)據(jù)的來源和內(nèi)部組織形式。
音訊訂閱模式最常見的問題是同步模式下怎么樣處理重入和超時。作為框架設計者，一定要考慮好這個問題。所謂重入，是二次開發(fā)者在音訊的回調(diào)函數(shù)中執(zhí)行訂閱/取消訂閱的操作，這會破壞音訊訂閱的機制。所謂超時是指二次開發(fā)者的音訊回調(diào)函數(shù)處理時長過長，導致其他音訊沒法響應。最簡略的辦法是運用異步模式，讓訂閱者和數(shù)據(jù)發(fā)布者在獨立進程/線程中運行。假如不具備此條件，則必需作為框架的重要約定，禁二次開發(fā)者產(chǎn)生此類問題。
裝飾器模式
裝飾器模式賦予了框架在后期增加功能的才能?？蚣芏x裝飾器的抽象基類，而由詳細的達到者達到，動態(tài)地添加到框架中。
舉一個游戲中的例子，圖形繪制引擎是一個獨立的模塊，假如能夠繪制人物的靜止，跑動等圖像。假如策劃決定在游戲中增加一種叫“隱身衣”的道具，要求穿著此道具的玩家在屏幕上顯示的是若有若沒的半透明圖像。應該怎么樣設計圖像引擎來適應后期的游戲升級呢?
當隱身衣被裝備后，就向圖像引擎添加一個過濾器。這是個極度簡化的例子，現(xiàn)實中的游戲引擎要比這個復雜。裝飾器模式還常見用于數(shù)據(jù)的前置和后置處理上。
框架的缺少點
一個好的框架能夠大大提高產(chǎn)品的開發(fā)效率和質(zhì)量，但也有它的缺少點。
1.框架一般都比較復雜，設計和達到一個好的框架須要相當?shù)臅r長。所以，一般獨有在框架能夠被屢次反復應用的時候合適，這時候，前提投入的老本會得到豐厚的回報。
2.框架規(guī)定了一系列的接口和規(guī)則，這雖然簡化了二次開發(fā)工作，但同時也要求二次開發(fā)者必需記住很多規(guī)定，假如違反了這些規(guī)定，就不能正常工作。但是由于框架屏蔽了大量的領域細節(jié)，相對而言，其進修老本還是大大降低了的。
3.框架的升級對已有產(chǎn)品可能會造成嚴重的影響，導致須要完整的回歸測試。對這個問題有兩個辦法。第一是對框架自身進行嚴格的測試，有必要建設完善的單元測試庫，同時開發(fā)示例項目，拿來測試框架的所有功能。第二則是運用靜態(tài)鏈接，讓已有產(chǎn)品不輕易跟隨升級。當然，假如已有產(chǎn)品有較好的回歸測試伎倆，就更好。
4.性能損失。由于框架對系統(tǒng)進行了抽象，增加了系統(tǒng)的復雜性。諸如多態(tài)這樣的伎倆運用也會普遍的降低系統(tǒng)的性能。但是從整體上來看，框架能夠保證系統(tǒng)的性能處于一個較高的水平。
下載文檔
