電子產(chǎn)業(yè)一站式賦能平臺

PCB聯(lián)盟網(wǎng)

搜索
查看: 45|回復(fù): 0
收起左側(cè)

分享 7 種嵌入式軟件設(shè)計架構(gòu)

[復(fù)制鏈接]
跳轉(zhuǎn)到指定樓層
樓主
匿名  發(fā)表于 2023-2-17 17:50:00 回帖獎勵 |倒序瀏覽 |閱讀模式
我是老溫,一名熱愛學(xué)習(xí)的嵌入式工程師
關(guān)注我,一起變得更加優(yōu)秀!架構(gòu)模式是對給定上下文的軟件架構(gòu)中常見問題的一種通用的可復(fù)用的解決方案。一種模式就是特定上下文的問題的一種解決方案。
然而,很多開發(fā)者至今還對各種軟件架構(gòu)模式之間的差別搞不清,甚至對其所知甚少。大體上,主要有下面這7種架構(gòu)模式:
  • 分層架構(gòu)
  • 多層架構(gòu)
  • 管道/過濾器架構(gòu)
  • 客戶端/服務(wù)器架構(gòu)
  • 模型/視圖/控制器架構(gòu)
  • 事件驅(qū)動架構(gòu)
  • 微服務(wù)架構(gòu)
    [/ol]1分層架構(gòu)模式
    最常見的架構(gòu)模式就是分層架構(gòu)或者稱為 n 層架構(gòu)。大部分軟件架構(gòu)師、設(shè)計師和開發(fā)者都對這個架構(gòu)模式非常熟悉。盡管對于層的數(shù)量和類型沒有具體限制,但大部分分層架構(gòu)主要由四層組成:展現(xiàn)層、業(yè)務(wù)層、持久層和數(shù)據(jù)庫層,如下圖所示。

    一個很流行的 n 層架構(gòu)示例 1 上下文 所有復(fù)雜的系統(tǒng)都會經(jīng)歷獨立地發(fā)展和衍化系統(tǒng)各個部分的需要。出于這個原因,系統(tǒng)開發(fā)者需要對關(guān)注點進行清晰且條理分明的分離,以便系統(tǒng)的各個模塊可以獨立地開發(fā)和維護。 2 問題
    軟件需要以這樣一種方式分割:各個模塊可以獨自開發(fā)和衍化,各自部分之間的交互非常少,支持可移植性、可修改性和復(fù)用性。 3 方案
    為了實現(xiàn)關(guān)注點分離,分層模式將軟件分割成各個單元(稱為“層”)。每一層都是一組模塊,提供了一組高內(nèi)聚的服務(wù)。其使用必須是單向的。層將一組軟件作為一個完整的分區(qū),每個分區(qū)暴露一個公開接口。
  • 第一個概念是,每一層都有特定的角色和職責(zé)。例如,展現(xiàn)層負責(zé)處理所有的用戶界面。分層架構(gòu)的這種關(guān)注點分離,讓構(gòu)建高效的角色和職責(zé)非常簡單。
  • 第二個概念是,分層架構(gòu)模式是一個技術(shù)性的分區(qū)架構(gòu),而非一個領(lǐng)域性的分區(qū)架構(gòu)。它們是由組件組成的,而不是領(lǐng)域。
  • 最后一個概念是,分層架構(gòu)中的每一層都被標記為封閉或者開放。封閉層意味著請求從一層移到另一層,它必須通過它正下面的這一層才能達到下面這一層的再下一層。請求不能跳過任何層。


    封閉層和請求訪問
    4 弱點 分層會導(dǎo)致性能下降。這種模式不適合高性能應(yīng)用程序,因為經(jīng)過架構(gòu)中的多層來實現(xiàn)一個業(yè)務(wù)請求的效率是不高的。分層還會增加系統(tǒng)的前期成本和復(fù)雜性。
    5 用途 我們應(yīng)該將這種方式應(yīng)用于小型簡單的應(yīng)用程序或網(wǎng)站。對于預(yù)算和時間非常緊張的場景,這是一個不錯的選擇。2多層模式
    1 方案

    一個多層模式示例:消費者網(wǎng)站 J2EE
    許多系統(tǒng)的執(zhí)行結(jié)構(gòu)被組織成一系列邏輯組件分組。每個分組被稱為一個層。 1 上下文 在一個分布式部署中,通常需要將系統(tǒng)的基礎(chǔ)設(shè)施分到不同的子集中。 2 問題 我們?nèi)绾螌⑾到y(tǒng)分割到多個計算上獨立的執(zhí)行結(jié)構(gòu):由一些通信媒介連接的軟件和硬件組? 3 弱點 大量前期成本和復(fù)雜性。 4 用途 用在分布式系統(tǒng)中。
    3管道、過濾器架構(gòu)
    軟件架構(gòu)中反復(fù)出現(xiàn)的一種模式是管道 - 過濾器(pipe-filter)模式。

    管道過濾器模式
    1 上下文 許多系統(tǒng)需要轉(zhuǎn)換從輸入到輸出的離散數(shù)據(jù)流。許多類型轉(zhuǎn)換在實踐中重復(fù)出現(xiàn),因此將其創(chuàng)建成獨立的可復(fù)用的部分,這是比較理想的。
    2 問題 這些系統(tǒng)需要被分割成可復(fù)用的松耦合的組件,組件之間擁有簡單通用的交互機制。這樣它們就可以靈活地相互結(jié)合。這些通用松耦合的組件就很容易復(fù)用。那些獨立的組件可以并行執(zhí)行。
    3 方案 這種架構(gòu)中的管道構(gòu)成了過濾器之間的通信通道。第一個概念是,由于性能原因,每個管道都是非定向的和點對點的,接受來自一個源的輸入并經(jīng)常直接輸出到另外一個源。在這種模式中,有如下四種過濾器。
  • producer(source):一個過程的起點。
  • transformer (map):對一些或所有數(shù)據(jù)進行轉(zhuǎn)換。
  • tester (reduce):測試一個或多個條件。
  • consumer (sink):終點。
    4 弱點 不太適合交互性的系統(tǒng),因為它們的轉(zhuǎn)換特性。過多的解析和反解析會導(dǎo)致性能損失,也會增加編寫過濾器本身的復(fù)雜性。
    5 用途 管道 - 過濾器架構(gòu)用于各種應(yīng)用程序,特別是簡化單項處理的任務(wù),例如 EDI、ETL 工具。編譯器:連續(xù)的過濾器執(zhí)行詞法分析、語法分析、語義分析和代碼生成。
    4客戶端、過濾器架構(gòu)


    1 上下文 有許多共享資源和服務(wù)是大量分布式的客戶端希望訪問的,我們希望控制訪問或服務(wù)質(zhì)量。
    2 問題 通過管理一組共享資源和服務(wù),我們可以通過分解公共服務(wù)并在單個位置或少數(shù)位置進行修改來提高可修改性和復(fù)用性。我們想要通過在將資源本身分布在多個物理服務(wù)器上的同時集中控制這些資源和服務(wù),來提高可伸縮性和可用性。
    3 方案 在客戶端 - 服務(wù)器模式中,組件和連接器具有特定的行為。
    稱為“客戶端”的組件將請求發(fā)送到稱為“服務(wù)器”的組件,然后等待回復(fù)。服務(wù)器組件接收到客戶端的請求并向其發(fā)送回復(fù)。
    4 弱點 服務(wù)器會成為性能瓶頸和單點故障位置。
    在系統(tǒng)建成后,關(guān)于功能位置(在客戶端還是在服務(wù)器)的決策通常是復(fù)雜的而且變動成本很大。
    5 用途
    對于有許多組件(客戶端)發(fā)送請求到另外一些提供服務(wù)的組件(服務(wù)器)的系統(tǒng),我們可以使用客戶端 - 服務(wù)器模式來建模這個系統(tǒng)的一部分:在線應(yīng)用程序,例如電子郵件、共享文檔或銀行服務(wù)。
    5模型、視圖、控制器架構(gòu)(MVC)


    1 上下文
    用戶界面通常是一個交互性應(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)用戶界面的多個視圖?
    3 方案
    模型 - 視圖 - 控制器(model-view-controller,即 MVC)模式將應(yīng)用程序功能分為以下三種類型的組件:
  • 模型,包含應(yīng)用程序的數(shù)據(jù)。
  • 視圖,顯示部分底層數(shù)據(jù)并與用戶交互。
  • 控制器,在模型和視圖之間進行中介并管理狀態(tài)更改的通知。
    4 弱點
    對于簡單的用戶界面,其復(fù)雜性并不值得這么做。
    模型、視圖和控制器抽象可能不適用于某些用戶界面工具包。
    5 用途
    MVC 是網(wǎng)站或移動應(yīng)用程序開發(fā)用戶界面常用的一種架構(gòu)模式。
    6事件驅(qū)動架構(gòu)
    1 上下文
    需要提供計算和信息資源來處理傳入的應(yīng)用程序生成的獨立異步事件,這種方式可以隨著需求的增加而擴展。
    2 問題
    構(gòu)建分布式系統(tǒng),這個系統(tǒng)可以服務(wù)異步到達的事件相關(guān)信息,并且能從簡單小型擴展到復(fù)雜大型。
    3 方案

    為事件處理部署獨立的事件進程或處理器。到達的事件進入隊列。調(diào)度程序根據(jù)調(diào)度策略從隊列中拉取事件并將它們分配到合適的事件處理器。
    4 弱點
    性能和錯誤恢復(fù)可能是問題。
    5 用途
    使用這個方案的電商應(yīng)用程序?qū)⒐ぷ魅缦拢?br /> Order Service 創(chuàng)建一個 Order,這個訂單處于待定狀態(tài),然后發(fā)布一個OrderCreated事件。
  • Customer Service 接收到這個事件并嘗試為這個 Order 扣除信用。然后發(fā)布一個 Credit Reserved 事件或者CreditLimitExceeded(超出信用限額)事件。
  • Order Service 接收到 Customer Service 發(fā)送的事件并將訂單狀態(tài)更改為已核準或已取消。
    7微服務(wù)架構(gòu) 1 上下文 部署基于服務(wù)器的企業(yè)應(yīng)用程序,支持各種瀏覽器和原生移動客戶端。應(yīng)用程序通過執(zhí)行業(yè)務(wù)邏輯、訪問數(shù)據(jù)庫、與其它系統(tǒng)交換信息并返回響應(yīng)來處理客戶端請求。這個應(yīng)用程序可能會暴露一個第三方 API。
    2 問題
    一體化應(yīng)用程序會變得過于龐大和復(fù)雜,無法得到有效支持和部署來實現(xiàn)最優(yōu)的分布式資源利用,例如在云環(huán)境中。
    3 方案

    將應(yīng)用程序構(gòu)建成服務(wù)套件。每個服務(wù)都是獨立部署和可擴展的,擁有自己的 API 邊界。不同的服務(wù)可以用不同的編程語言編寫,管理它們自己的數(shù)據(jù)庫,由不同的團隊開發(fā)。
    4 弱點 系統(tǒng)設(shè)計必須能容忍服務(wù)失敗,需要更多的系統(tǒng)監(jiān)控。服務(wù)編排和事件協(xié)作開銷比較大。當然,我們還需要更多錢。
    5 用途 許多使用場景都可以應(yīng)用微服務(wù)架構(gòu),特別是那些涉及大量數(shù)據(jù)管道的場景。例如,一個微服務(wù)系統(tǒng)對關(guān)于一個公司的零售店銷售的報表系統(tǒng)會比較理想。數(shù)據(jù)展現(xiàn)過程的每一步都會被一個微服務(wù)處理:數(shù)據(jù)收集、清理、規(guī)范化、濃縮、聚合、報告等。
    文章來源于網(wǎng)絡(luò),版權(quán)歸原作者所有,如有侵權(quán),請聯(lián)系刪除。

    -END-
    往期推薦:點擊圖片即可跳轉(zhuǎn)閱讀

                                                           
                                                                   
                                                                           
                                                                                   

                                                                                   
                                                                                            嵌入式 C 語言編程,如何正確使用動態(tài)內(nèi)存?
                                                                                   
                                                                           
                                                                   
                                                           
                                                   

                                                           
                                                                   
                                                                           
                                                                                   

                                                                                   
                                                                                            搞嵌入式那么累,值不值得堅持下去?
                                                                                   
                                                                           
                                                                   
                                                           
                                                   

                                                           
                                                                   
                                                                           
                                                                                   

                                                                                   
                                                                                            ChatGPT這貨,還沒學(xué)會腦筋急轉(zhuǎn)彎!
                                                                                   
                                                                           
                                                                   
                                                           
                                                   
    我是老溫,一名熱愛學(xué)習(xí)的嵌入式工程師
    關(guān)注我,一起變得更加優(yōu)秀!
  • 回復(fù)

    使用道具

    發(fā)表回復(fù)

    您需要登錄后才可以回帖 登錄 | 立即注冊

    本版積分規(guī)則


    聯(lián)系客服 關(guān)注微信 下載APP 返回頂部 返回列表