轉：軟體架構入門

http://www.ruanyifeng.com/blog/2016/09/software-architecture.html

軟體架構（software architecture）就是軟體的基本結構。

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

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

一、分層架構

分層架構（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）：負責處理單元的啟動和關閉，監控負載和響應時間，當負載增加，就新啟動處理單元，負載減少，就關閉處理單元。

優點

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

缺點

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

（完