搞懂這幾個常見的嵌入式軟件架構(gòu)，足夠平時開發(fā)使用了！

工程師進階筆記

我是老溫，一名熱愛學習的嵌入式工程師
2 V$ z+ p! ~: O1 i關(guān)注我，一起變得更加優(yōu)秀！
嵌入式軟件因為硬件資源限制，可能存在驅(qū)動與應(yīng)用耦合的情況，但對于大型項目，資源充裕的情況下，復(fù)雜的業(yè)務(wù)邏輯、后續(xù)擴展維護的需要，必須采用分層和模塊化思維，這種思想就是架構(gòu)模式。

5 W; @8 c* ?( J7 {) g4 L市面上常見的架構(gòu)模式有以下幾種：
① 分層架構(gòu)
② 多層架構(gòu)
③ 管道 - 過濾器架構(gòu)
0 J# B- q8 t$ A6 l④ 客戶端 - 服務(wù)器架構(gòu)
7 S8 i+ f4 L, Q* Y⑤ 模型 - 視圖 - 控制器架構(gòu)
⑥ 事件驅(qū)動架構(gòu)
⑦ 微服務(wù)架構(gòu)

( A5 z; L# s, W& D) m分層架構(gòu)模式
! ~2 K! H- b6 X1 H; }" `最常見的架構(gòu)模式就是分層架構(gòu)，大部分分層架構(gòu)主要由四層組成：展現(xiàn)層、業(yè)務(wù)層、持久層和數(shù)據(jù)庫層，如下圖所示：
9 s( r' S% c+ ~/ y) V% e0 P& E
% c1 Z: E! M. n7 q; D- H
1）上下文
復(fù)雜的系統(tǒng)都會經(jīng)歷獨立的發(fā)展和衍化系統(tǒng)各個部分的需要。出于這個原因，系統(tǒng)開發(fā)者需要對關(guān)注點進行清晰且條理分明地分離，以便系統(tǒng)的各個模塊可以獨立地開發(fā)和維護。

2）問題
' k( M9 {- N  K9 v* V! C& o軟件需要以這樣一種方式分割：各個模塊可以獨自開發(fā)和衍化，各自部分之間的交互非常少，支持可移植性、可修改性和復(fù)用性。
- V$ S' d+ T, w, V' }$ y$ c( X
3）方案
9 h" F- [  A8 D- n  c% E' r0 ^1 o為了實現(xiàn)關(guān)注點分離，分層模式將軟件分割成各個單元（稱為“層”）。
& g/ k' e5 x" B' M
- ~) i: o' ^/ k; u+ E7 d# X+ N每一層都是一組模塊，提供了一組高內(nèi)聚的服務(wù)。其使用必須是單向的。將一組軟件作為一個完整的分區(qū)，每個分區(qū)暴露一個公開接口。

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

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

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

9 N1 R( c8 F) f. y+ y7 K
9 g1 B6 n) q3 Q' ^
. x7 A* p2 D" B3 o5 H
( U5 C+ Y; v  W; M" S; V9 f0 Y4）弱點
分層會導(dǎo)致性能下降。這種模式不適合高性能應(yīng)用程序，因為經(jīng)過架構(gòu)中的多層來實現(xiàn)一個業(yè)務(wù)請求的效率是不高的。還會增加系統(tǒng)的前期成本和復(fù)雜性。

5）用途
" ]: A! ~9 L8 A) n. I我們應(yīng)該將這種方式應(yīng)用于小型簡單的應(yīng)用程序。

多層模式
  D) J) I- I& L2 W0 a$ O; Z* c6 X
許多系統(tǒng)的執(zhí)行結(jié)構(gòu)被組織成一系列邏輯組件分組。每個分組被稱為一個層。

# s: y% D0 @$ M) X* ?1）上下文
在一個分布式部署中，通常需要將系統(tǒng)的基礎(chǔ)設(shè)施分到不同的子集中。

