在上一篇《微服務架構設計模式》讀書筆記（一）：逃離單體地獄》中我們對比了單體架構和微服務架構的優缺點，已經實施微服務的組織和流程條件，同時也給出了微服務的概括性定義：把應用程序功能性分解為一組服務的架構風格。在本篇中，我們将繼續深入微服務架構設計。

軟件架構定義

計算機系統的軟件架構是構建這個系統所需要的一組結構，包括軟件元素、它們之間的關系以及兩者的屬性。

——《Documenting Software Architectures: Views and Beyond》

軟件的架構是一種抽象的架構，由軟件的各個組成部分和這些部分之間的依賴關系構成。

軟件需求可以分為兩類：

功能需求：決定軟件可以做什麼

非功能需求：非功能需求也稱為質量需求或者能力，包含開發階段的質量、後續的可維護性、可測試性、可擴展性、可以部署性等質量屬性

以上描述其實和《從零開始學架構》讀書筆記（一）：概念與基礎中講述的軟件架構的定義（頂層結構）和解決複雜性（為了實現高性能、高可用、可擴展、安全等）的理解很類似。

架構的重要性在于：決定應用程序的質量屬性。

架構的4 1視圖模型

邏輯視圖：開發人員創建的軟件元素及關系

實現視圖：編譯構建系統的輸出，模塊、組件及關系

進程視圖：運行時的組件及關系

部署視圖：進程如何映射到機器，由機器、進程及關系構成

分層式架構将軟件運算按“層”的方式組織，每層都有明确定義的職責，每層隻能依賴緊鄰的下層。

可以将分層架構應用于前面所述四種視圖中任何一種，流行的三層架構是應用于邏輯視圖的MVC架構：

• 表現層：包含實現用戶界面或外部API的代碼
• 業務邏輯層：包含業務邏輯
• 數據持久層：實現與數據庫交互的邏輯

其弊端是：

• 單個表現層：無法展現應用程序可能不僅僅由單個系統調用的事實
• 單一數據持久化層：無法展示應用程序可能與多個數據庫進行交互的事實
• 将業務邏輯層定義為依賴于數據持久化層：理論上，這樣的依賴會妨礙在沒有數據庫的情況下測試業務邏輯

六邊形架構是分層架構風格的替代品 [解決分層架構的弊端]，六邊形架構選擇以業務邏輯為中心的方式組織邏輯視圖。

業務邏輯周圍是适配器，有兩種适配器：

• 入站适配器：通過調用入站端口處理外部請求（如Spring MVC Controller，實現REST接口或一組Web界面）
• 出站适配器：通過調用外部應用程序或服務處理來自業務邏輯的請求（如實現數據訪問對象DAO類）

好處：

• 将業務邏輯與适配器中包含的表示層和數據訪問層的邏輯分離開，使單獨測試業務邏輯容易
• 反映現代應用程序的架構

微服務架構是一種把應用程序功能性分解為一組服務的架構風格。

服務是一個單一的、可獨立部署的軟件組件，它實現了一些有用的功能。

• 服務的API封裝了其内部實現
• 服務之間交互使用API完成
• 服務用于實現可能會更改的通用的功能
• 服務的代碼規模不一定小，但通常職責範圍小

微服務架構把應用程序通過一些小的、松耦合的服務組織在一起，能提升開發、測試、維護、部署的效率，讓組織的軟件開發速度更快，同時提升可擴展性。

• 架構決定了軟件的各種非功能性因素，比如可維護性、可測試性、可部署性和可擴展性，它們會直接影響開發速度。
• 微服務架構是一種架構風格，它給應用程序帶來了更高的可維護性、可測試性、可部署性和可擴展性。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!