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

工程師進(jìn)階筆記

我是老溫，一名熱愛學(xué)習(xí)的嵌入式工程師
- M. Y, e1 B; B8 c! n. K2 n關(guān)注我，一起變得更加優(yōu)秀！
. K7 ]  ]/ [7 `嵌入式軟件因?yàn)橛布�資源限制，可能存在驅(qū)動(dòng)與應(yīng)用耦合的情況，但對(duì)于大型項(xiàng)目，資源充裕的情況下，復(fù)雜的業(yè)務(wù)邏輯、后續(xù)擴(kuò)展維護(hù)的需要，必須采用分層和模塊化思維，這種思想就是架構(gòu)模式。
% W5 X: o+ L( e" h; Q
0 B9 G1 j- T/ b: k市面上常見的架構(gòu)模式有以下幾種：
① 分層架構(gòu)
② 多層架構(gòu)
③ 管道 - 過濾器架構(gòu)
④ 客戶端 - 服務(wù)器架構(gòu)
7 R3 H$ e( n2 v; E3 t⑤ 模型 - 視圖 - 控制器架構(gòu)
⑥ 事件驅(qū)動(dòng)架構(gòu)
' H0 b6 ^- K+ M, ^/ w⑦ 微服務(wù)架構(gòu)

分層架構(gòu)模式
4 O! ^( @0 P. |$ V; X, ~1 P最常見的架構(gòu)模式就是分層架構(gòu)，大部分分層架構(gòu)主要由四層組成：展現(xiàn)層、業(yè)務(wù)層、持久層和數(shù)據(jù)庫層，如下圖所示：

, z+ n* J6 Q& d% w# K7 w
1 s7 f  v' x* w7 T5 }7 y1）上下文
) p; E. G/ _( Y2 e2 J7 p復(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ù)。
; J8 [& i" t6 {; O/ v2 q7 Q
2）問題
- i! ?6 S4 S; i3 z3 `/ s軟件需要以這樣一種方式分割：各個(gè)模塊可以獨(dú)自開發(fā)和衍化，各自部分之間的交互非常少，支持可移植性、可修改性和復(fù)用性。
' R/ K1 l- D  L& j
3）方案
% D# A2 C9 ?# n為了實(shí)現(xiàn)關(guān)注點(diǎn)分離，分層模式將軟件分割成各個(gè)單元（稱為“層”）。

" c# R! |) G9 a- g每一層都是一組模塊，提供了一組高內(nèi)聚的服務(wù)。其使用必須是單向的。將一組軟件作為一個(gè)完整的分區(qū)，每個(gè)分區(qū)暴露一個(gè)公開接口。

7 P  S* M/ p" b, X" N. ~

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

第二個(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)求不能跳過任何層。


9 F) Q4 [9 ^9 l; S
  k4 ^0 t$ g: K& j
4）弱點(diǎn)
' p. [6 U3 u6 S/ A: b分層會(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)用于小型簡(jiǎn)單的應(yīng)用程序。
- V  b" N4 g( D$ }9 o
6 Y% j, U6 B# l% b0 V; q8 Z6 |多層模式

8 C/ T! M! Z+ ^+ D許多系統(tǒng)的執(zhí)行結(jié)構(gòu)被組織成一系列邏輯組件分組。每個(gè)分組被稱為一個(gè)層。
8 o- F% f  L9 A- E; s
1）上下文
1 i+ {3 C3 M2 _+ i! l在一個(gè)分布式部署中，通常需要將系統(tǒng)的基礎(chǔ)設(shè)施分到不同的子集中。

* l$ ]2 |2 \" `$ T2 w7 E2）問題
" d' p8 f4 x* }* y! e* g- w8 G# F我們?nèi)绾螌⑾到y(tǒng)分割到多個(gè)計(jì)算上獨(dú)立的執(zhí)行結(jié)構(gòu)：由一些通信媒介連接的軟件和硬件組？

, _( `4 T" N/ X+ G, E6 W+ P" `3）弱點(diǎn)
大量前期成本和復(fù)雜性。

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

) U& v; L! D2 N/ x; D管道-過濾器架構(gòu)
軟件架構(gòu)中反復(fù)出現(xiàn)的一種模式是管道 - 過濾器（pipe-filter）模式。
+ V: q8 ^5 X$ r( t" I
- W0 I: o: F6 f. g9 p- ~
1）上下文
許多系統(tǒng)需要轉(zhuǎn)換從輸入到輸出的離散數(shù)據(jù)流。許多類型轉(zhuǎn)換在實(shí)踐中重復(fù)出現(xiàn)，因此將其創(chuàng)建成獨(dú)立的可復(fù)用的部分，這是比較理想的。

7 D8 l5 K5 Y% J1 E8 C0 L3 G! C2）問題
這些系統(tǒng)需要被分割成可復(fù)用的松耦合的組件，組件之間擁有簡(jiǎn)單通用的交互機(jī)制。這樣它們就可以靈活地相互結(jié)合。這些通用松耦合的組件就很容易復(fù)用。獨(dú)立的組件可以并行執(zhí)行。

3 M- j4 w5 ^4 V% i3）方案
$ }6 P5 w9 S- l1 N; L1 R3 _- y這種架構(gòu)中的管道構(gòu)成了過濾器之間的通信通道。第一個(gè)概念是，由于性能原因，每個(gè)管道都是非定向的和點(diǎn)對(duì)點(diǎn)的，接受來自一個(gè)源的輸入并經(jīng)常直接輸出到另外一個(gè)源。

在這種模式中，有如下四種過濾器。
? producer（source）：一個(gè)過程的起點(diǎn)。
- u; T% U8 R- u, @1 q  }4 k? transformer (map)：對(duì)一些或所有數(shù)據(jù)進(jìn)行轉(zhuǎn)換。
? tester (reduce)：測(cè)試一個(gè)或多個(gè)條件。
6 |7 A$ b8 Q- A9 ]1 s0 L? consumer (sink)：終點(diǎn)。
6 w  N- D* f. w$ V% E1 D; |+ D
4）弱點(diǎn)
不太適合交互性的系統(tǒng)，因?yàn)樗鼈兊霓D(zhuǎn)換特性。過多的解析和反解析會(huì)導(dǎo)致性能損失，也會(huì)增加編寫過濾器本身的復(fù)雜性。

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

