架構師最常使用的5種架構模式及其適用場景分析

好萊塢電影中有多少情節?一些電影評論家說只有五個。您能夠採用幾種架構來實現應用程序?目前大多數程序都使用下面提到的五種架構之一。vue

在本文中,我將五種軟件架構模式的優缺點以及適合場景提煉出來做爲快速參考。你能夠在單個系統中使用多個架構模式,它們的組合既是計算機科學,也是一門藝術。程序員

1、分層架構

這種方法多是最多見的方法,由於它一般圍繞數據庫構建,而且業務中的許多應用程序天然會傾向於將信息存儲在RDBMS的表中。許多比較大的軟件框架(例如Java EE,Drupal和Express)都是在這種架構下實現的,所以使用它們構建的許多應用程序天然都來自分層體系結構。spring

Model-View-Controller(MVC)分層結構是大多數流行的Web框架提供的標準軟件開發方法,顯然是分層體系結構。數據持久層上方是服務層,它一般包含業務邏輯和有關數據庫中數據類型的信息。視圖層位於頂層,一般是CSS,JavaScript和帶有動態嵌入式代碼的HTML。在中間有一個控制層,該控制層具備用於轉換在視圖和模型之間移動的數據的各類規則和方法。數據庫

分層架構的優勢:每一個層能夠只集中於本身的功能實現。這使得應用程序:編程

  • 容易維護
  • 容易單元測試
  • 易於分配單獨的「角色」
  • 易於更新和擴展

適當的分層體系結構將開發層面進行隔離,這些層不受其餘層的更改的影響,從而使重構更加容易。劃分任務並定義單獨的層是架構師面臨的挑戰。當需求很好地適應了模式時,這些層將易於解耦或分層開發。後端

適合:瀏覽器

  • 須要快速構建的新應用程序
  • 傳統IT部門和流程的企業或業務應用程序
  • 具備尚不瞭解其餘架構的經驗不足的開發人員的團隊
  • 須要嚴格的可維護性和可測試性標準的應用

2、事件驅動架構

事件驅動的體系架構根據數據生成一個「事件」,事件由「消息中間件」或「事件分發管理的中央單元」統一接收,並將事件分配特定類型的代碼處理。 緩存

使用JavaScript編程網頁涉及編寫對諸如鼠標單擊或擊鍵之類的事件作出反應的小模塊。瀏覽器自己會協調全部輸入,並確保只有正確的代碼才能獲得正確的事件。瀏覽器中常見許多不一樣類型的事件,可是模塊僅與相關的事件進行交互。這與分層體系結構很是不一樣,在分層體系結構中,全部數據一般都將穿過全部層。整體而言,事件驅動的體系結構:springboot

  • 容易適應複雜,混亂的業務環境
  • 當出現新的事件類型時,很容易擴展

注意事項:服務器

  • 若是模塊之間能夠相互影響,則[測試可能會很複雜
  • 當模塊發生故障時,中央單元(或消息中間件)必須有一個事件備份計劃。
  • 消息傳遞開銷可能會下降處理速度,消息中間件必須緩衝以突發形式到達的消息時。
  • 當事件有很是不一樣的需求時,爲事件開發數據結構可能會很複雜。
  • 維護基於事務的一致性機制很困難,由於接收事件的模塊是解耦和獨立的。

適合:

  • 具備異步數據流的異步系統
  • 各個數據塊僅與多模塊中的少數模塊交互的應用程序
  • 用戶界面

3、微內核-多插件架構

許多的應用程序都具備一組核心代碼,這些代碼在不一樣的模塊下反覆使用。例如,開發工具Eclipse將打開文件,批註,編輯文件並啓動後臺處理器。用於顯示文件和對其進行編輯的代碼是微內核的一部分。其餘的插件擴展了Eclipse,從而擴展了其功能。

具體到解決方案就是將一些基本的核心的任務代碼推入微內核。而後,不一樣的業務部門能夠根據不一樣類型的聲明編寫插件。

注意事項:

  • 肯定哪些代碼是微內核中的內容一般是一門藝術。它應該保留常常被使用的代碼。
  • 一旦許多插件依賴微內核,修改微內核可能很是困難,甚至不可能。惟一的解決方案就是修改插件。
  • 爲內核函數選擇正確的粒度很難事先完成,也幾乎不可能在後期進行更改。

適合:

  • 工具類軟件
  • 在覈心代碼與邊緣代碼之間有清晰區分的應用程序
  • 具備一組固定的核心函數和一組動態規則的應用程序

4、微服務架構

小寶寶既可愛又有趣,可是一旦變大,就很難操縱而且難以維護。微服務架構旨在幫助開發人員避免讓本身的寶寶長大,笨拙,僵硬,煩人。它的目標不是建立一個大型程序,而是建立多個不一樣的小型程序。避免修改一個小bug,就須要從新部署整個大型應用的狀況出現。

這種方法相似於事件驅動和微內核方法,可是主要用於解耦不一樣模塊及任務。在許多狀況下,不一樣的任務可能須要不一樣的處理量,而且用途可能會有所不一樣。因此微服務的特色是便於修改、便於擴展。使用負載均衡及服務發現的機制,在用戶使用高峯期部署更多的微服務,保證服務的高可用;在用戶低頻服務時段縮減微服務,從而節省服務器資源。

注意事項:

  • 並不是全部應用程序均可以拆分爲相對獨立的微服務單元。
  • 當任務分散在不一樣的微服務之間時,通訊成本會更大。單個請求的響應時長會增長。

適合:

  • 快速發展新業務團隊
  • 大型Web應用程序

5、高速緩存架構

許多網站都是圍繞數據庫構建的,只要數據庫可以知足負載,它們就能夠正常運行。可是當使用量達到頂峯,而且數據庫沒法跟上用戶請求的速度時,整個網站就會癱瘓。將數據存儲在內存中可使許多工做更快,從而大幅度提升用戶併發訪問的支撐能力。

注意事項:

  • 對於內存數據庫,事務的支持更加困難。
  • 開發專業的高速緩存數據的程序,對程序員的技術水平每每要求更高一些(至少比只會寫增刪改查的程序員要高)

適合:

  • 高頻點擊數據流和用戶日誌之類的大量數據處理
  • 低價值數據,有時可能會丟失而不會形成重大後果(好比用戶訪問量數據)
  • 讀多寫少的數據。好比新聞數據,寫完以後幾乎不改,可是有不少的人看。

歡迎關注個人博客,裏面有不少精品合集

  • 本文轉載註明出處(必須帶鏈接,不能只轉文字):字母哥博客

以爲對您有幫助的話,幫我點贊、分享!您的支持是我不竭的創做動力! 。另外,筆者最近一段時間輸出了以下的精品內容,期待您的關注。

相關文章
相關標籤/搜索