軟件架構(software architecture)就是軟件的基本結構。html
合適的架構是軟件成功的最重要因素之一。大型軟件公司一般有專門的架構師職位(architect),只有資深程序員才能夠擔任。程序員
O'Reilly 出版過一本免費的小冊子《Software Architecture Patterns》(PDF), 介紹了五種最多見的軟件架構,是很是好的入門讀物。我讀後受益不淺,下面就是個人筆記。數據庫
分層架構(layered architecture)是最多見的軟件架構,也是事實上的標準架構。若是你不知道要用什麼架構,那就用它。編程
這種架構將軟件分紅若干個水平層,每一層都有清晰的角色和分工,不須要知道其餘層的細節。層與層之間經過接口通訊。網絡
雖然沒有明確約定,軟件必定要分紅多少層,可是四層的結構最多見。session
- 表現層(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):負責處理單元的啓動和關閉,監控負載和響應時間,當負載增長,就新啓動處理單元,負載減小,就關閉處理單元。
優勢
- 高負載,高擴展性
- 動態部署
缺點
- 實現複雜,成本較高
- 主要適合網站類應用,不合適大量數據吞吐的大型數據庫應用
- 較難測試
- 原文地址:http://www.ruanyifeng.com/blog/2016/09/software-architecture.html