轉載：阮一峯 軟件架構入門

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

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

合適的架構是軟件成功的最重要因素之一。大型軟件公司一般有專門的架構師職位（architect），只有資深程序員才能夠擔任。

O'Reilly 出版過一本免費的小冊子《Software Architecture Patterns》（PDF）， 介紹了五種最多見的軟件架構，是很是好的入門讀物。我讀後受益不淺，下面就是個人筆記。

1、分層架構

分層架構（layered architecture）是最多見的軟件架構，也是事實上的標準架構。若是你不知道要用什麼架構，那就用它。

這種架構將軟件分紅若干個水平層，每一層都有清晰的角色和分工，不須要知道其餘層的細節。層與層之間經過接口通訊。

雖然沒有明確約定，軟件必定要分紅多少層，可是四層的結構最多見。

表現層（presentation）：用戶界面，負責視覺和用戶互動
業務層（business）：實現業務邏輯
持久層（persistence）：提供數據，SQL 語句就放在這一層
數據庫（database） ：保存數據
有的軟件在邏輯層和持久層之間，加了一個服務層（service），提供不一樣業務邏輯須要的一些通用接口。

用戶的請求將依次經過這四層的處理，不能跳過其中任何一層。

優勢

結構簡單，容易理解和開發
不一樣技能的程序員能夠分工，負責不一樣的層，自然適合大多數軟件公司的組織架構
每一層均可以獨立測試，其餘層的接口經過模擬解決
缺點

一旦環境變化，須要代碼調整或增長功能時，一般比較麻煩和費時
部署比較麻煩，即便只修改一個小地方，每每須要整個軟件從新部署，不容易作持續發佈
軟件升級時，可能須要整個服務暫停
擴展性差。用戶請求大量增長時，必須依次擴展每一層，因爲每一層內部是耦合的，擴展會很困難

2、事件驅動架構

事件（event）是狀態發生變化時，軟件發出的通知。

事件驅動架構（event-driven architecture）就是經過事件進行通訊的軟件架構。它分紅四個部分。

事件隊列（event queue）：接收事件的入口
分發器（event mediator）：將不一樣的事件分發到不一樣的業務邏輯單元
事件通道（event channel）：分發器與處理器之間的聯繫渠道
事件處理器（event processor）：實現業務邏輯，處理完成後會發出事件，觸發下一步操做
對於簡單的項目，事件隊列、分發器和事件通道，能夠合爲一體，整個軟件就分紅事件代理和事件處理器兩部分。

優勢

分佈式的異步架構，事件處理器之間高度解耦，軟件的擴展性好
適用性廣，各類類型的項目均可以用
性能較好，由於事件的異步本質，軟件不易產生堵塞
事件處理器能夠獨立地加載和卸載，容易部署
缺點

涉及異步編程（要考慮遠程通訊、失去響應等狀況），開發相對複雜
難以支持原子性操做，由於事件經過會涉及多個處理器，很難回滾
分佈式和異步特性致使這個架構較難測試

3、微核架構

微核架構（microkernel architecture）又稱爲"插件架構"（plug-in architecture），指的是軟件的內核相對較小，主要功能和業務邏輯都經過插件實現。

內核（core）一般只包含系統運行的最小功能。插件則是互相獨立的，插件之間的通訊，應該減小到最低，避免出現互相依賴的問題。

優勢

良好的功能延伸性（extensibility），須要什麼功能，開發一個插件便可
功能之間是隔離的，插件能夠獨立的加載和卸載，使得它比較容易部署，
可定製性高，適應不一樣的開發須要
能夠漸進式地開發，逐步增長功能
缺點

擴展性（scalability）差，內核一般是一個獨立單元，不容易作成分佈式
開發難度相對較高，由於涉及到插件與內核的通訊，以及內部的插件登記機制

4、微服務架構

微服務架構（microservices architecture）是服務導向架構（service-oriented architecture，縮寫 SOA）的升級。

每個服務就是一個獨立的部署單元（separately deployed unit）。這些單元都是分佈式的，互相解耦，經過遠程通訊協議（好比REST、SOAP）聯繫。

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

RESTful API 模式：服務經過 API 提供，雲服務就屬於這一類
RESTful 應用模式：服務經過傳統的網絡協議或者應用協議提供，背後一般是一個多功能的應用程序，常見於企業內部
集中消息模式：採用消息代理（message broker），能夠實現消息隊列、負載均衡、統一日誌和異常處理，缺點是會出現單點失敗，消息代理可能要作成集羣
優勢

擴展性好，各個服務之間低耦合
容易部署，軟件從單一可部署單元，被拆成了多個服務，每一個服務都是可部署單元
容易開發，每一個組件均可以進行持續集成式的開發，能夠作到實時部署，不間斷地升級
易於測試，能夠單獨測試每個服務
缺點

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

5、雲架構

雲結構（cloud architecture）主要解決擴展性和併發的問題，是最容易擴展的架構。

它的高擴展性，主要緣由是沒使用中央數據庫，而是把數據都複製到內存中，變成可複製的內存數據單元。而後，業務處理能力封裝成一個個處理單元（prcessing unit）。訪問量增長，就新建處理單元；訪問量減小，就關閉處理單元。因爲沒有中央數據庫，因此擴展性的最大瓶頸消失了。因爲每一個處理單元的數據都在內存裏，最好要進行數據持久化。

這個模式主要分紅兩部分：處理單元（processing unit）和虛擬中間件（virtualized middleware）。

處理單元：實現業務邏輯
虛擬中間件：負責通訊、保持sessions、數據複製、分佈式處理、處理單元的部署。

虛擬中間件又包含四個組件。

消息中間件（Messaging Grid）：管理用戶請求和session，當一個請求進來之後，決定分配給哪個處理單元。
數據中間件（Data Grid）：將數據複製到每個處理單元，即數據同步。保證某個處理單元都獲得一樣的數據。
處理中間件（Processing Grid）：可選，若是一個請求涉及不一樣類型的處理單元，該中間件負責協調處理單元
部署中間件（Deployment Manager）：負責處理單元的啓動和關閉，監控負載和響應時間，當負載增長，就新啓動處理單元，負載減小，就關閉處理單元。
優勢

高負載，高擴展性
動態部署
缺點

實現複雜，成本較高 主要適合網站類應用，不合適大量數據吞吐的大型數據庫應用 較難測試 （完）