軟體架構分類(轉載)

科睿思博發表於2016-09-04

思維導圖:

 作者:阮一峰(以下內容)

日期:2016年9月 3日

軟體架構(software architecture)就是軟體的基本結構。

合適的架構是軟體成功的最重要因素之一。大型軟體公司通常有專門的架構師職位(architect),只有資深程式設計師才可以擔任。

O'Reilly 出版過一本免費的小冊子《Software Architecture Patterns》PDF), 介紹了五種最常見的軟體架構,是非常好的入門讀物。我讀後受益匪淺,下面就是我的筆記。

一、分層架構

分層架構(layered architecture)是最常見的軟體架構,也是事實上的標準架構。如果你不知道要用什麼架構,那就用它。

這種架構將軟體分成若干個水平層,每一層都有清晰的角色和分工,不需要知道其他層的細節。層與層之間通過介面通訊。

雖然沒有明確約定,軟體一定要分成多少層,但是四層的結構最常見。

  • 表現層(presentation):使用者介面,負責視覺和使用者互動
  • 業務層(business):實現業務邏輯
  • 持久層(persistence):提供資料,SQL 語句就放在這一層
  • 資料庫(database) :儲存資料

有的軟體在邏輯層和持久層之間,加了一個服務層(service),提供不同業務邏輯需要的一些通用介面。

使用者的請求將依次通過這四層的處理,不能跳過其中任何一層

優點

  • 結構簡單,容易理解和開發
  • 不同技能的程式設計師可以分工,負責不同的層,天然適合大多數軟體公司的組織架構
  • 每一層都可以獨立測試,其他層的介面通過模擬解決

缺點

  • 一旦環境變化,需要程式碼調整或增加功能時,通常比較麻煩和費時
  • 部署比較麻煩,即使只修改一個小地方,往往需要整個軟體重新部署,不容易做持續釋出
  • 軟體升級時,可能需要整個服務暫停
  • 擴充套件性差。使用者請求大量增加時,必須依次擴充套件每一層,由於每一層內部是耦合的,擴充套件會很困難

 

二、事件驅動架構

事件(event)是狀態發生變化時,軟體發出的通知。

事件驅動架構(event-driven architecture)就是通過事件進行通訊的軟體架構。它分成四個部分。

  • 事件佇列(event queue):接收事件的入口
  • 分發器(event mediator):將不同的事件分發到不同的業務邏輯單元
  • 事件通道(event channel):分發器與處理器之間的聯絡渠道
  • 事件處理器(event processor):實現業務邏輯,處理完成後會發出事件,觸發下一步操作

對於簡單的專案,事件佇列、分發器和事件通道,可以合為一體,整個軟體就分成事件代理和事件處理器兩部分。

 

優點

  • 分散式的非同步架構,事件處理器之間高度解耦,軟體的擴充套件性好
  • 適用性廣,各種型別的專案都可以用
  • 效能較好,因為事件的非同步本質,軟體不易產生堵塞
  • 事件處理器可以獨立地載入和解除安裝,容易部署

缺點

  • 涉及非同步程式設計(要考慮遠端通訊、失去響應等情況),開發相對複雜
  • 難以支援原子性操作,因為事件通過會涉及多個處理器,很難回滾
  • 分散式和非同步特性導致這個架構較難測試

三、微核架構

微核架構(microkernel architecture)又稱為"外掛架構"(plug-in architecture),指的是軟體的核心相對較小,主要功能和業務邏輯都通過外掛實現。

核心(core)通常只包含系統執行的最小功能。外掛則是互相獨立的,外掛之間的通訊,應該減少到最低,避免出現互相依賴的問題。

優點

  • 良好的功能延伸性(extensibility),需要什麼功能,開發一個外掛即可
  • 功能之間是隔離的,外掛可以獨立的載入和解除安裝,使得它比較容易部署,
  • 可定製性高,適應不同的開發需要
  • 可以漸進式地開發,逐步增加功能

缺點

  • 擴充套件性(scalability)差,核心通常是一個獨立單元,不容易做成分散式
  • 開發難度相對較高,因為涉及到外掛與核心的通訊,以及內部的外掛登記機制

四、微服務架構

微服務架構(microservices architecture)是服務導向架構(service-oriented architecture,縮寫 SOA)的升級。

每一個服務就是一個獨立的部署單元(separately deployed unit)。這些單元都是分散式的,互相解耦,通過遠端通訊協議(比如REST、SOAP)聯絡。

微服務架構分成三種實現模式。

  • RESTful API 模式:服務通過 API 提供,雲服務就屬於這一類
  • RESTful 應用模式:服務通過傳統的網路協議或者應用協議提供,背後通常是一個多功能的應用程式,常見於企業內部
  • 集中訊息模式:採用訊息代理(message broker),可以實現訊息佇列、負載均衡、統一日誌和異常處理,缺點是會出現單點失敗,訊息代理可能要做成叢集

優點

  • 擴充套件性好,各個服務之間低耦合
  • 容易部署,軟體從單一可部署單元,被拆成了多個服務,每個服務都是可部署單元
  • 容易開發,每個元件都可以進行持續整合式的開發,可以做到實時部署,不間斷地升級
  • 易於測試,可以單獨測試每一個服務

缺點

  • 由於強調互相獨立和低耦合,服務可能會拆分得很細。這導致系統依賴大量的微服務,變得很凌亂和笨重,效能也會不佳。
  • 一旦服務之間需要通訊(即一個服務要用到另一個服務),整個架構就會變得複雜。典型的例子就是一些通用的 Utility 類,一種解決方案是把它們拷貝到每一個服務中去,用冗餘換取架構的簡單性。
  • 分散式的本質使得這種架構很難實現原子性操作,交易回滾會比較困難。

五、雲架構

雲結構(cloud architecture)主要解決擴充套件性和併發的問題,是最容易擴充套件的架構。

它的高擴充套件性,主要原因是沒使用中央資料庫,而是把資料都複製到記憶體中,變成可複製的記憶體資料單元。然後,業務處理能力封裝成一個個處理單元(prcessing unit)。訪問量增加,就新建處理單元;訪問量減少,就關閉處理單元。由於沒有中央資料庫,所以擴充套件性的最大瓶頸消失了。由於每個處理單元的資料都在記憶體裡,最好要進行資料持久化。

這個模式主要分成兩部分:處理單元(processing unit)和虛擬中介軟體(virtualized middleware)。

  • 處理單元:實現業務邏輯
  • 虛擬中介軟體:負責通訊、保持sessions、資料複製、分散式處理、處理單元的部署。

 

 

虛擬中介軟體又包含四個元件。

  • 訊息中介軟體(Messaging Grid):管理使用者請求和session,當一個請求進來以後,決定分配給哪一個處理單元。
  • 資料中介軟體(Data Grid):將資料複製到每一個處理單元,即資料同步。保證某個處理單元都得到同樣的資料。
  • 處理中介軟體(Processing Grid):可選,如果一個請求涉及不同型別的處理單元,該中介軟體負責協調處理單元
  • 部署中介軟體(Deployment Manager):負責處理單元的啟動和關閉,監控負載和響應時間,當負載增加,就新啟動處理單元,負載減少,就關閉處理單元。

優點

  • 高負載,高擴充套件性
  • 動態部署

缺點

  • 實現複雜,成本較高
  • 主要適合網站類應用,不合適大量資料吞吐的大型資料庫應用
  • 較難測試

 

 

 

相關文章