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

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

O'Reilly 出版過一本免費的小冊子《Software Architecture Patterns》（PDF）， 介紹了五種最常見的軟件架構，是非常好的入門讀物。

軟件架構就是軟件的基本結構。架構的本質是管理復雜性。如果你覺得架構不重要，可能是你做的事情不夠復雜，或者是你沒有管理好復雜性。架構模式雖多，經過抽象沉淀之后，也就那么幾種：

1. 分層架構（比較傳統的單體架構）

2. 事件驅動架構 （一般適用于應用局部場景，用來實現異步解耦）

3. 微核架構（又稱插件架構，開發難度較高，一般用來做工具軟件開發，如Eclipse，不太適合分布式業務場景）

4. 微服務架構（當前比較流行的服務化架構，解決單體架構面臨的問題，適合敏捷開發，快速迭代）

5. 云架構（現在的說法是云原生架構-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架構）

在原文的基礎上，小編按照自己的想法，進行了小幅調整。

layered architecture）是最常見的軟件架構，也是事實上的標準架構。如果你不知道要用什么架構，那就用它。

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

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

• 表現層（presentation）：用戶界面，負責視覺和用戶互動
• 業務層（business）：實現業務邏輯
• 持久層（persistence）：提供數據，SQL 語句就放在這一層
• 數據庫（database） ：保存數據

有的軟件在邏輯層（business）和持久層（persistence）之間，加了一個服務層（service），提供不同業務邏輯需要的一些通用接口。

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

優點

• 結構簡單，容易理解和開發
• 不同技能的程序員可以分工，負責不同的層，天然適合大多數軟件公司的組織架構
• 每一層都可以獨立測試，其他層的接口通過模擬解決

缺點

• 一旦環境變化，需要代碼調整或增加功能時，通常比較麻煩和費時
• 部署比較麻煩，即使只修改一個小地方，往往需要整個軟件重新部署，不容易做持續發布（因為是單體架構）
• 軟件升級時，可能需要整個服務暫停
• 擴展性差。用戶請求大量增加時，必須依次擴展每一層，由于每一層內部是耦合的，擴展會很困難（單體架構，需求調整會貫穿每一層）

事件驅動架構（event-driven architecture）核心組件：

• 事件隊列（event queue）：接收事件的入口
• 分發器（event mediator）：將不同的事件分發到不同的業務邏輯單元
• 事件通道（event channel）：分發器與處理器之間的聯系渠道
• 事件處理器（event processor）：實現業務邏輯，處理完成后會發出事件，觸發下一步操作

對于簡單的項目，事件隊列、分發器和事件通道，可以合為一體，整個軟件就分成事件代理和事件處理器兩部分。

優點

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

缺點

• 涉及異步編程（要考慮遠程通信、失去響應等情況），開發相對復雜
• 難以支持原子性操作，因為事件通過會涉及多個處理器，很難回滾
• 分布式和異步特性導致這個架構較難測試

事件驅動架構在通信產品中應用得也非常廣泛，典型的如狀態機處理。事件驅動架構不適于做頂層架構，但適合做局部實現，幾乎遍布在通信軟件的各個角落。

優點

• 良好的功能延伸性（extensibility），需要什么功能，開發一個插件即可
• 功能之間是隔離的，插件可以獨立的加載和卸載，使得它比較容易部署，
• 可定制性高，適應不同的開發需要
• 可以漸進式地開發，逐步增加功能

缺點

• 擴展性（scalability）差，內核通常是一個獨立單元，不容易做成分布式
• 開發難度相對較高，因為涉及到插件與內核的通信，以及內部的插件登記機制

微核架構的設計和開發難度較高，這就注定它在企業產品中用得不多，雖然它的優點還不少。

RESTful API 模式：服務通過 API 提供，云服務就屬于這一類

RESTful 應用模式：服務通過傳統的網絡協議或者應用協議提供，背后通常是一個多功能的應用程序，常見于企業內部

集中消息模式：采用消息代理（message broker），可以實現消息隊列、負載均衡、統一日志和異常處理，缺點是會出現單點失敗，消息代理可能要做成集群

現在開源的微服務框架比較多，如常用的有Spring Cloud、Dubbo、ServiceComb等等。

優點

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

缺點

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

處理單元：實現業務邏輯（類似于微服務架構中的微服務）

虛擬中間件：負責通信、保持sessions、數據復制、分布式處理、處理單元的部署。

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

• 消息中間件（Messaging Grid）：管理用戶請求和session，當一個請求進來以后，決定分配給哪一個處理單元；
• 數據中間件（Data Grid）：將數據復制到每一個處理單元，即數據同步。保證某個處理單元都得到同樣的數據；
• 處理中間件（Processing Grid）：可選，如果一個請求涉及不同類型的處理單元，該中間件負責協調處理單元；
• 部署中間件（Deployment Manager）：負責處理單元的啟動和關閉，監控負載和響應時間，當負載增加，就新啟動處理單元，負載減少，就關閉處理單元。

隨著Docker、Kubernetes等容器化技術的快速發展，上述關于云架構描述有點陳舊了。當前最新的云原生架構，以Docker+Kubernetes為核心，尤其是容器編排Kubernetes 已經成為事實上的行業標準。

云原生架構圖的主要特征：

• 微服務應用運行支撐環境；
• 以容器化應用的鏡像作為交付標準；
• 通過資源調度服務快速申請、釋放資源；
• 通過彈性伸縮快速擴展應用；
• 狀態監控；

主要目標：

1. 讓開發人員聚焦業務邏輯的實現，其他交給容器云平臺來完成；

2. 支持業務系統的快速迭代，支撐業務的快速變化和發展；

3. 構建以共享服務體系為核心的業務中臺；

下面是小編針對某新零售企業設計的云原生架構圖，以云和微服務架構為基礎構建云原生應用，這里云可以是公有云、私有云、混合云等等。

以上是從不同的視角，對架構進行了分類。實際應用中，各種架構并不是孤立的，可以根據業務環境和業務訴求，對各種架構進行綜合和嫁接。每種架構都有其優點和缺點。優點不必多說，缺點則幾乎都是通過工具工程（比如自動化發布工具、自動化測試等等）能力的方法來規避，工具工程對軟件架構非常重要。

文章名稱：軟件架構入門-分層架構、事件驅動、微服務架構和云原生架構
當前路徑：http://www.js-pz168.com/news19/103819.html

成都網站建設公司_創新互聯，為您提供企業建站、微信小程序、網站設計、云服務器、關鍵詞優化、品牌網站制作

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