4 e7 i1 H  B( o9 B0 G  u客戶端-過濾器架構(gòu)
2 U4 B) ?4 U' l8 D% y, s8 y  n" |- c0 H
5 h7 N" d3 L. U) d9 R! q$ ]
# v  [- ^' ^  L4 Z: l1）上下文
有許多共享資源和服務(wù)是大量分布式的客戶端希望訪問的，希望控制訪問或服務(wù)質(zhì)量。
4 R& H9 }' X7 i0 u
2）問題
通過管理一組共享資源和服務(wù)，我們可以通過分解公共服務(wù)并在單個(gè)位置或少數(shù)位置進(jìn)行修改來提高可修改性和復(fù)用性。我們想要通過在將資源本身分布在多個(gè)物理服務(wù)器上的同時(shí)集中控制這些資源和服務(wù)，來提高可伸縮性和可用性。
/ b+ o+ F1 `4 ?. Q
3）方案
在客戶端 - 服務(wù)器模式中，組件和連接器具有特定的行為。稱為“客戶端”的組件將請(qǐng)求發(fā)送到稱為“服務(wù)器”的組件，然后等待回復(fù)。服務(wù)器組件接收到客戶端的請(qǐng)求并向其發(fā)送回復(fù)。
: x9 f' u1 ^: \* [% H5 d* |
. |1 q* x" \6 G4 V2 U* W8 ]4）弱點(diǎn)
服務(wù)器會(huì)成為性能瓶頸和單點(diǎn)故障位置。在系統(tǒng)建成后，關(guān)于功能位置（在客戶端還是在服務(wù)器）的決策通常是復(fù)雜的而且變動(dòng)成本很大。
9 @/ w4 ]# D% N- Z7 Y
5）用途
/ k" j8 |% ~+ d$ M* l0 I4 q對(duì)于有許多組件（客戶端）發(fā)送請(qǐng)求到另外一些提供服務(wù)的組件（服務(wù)器）的系統(tǒng)，我們可以使用客戶端 - 服務(wù)器模式來建模這個(gè)系統(tǒng)的一部分：在線應(yīng)用程序，例如電子郵件、共享文檔或銀行服務(wù)。
* c2 v, D  m% L+ z- E0 n
& A1 S& q" ]- D! R+ j- t/ g模型-視圖-控制器架構(gòu)（MVC）

' J5 ~) R+ V1 ^5 C
( @# i2 N! s7 J6 f
1）上下文
" w: A. E- m1 F7 C% S7 ~用戶界面通常是一個(gè)交互性應(yīng)用程序的最頻繁被修改的部分。用戶通常希望從不同的視角查看數(shù)據(jù)，例如柱狀圖或者餅圖。這些表示形式都應(yīng)該反映數(shù)據(jù)當(dāng)前的狀態(tài)。
) Z+ g, k! F' T4 [
2）問題
) t5 \. ?) R( B$ t- h& \用戶界面功能如何獨(dú)立于應(yīng)用程序功能，同時(shí)還還對(duì)用戶輸入或底層應(yīng)用程序數(shù)據(jù)的更改做出響應(yīng)？
% C. r. K9 B( ]8 ?1 M! W, n當(dāng)?shù)讓討?yīng)用程序數(shù)據(jù)更改時(shí)，如何創(chuàng)建、維護(hù)和協(xié)調(diào)用戶界面的多個(gè)視圖？

3）方案
$ g2 s& @3 c8 G模型 - 視圖 - 控制器（model-view-controller，即 MVC）模式將應(yīng)用程序功能分為以下三種類型的組件：
3 k( [/ Y& o6 d) R, S? 模型，包含應(yīng)用程序的數(shù)據(jù)。
? 視圖，顯示部分底層數(shù)據(jù)并與用戶交互。
1 a0 i9 D& _8 W- M6 }( }# U? 控制器，在模型和視圖之間進(jìn)行中介并管理狀態(tài)更改的通知。

' \- S8 z0 D* e1 Z4）弱點(diǎn)
對(duì)于簡(jiǎn)單的用戶界面，其復(fù)雜性并不值得這么做。
模型、視圖和控制器抽象可能不適用于某些用戶界面工具包。

5）用途
* o4 {. ^" g% C) ]& |% X$ N6 NMVC 是網(wǎng)站或移動(dòng)應(yīng)用程序開發(fā)用戶界面常用的一種架構(gòu)模式。

$ T' ]7 A) g' b2 Y
事件驅(qū)動(dòng)架構(gòu)
4 ~; U2 S+ u' L: v6 T) ~" R) U. I1）上下文
需要提供計(jì)算和信息資源來處理傳入的應(yīng)用程序生成的獨(dú)立異步事件，這種方式可以隨著需求的增加而擴(kuò)展。

2）問題
構(gòu)建分布式系統(tǒng)，這個(gè)系統(tǒng)可以服務(wù)異步到達(dá)的事件相關(guān)信息，并且能從簡(jiǎn)單小型擴(kuò)展到復(fù)雜大型。
% R/ G; K, j) e8 M  l
# Z6 U7 ?8 D' W& w& W. U+ h3）方案
  A& }. V+ |6 h5 Y5 s7 u, T
為事件處理部署獨(dú)立的事件進(jìn)程或處理器。到達(dá)的事件進(jìn)入隊(duì)列。調(diào)度程序根據(jù)調(diào)度策略從隊(duì)列中拉取事件并將它們分配到合適的事件處理器。

4）弱點(diǎn)
- Z' H8 Y! H6 Y; S! ~性能和錯(cuò)誤恢復(fù)可能是問題。
% k6 B2 A  D9 ?& u1 \- h
5）用途
使用這個(gè)方案的電商應(yīng)用程序?qū)⒐ぷ魅缦拢?font class="jammer">6 Y& [4 X$ a+ E

  K& ^5 Y# v  ~3 TOrder Service 創(chuàng)建一個(gè) Order，這個(gè)訂單處于待定狀態(tài)，然后發(fā)布一個(gè)OrderCreated事件。
) z. l# ~9 J0 D, ~# ?? Customer Service 接收到這個(gè)事件并嘗試為這個(gè) Order 扣除信用。然后發(fā)布一個(gè)Credit Reserved 事件或者CreditLimitExceeded（超出信用限額）事件。
  [1 s, R; G5 O? Order Service 接收到 Customer Service 發(fā)送的事件并將訂單狀態(tài)更改為已核準(zhǔn)或已取消。


微服務(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。
" |5 u3 O& g! w0 Y% p7 h
; j/ x$ x0 z! }2 E2）問題
! l7 y2 J6 K% j8 y0 P5 D, {( Y. [一體化應(yīng)用程序會(huì)變得過于龐大和復(fù)雜，無法得到有效支持和部署來實(shí)現(xiàn)最優(yōu)的分布式資源利用，例如在云環(huán)境中。
% m) h- X# [: C! Y0 w3 u/ D
' _3 I9 D9 Q9 S" Y3）方案
2 v5 S% u% Q% i/ j  J; p
將應(yīng)用程序構(gòu)建成服務(wù)套件。每個(gè)服務(wù)都是獨(dú)立部署和可擴(kuò)展的，擁有自己的 API 邊界。不同的服務(wù)可以用不同的編程語言編寫，管理它們自己的數(shù)據(jù)庫，由不同的團(tuán)隊(duì)開發(fā)。
6 ?9 L! e9 V* U' f. {# ~
* ^8 F4 u# [; D6 _& N) K' ]5 i4 g; L4）弱點(diǎn)
系統(tǒng)設(shè)計(jì)必須能容忍服務(wù)失敗，需要更多的系統(tǒng)監(jiān)控。服務(wù)編排和事件協(xié)作開銷比較大。

5）用途
" w$ @1 X# H1 U+ ]/ I/ F, [許多使用場(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)告等。
+ X" W6 G6 ^; i
文章來源：牛逼的工程師網(wǎng)友。

. `' n3 b+ ]! P6 Q# t

我是老溫，一名熱愛學(xué)習(xí)的嵌入式工程師
關(guān)注我，一起變得更加優(yōu)秀！