2）問題
- h/ A) }; R% B( c1 p  q# j我們?nèi)绾螌⑾到y(tǒng)分割到多個計算上獨立的執(zhí)行結(jié)構(gòu)：由一些通信媒介連接的軟件和硬件組？

3）弱點
5 l  F$ J9 b. F1 H2 K大量前期成本和復(fù)雜性。
5 _8 G( l+ I( z
4）用途
用在分布式系統(tǒng)中。
+ p0 P5 F( C1 g( B& W
管道-過濾器架構(gòu)
3 j$ J9 U2 x- E8 r* }* [) Q+ L' A軟件架構(gòu)中反復(fù)出現(xiàn)的一種模式是管道 - 過濾器（pipe-filter）模式。
3 B. j+ F+ @8 p
( k, r% ]- N! f& h$ t8 o5 i, l
2 f; H. |$ B2 g9 c0 I1）上下文
許多系統(tǒng)需要轉(zhuǎn)換從輸入到輸出的離散數(shù)據(jù)流。許多類型轉(zhuǎn)換在實踐中重復(fù)出現(xiàn)，因此將其創(chuàng)建成獨立的可復(fù)用的部分，這是比較理想的。

4 i6 e$ i# B, \0 a9 J3 \2）問題
這些系統(tǒng)需要被分割成可復(fù)用的松耦合的組件，組件之間擁有簡單通用的交互機制。這樣它們就可以靈活地相互結(jié)合。這些通用松耦合的組件就很容易復(fù)用。獨立的組件可以并行執(zhí)行。

3）方案
這種架構(gòu)中的管道構(gòu)成了過濾器之間的通信通道。第一個概念是，由于性能原因，每個管道都是非定向的和點對點的，接受來自一個源的輸入并經(jīng)常直接輸出到另外一個源。
: V( {, H2 y. \5 L+ j
. `) v; W# J  u% Q# D! ]9 i在這種模式中，有如下四種過濾器。
% Q- V' Z% B1 M! x% I% [* H; V- V? producer（source）：一個過程的起點。
? transformer (map)：對一些或所有數(shù)據(jù)進行轉(zhuǎn)換。
; f( w5 V( b# l0 z4 v" t5 U8 E# I. M? tester (reduce)：測試一個或多個條件。
/ O! l& k" ^' n* i$ W1 Z. D* l5 @? consumer (sink)：終點。

4）弱點
不太適合交互性的系統(tǒng)，因為它們的轉(zhuǎn)換特性。過多的解析和反解析會導(dǎo)致性能損失，也會增加編寫過濾器本身的復(fù)雜性。
& y6 q1 I" a2 w( Q  S! B7 ~
; P, Q8 a( a6 p; n- ~) J5）用途
! l$ F* c1 J, _; p管道 - 過濾器架構(gòu)用于各種應(yīng)用程序，特別是簡化單項處理的任務(wù)。
) z9 n9 C* Z  u" ]$ O" S6 ?
客戶端-過濾器架構(gòu)
4 M7 ^3 a, |! `, q) s' T5 s

1）上下文
有許多共享資源和服務(wù)是大量分布式的客戶端希望訪問的，希望控制訪問或服務(wù)質(zhì)量。
  n' C- H2 Y, `
2）問題
8 |4 H9 i/ y& O通過管理一組共享資源和服務(wù)，我們可以通過分解公共服務(wù)并在單個位置或少數(shù)位置進行修改來提高可修改性和復(fù)用性。我們想要通過在將資源本身分布在多個物理服務(wù)器上的同時集中控制這些資源和服務(wù)，來提高可伸縮性和可用性。

3 z5 \# E+ M6 F2 T" ?3）方案
$ Y$ ^$ ~) {* `: v$ j在客戶端 - 服務(wù)器模式中，組件和連接器具有特定的行為。稱為“客戶端”的組件將請求發(fā)送到稱為“服務(wù)器”的組件，然后等待回復(fù)。服務(wù)器組件接收到客戶端的請求并向其發(fā)送回復(fù)。

$ f$ b6 \2 A( S3 b$ a4）弱點
服務(wù)器會成為性能瓶頸和單點故障位置。在系統(tǒng)建成后，關(guān)于功能位置（在客戶端還是在服務(wù)器）的決策通常是復(fù)雜的而且變動成本很大。

6 S  e2 a3 x' b8 H5）用途
. t0 w" y- W4 f, U2 [2 q# g8 K對于有許多組件（客戶端）發(fā)送請求到另外一些提供服務(wù)的組件（服務(wù)器）的系統(tǒng)，我們可以使用客戶端 - 服務(wù)器模式來建模這個系統(tǒng)的一部分：在線應(yīng)用程序，例如電子郵件、共享文檔或銀行服務(wù)。

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

4 d* X' |! k& }" ?9 _' ]

' C# a; L% Y( d( x+ V1）上下文
用戶界面通常是一個交互性應(yīng)用程序的最頻繁被修改的部分。用戶通常希望從不同的視角查看數(shù)據(jù)，例如柱狀圖或者餅圖。這些表示形式都應(yīng)該反映數(shù)據(jù)當前的狀態(tài)。

2）問題
用戶界面功能如何獨立于應(yīng)用程序功能，同時還還對用戶輸入或底層應(yīng)用程序數(shù)據(jù)的更改做出響應(yīng)？
當?shù)讓討?yīng)用程序數(shù)據(jù)更改時，如何創(chuàng)建、維護和協(xié)調(diào)用戶界面的多個視圖？
' T( m: |: ^3 }* m: Z
3）方案
模型 - 視圖 - 控制器（model-view-controller，即 MVC）模式將應(yīng)用程序功能分為以下三種類型的組件：
" _, Y8 x- ]0 W' Y. @& u? 模型，包含應(yīng)用程序的數(shù)據(jù)。
? 視圖，顯示部分底層數(shù)據(jù)并與用戶交互。
) ^9 O; C: X2 |( L' H2 N9 P! q? 控制器，在模型和視圖之間進行中介并管理狀態(tài)更改的通知。

+ Y9 E9 B6 l  n" h, }* ^9 |5 w4）弱點
9 R7 B- O* Y1 H! V* q3 ^* a# L對于簡單的用戶界面，其復(fù)雜性并不值得這么做。
( ^" ^  M- S$ m9 b模型、視圖和控制器抽象可能不適用于某些用戶界面工具包。
& M6 d* w5 ]% R8 N! y
5）用途
MVC 是網(wǎng)站或移動應(yīng)用程序開發(fā)用戶界面常用的一種架構(gòu)模式。
5 e" Z& \5 ?% Q. O

4 K' @2 A$ {6 P2 G% ~事件驅(qū)動架構(gòu)
" q# b$ n$ H# d4 E1）上下文
需要提供計算和信息資源來處理傳入的應(yīng)用程序生成的獨立異步事件，這種方式可以隨著需求的增加而擴展。
$ H8 j% @# \' j
, z% ~# |6 l9 L% f) `; T9 d+ T2）問題
構(gòu)建分布式系統(tǒng)，這個系統(tǒng)可以服務(wù)異步到達的事件相關(guān)信息，并且能從簡單小型擴展到復(fù)雜大型。
9 h1 N4 M- B7 A
3）方案

為事件處理部署獨立的事件進程或處理器。到達的事件進入隊列。調(diào)度程序根據(jù)調(diào)度策略從隊列中拉取事件并將它們分配到合適的事件處理器。
9 _) b+ ^! j5 H3 n7 `. p
* m9 b$ J  U8 k1 C8 q$ L4）弱點
性能和錯誤恢復(fù)可能是問題。
0 V' Y0 F4 L) Y3 i/ v7 A/ r% F
5）用途
& ^0 }0 f! H! q' o使用這個方案的電商應(yīng)用程序?qū)⒐ぷ魅缦拢?br />   F8 v# y. s4 Y3 {& G7 ?% |$ T* O
Order Service 創(chuàng)建一個 Order，這個訂單處于待定狀態(tài)，然后發(fā)布一個OrderCreated事件。
4 F! \1 r) }  k. K$ q7 i. n? Customer Service 接收到這個事件并嘗試為這個 Order 扣除信用。然后發(fā)布一個Credit Reserved 事件或者CreditLimitExceeded（超出信用限額）事件。
? Order Service 接收到 Customer Service 發(fā)送的事件并將訂單狀態(tài)更改為已核準或已取消。
! J! m! a) ^; `5 e4 i/ [) z6 o
+ t# u5 ~$ W6 @- C
微服務(wù)架構(gòu)
7 L9 R* }2 H" L1 G1）上下文
部署基于服務(wù)器的企業(yè)應(yīng)用程序，支持各種瀏覽器和原生移動客戶端。應(yīng)用程序通過執(zhí)行業(yè)務(wù)邏輯、訪問數(shù)據(jù)庫、與其它系統(tǒng)交換信息并返回響應(yīng)來處理客戶端請求。這個應(yīng)用程序可能會暴露一個第三方 API。
# s2 ^2 I( B3 a$ `* [* H1 z
+ c. \6 K& Q/ I7 C# s% g* s  L2）問題
一體化應(yīng)用程序會變得過于龐大和復(fù)雜，無法得到有效支持和部署來實現(xiàn)最優(yōu)的分布式資源利用，例如在云環(huán)境中。

3）方案

將應(yīng)用程序構(gòu)建成服務(wù)套件。每個服務(wù)都是獨立部署和可擴展的，擁有自己的 API 邊界。不同的服務(wù)可以用不同的編程語言編寫，管理它們自己的數(shù)據(jù)庫，由不同的團隊開發(fā)。
* E1 ], T/ e. S- Q; m
4）弱點
系統(tǒng)設(shè)計必須能容忍服務(wù)失敗，需要更多的系統(tǒng)監(jiān)控。服務(wù)編排和事件協(xié)作開銷比較大。
: R3 a8 u- x- }6 y
' s! j: P, i4 O. u" B5）用途
許多使用場景都可以應(yīng)用微服務(wù)架構(gòu)，特別是那些涉及大量數(shù)據(jù)管道的場景。例如，一個微服務(wù)系統(tǒng)對關(guān)于一個公司的零售店銷售的報表系統(tǒng)會比較理想。數(shù)據(jù)展現(xiàn)過程的每一步都會被一個微服務(wù)處理：數(shù)據(jù)收集、清理、規(guī)范化、濃縮、聚合、報告等。

: v! L5 _) B3 [0 O# T文章來源：牛逼的工程師網(wǎng)友。


+ i; y* i3 q# I; R" p& c0 X8 O
我是老溫，一名熱愛學習的嵌入式工程師
關(guān)注我，一起變得更加優(yōu)秀！