軟件的架構是一種抽象的結構，它由軟件的各個組成部分和這些部分之間的依賴關系構成。正如你將在本文中看到的，軟件的架構是多維的，因此有多種方法可以對其進行描述。架構很重要的原因是它決定了應用程序的質量屬性或能力。傳統上，架構的目標是可擴展性、可靠性和安全性。但是今天，該架構能夠快速安全地交付軟件，這一點非常重要。你將了解微服務架構是一種架構風格，可為應用程序提供更高的可維護性、可測試性和可部署性。

我將通過描述軟件架構的概念及其重要性來開始本文。接下來，我將討論架構風格的概念。然后我將微服務架構定義為特定的架構風格。讓我們從理解軟件架構的概念開始。

1軟件架構是什么，為什么它如此重要

架構顯然很重要。至少有兩個專門討論該主題的會議：O’Reilly的軟件架構會議和SATURN會議。許多開發人員的目標是成為一名架構師。但什么是架構，為什么它如此重要？

為了回答這個問題，我首先定義術語軟件架構的含義。之后，我將討論應用程序的架構是多維的，并使用一組視圖或藍圖進行描述。然后我將強調軟件架構的重要性，因為它對應用程序的質量屬性有顯著的影響。

軟件架構的定義

軟件架構有很多定義。例如，維基百科上列舉了大量的定義。我最喜歡的定義來自卡耐基梅隆大學軟件工程研究所的Len Bass及其同事，他們在使軟件架構成為一門學科方面發揮了關鍵作用。他們定義的軟件架構如下：

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

這顯然是一個非常抽象的定義。但其實質是應用程序的架構是將軟件分解為元素（element）和這些元素之間的關系（relation）。由于以下兩個原因，分解很重要：

它促進了勞動和知識的分工。它使具有特定專業知識的人們（或多個團隊）能夠就應用程序高效地協同工作。

它定義了軟件元素的交互方式。

將軟件分解成元素以及定義這些元素之間的關系，決定了軟件的能力。

軟件架構的4+1視圖模型

從更具體的角度而言，應用程序的架構可以從多個視角來看，就像建筑架構，一般有結構、管線、電氣等多個架構視角。 Phillip Krutchen 在他經典的論文《 Architectural Blueprints — The 4+1 View Model of Software Architecture 》中提出了軟件架構的4+1視圖。圖1展示的這套視圖定義了四個不同的軟件架構視圖，每一個視圖都只描述架構的一個特定方面。每個視圖包括一些特定的軟件元素和它們相互之間的關系。

圖14+1視圖模型使用四個視圖描述應用程序的架構，并顯示每個視圖中的元素如何協作處理請求的場景

每個視圖的目的如下：

• 邏輯視圖：開發人員創建的軟件元素。在面向對象的語言中，這些元素是類和包。它們之間的關系是類和包之間的關系，包括繼承、關聯和依賴。
• 實現視圖：構建編譯系統的輸出。此視圖由表示打包代碼的模塊和組件組成，組件是由一個或多個模塊組成的可執行或可部署單元。在Java中，模塊是JAR文件，組件通常是WAR文件或可執行JAR文件。它們之間的關系包括模塊之間的依賴關系以及組件和模塊之間的組合關系。
• 進程視圖：運行時的組件。每個元素都是一個進程，進程之間的關系代表進程間通信。
• 部署視圖：進程如何映射到機器。此視圖中的元素由（物理或虛擬）計算機和進程組成。機器之間的關系代表網絡。該視圖還描述了進程和機器之間的關系。

除了這四個視圖以外，4+1中的+1是指場景，它負責把視圖串聯在一起。每個場景負責描述在一個視圖中的多個架構元素如何協作，以完成一個請求。例如，在邏輯視圖中的場景，展現了類是如何協作的。同樣，在進程視圖中的場景，展現了進程是如何協作的。

4+1視圖是描述應用程序架構的好方式。每一個視圖都描述了架構的一個重要側面。場景把視圖中的元素如何協作串聯在一起。現在我們來看看為什么架構是如此重要。

為什么架構如此重要

應用程序有兩個層面的需求。第一類是功能性需求，這些需求決定一個應用程序做什么。這些通常都包含在用例（use case）或者用戶故事（user story）中。應用的架構其實跟這些功能性需求沒什么關系。功能性需求可以通過任意的架構來實現，甚至是非常糟糕的大泥球架構。

架構的重要性在于，它幫助應用程序滿足了第二類需求：非功能性需求。我們把這類需求也稱之為質量屬性需求，或者簡稱為“能力”。這些非功能性需求決定一個應用程序在運行時的質量，比如可擴展性和可靠性。它們也決定了開發階段的質量，包括可維護性、可測試性、可擴展性和可部署性。為應用程序所選擇的架構將決定這些質量屬性。

2什么是架構的風格

在物理世界中，建筑物的建筑通常遵循特定的風格，例如維多利亞式、美國工匠式或裝飾藝術式。每種風格都是一系列設計決策，限制了建筑的特征和建筑材料。建筑風格的概念也適用于軟件。David Garlan和Mary Shaw這兩位軟件架構學科的先驅定義了如下架構風格：

因此，架構風格根據結構組織模式定義了一系列此類系統。更具體地說，架構風格確定可以在該風格的實例中使用的組件和連接器的詞匯表，以及關于如何組合它們的一組約束。

特定的架構風格提供了有限的元素（組件）和關系（連接器），你可以從中定義應用程序架構的視圖。應用程序通常使用多種架構風格的組合。例如，在本節的后面，我將描述單體架構是如何將實現視圖構造為單個（可執行與可部署）組件的架構樣式。微服務架構將應用程序構造為一組松散耦合的服務。

分層式架構風格

架構的典型例子是分層架構。分層架構將軟件元素按“層”的方式組織。每個層都有明確定義的職責。分層架構還限制了層之間的依賴關系。每一層只能依賴于緊鄰其下方的層（如果嚴格分層）或其下面的任何層。

可以將分層架構應用于前面討論的四個視圖中的任何一個。流行的三層架構是應用于邏輯視圖的分層架構。它將應用程序的類組織到以下層中：

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

分層架構是架構風格的一個很好的例子，但它確實有一些明顯的弊端：

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

此外，分層架構錯誤地表示了精心設計的應用程序中的依賴關系。業務邏輯通常定義數據訪問方法的接口或接口庫。數據持久化層則定義了實現存儲庫接口的DAO類。換句話說，依賴關系與分層架構所描述的相反。

讓我們看一下克服這些弊端的替代架構：六邊形架構。

關于架構風格的六邊形

六邊形架構是分層架構風格的替代品。如圖2-2所示，六邊形架構風格選擇以業務邏輯為中心的方式組織邏輯視圖。應用程序具有一個或多個入站適配器，而不是表示層，它通過調用業務邏輯來處理來自外部的請求。同樣，應用程序具有一個或多個出站適配器，而不是數據持久化層，這些出站適配器由業務邏輯調用并調用外部應用程序。此架構的一個關鍵特性和優點是業務邏輯不依賴于適配器。相反，各種適配器都依賴業務邏輯。

圖2六邊形架構的一個示例，它由業務邏輯和一個或多個與外部系統通信的適配器組成。業務邏輯具有一個或多個端口。處理來自外部系統請求的入站適配器調用入站端口。出站適配器實現出站端口，并調用外部系統

業務邏輯具有一個或多個端口（ port ）。端口定義了一組操作，關于業務邏輯如何與外部交互。例如，在 Java 中，端口通常是 Java 接口。有兩種端口：入站和出站端口。入站端口是業務邏輯公開的API，它使外部應用程序可以調用它。入站端口的一個實例是服務接口，它定義服務的公共方法。出站端口是業務邏輯調用外部系統的方式。出站端口的一個實例是存儲庫接口，它定義數據訪問操作的集合。

業務邏輯的周圍是適配器。與端口一樣，有兩種類型的適配器：入站和出站。入站適配器通過調用入站端口來處理來自外部世界的請求。入站適配器的一個實例是 Spring MVC Controller ，它實現一組 REST 接口（ endpoint ）或一組 Web 頁面。另一個實例是訂閱消息的消息代理客戶端。多個入站適配器可以調用相同的入站端口。

出站適配器實現出站端口，并通過調用外部應用程序或服務處理來自業務邏輯的請求。出站適配器的一個實例是實現訪問數據庫的操作的數據訪問對象（ DAO ）類。另一個實例是調用遠程服務的代理類。出站適配器也可以發布事件。

六邊形架構風格的一個重要好處是它將業務邏輯與適配器中包含的表示層和數據訪問層的邏輯分離開來。業務邏輯不依賴于表示層邏輯或數據訪問層邏輯。

由于這種分離，單獨測試業務邏輯要容易得多。另一個好處是它更準確地反映了現代應用程序的架構。可以通過多個適配器調用業務邏輯，每個適配器實現特定的API或用戶界面。業務邏輯還可以調用多個適配器，每個適配器調用不同的外部系統。六邊形架構是描述微服務架構中每個服務的架構的好方法。

分層架構和六邊形架構都是架構風格的實例。每個都定義了架構的構建塊（元素），并對它們之間的關系施加了約束。六邊形架構和分層架構（三層架構）構成了軟件的邏輯視圖。現在讓我們將微服務架構定義為構成軟件的實現視圖的架構風格。

2.1.3微服務架構是一種架構風格

前面已經討論過4+1視圖模型和架構風格，所以現在可以開始定義單體架構和微服務架構。它們都是架構風格。單體架構是一種架構風格，它的實現視圖是單個組件：單個可執行文件或WAR文件。這個定義并沒有說明其他的視圖。例如，單體應用程序可以具有六邊形架構風格的邏輯視圖。

模式：單體架構

將應用程序構建為單個可執行和可部署組件。請參閱： http://microservices.io/patterns/monolithic.html。

微服務架構也是一種架構風格。它的實現視圖由多個組件構成：一組可執行文件或WAR文件。它的組件是服務，連接器是使這些服務能夠協作的通信協議。每個服務都有自己的邏輯視圖架構，通常也是六邊形架構。圖2-3顯示了FTGO應用程序可能的微服務架構。此架構中的服務對應于業務功能，例如訂單管理和餐館管理。

模式：微服務架構

將應用程序構建為松耦合、可獨立部署的一組服務。請參閱： http://microservices.io/patterns/microservices.html。

圖3FTGO應用程序可能的微服務架構。它由眾多服務組成

微服務架構強加的一個關鍵約束是服務松耦合。因此，服務之間的協作方式存在一定限制。為了解釋這些限制，我將嘗試定義什么是服務，解釋松耦合意味著什么，并告訴你為什么這很重要。

什么是服務

服務是一個單一的、可獨立部署的軟件組件，它實現了一些有用的功能。圖2-4顯示了服務的外部視圖，在此示例中是Order Service。服務具有API，為其客戶端提供對功能的訪問。有兩種類型的操作：命令和查詢。API由命令、查詢和事件組成。命令如createOrder()執行操作并更新數據。查詢，如findOrderById()檢索數據。服務還發布由其客戶端使用的事件，例如OrderCreated。

服務的API封裝了其內部實現。與單體架構不同，開發人員無法繞過服務的API直接訪問服務內部的方法或數據。因此，微服務架構強制實現了應用程序的模塊化。

微服務架構中的每項服務都有自己的架構，可能還有獨特的技術棧。但是典型的服務往往都具有六邊形架構。其API由與服務的業務邏輯交互的適配器實現。操作適配器調用業務邏輯，事件適配器對外發布業務邏輯產生的事件。

圖4服務具有封裝實現的API。API定義了由客戶端調用的操作。有兩種類型的操作：命令用來更新數據，查詢用來檢索數據。當服務的數據發生更改時，服務會發布可供客戶端訂閱的事件

在本書第12章討論部署技術時，你將看到服務的實現視圖可以采用多種形式。該組件可以是獨立進程，在容器中運行的Web應用程序或OSGI包、云主機或Serverless技術，等等。但是，一個基本要求是服務具有API并且可以獨立部署。

什么是松耦合

微服務架構的最核心特性是服務之間的松耦合性。服務之間的交互采用API完成，這樣做就封裝了服務的實現細節。這允許服務在不影響客戶端的情況下，對實現方式做出修改。松耦合服務是改善開發效率、提升可維護性和可測試性的關鍵。小的、松耦合的服務更容易被理解、修改和測試。

我們通過API來實現松耦合服務之間的協調調用，這樣就避免了外界對服務的數據庫的直接訪問和調用。服務自身的持久化數據就如同類的私有屬性一樣，是不對外的。保證數據的私有屬性是實現松耦合的前提之一。這樣做，就允許開發者修改服務的數據結構，而不用提前與其他服務的開發者互相協商。這樣做在運行時也實現了更好的隔離。例如，一個服務的數據庫加鎖不會影響另外的服務。但是你稍后就會看到在服務間不共享數據庫的弊端，特別是處理數據一致性和跨服務查詢都變得更為復雜。

共享類庫的角色

開發人員經常把一些通用的功能打包到庫或模塊中，以便多個應用程序可以重用它而無須復制代碼。畢竟，如果沒有Maven或npm庫，我們今天的開發工作都會變得更困難。你可能也想在微服務架構中使用共享庫。從表面上看，它似乎是減少服務中代碼重復的好方法。但是你需要確保不會意外地在服務之間引入耦合。

例如，想象一下多個服務需要更新Order業務對象的場景。一種選擇是將該功能打包為可供多個服務使用的庫。一方面，使用庫可以消除代碼重復。另一方面，如果業務需求的變更影響了Order業務對象，開發者需要同時重建和重新部署所有使用了共享庫的服務。更好的選擇是把這些可能會更改的通用功能（例如Order管理）作為服務來實現，而不是共享庫。

你應該努力使用共享庫來實現不太可能改變的功能。例如，在典型的應用程序中，在每個服務中都實現一個通用的Money類（例如用來實現幣種轉換等固定功能）沒有任何意義。相反，你應該創建一個供所有服務使用的共享庫。

服務的大小并不重要

微服務這個術語的一個問題是會將你的關注點錯誤地聚焦在微上。它暗示服務應該非常小。其他基于大小的術語 （如miniservice或nanoservice） 也是如此。實際上，大小不是一個重要的考慮因素。

更好的目標是將精心設計的服務定義為能夠由小團隊開發的服務，并且交付時間最短，與其他團隊協作最少。理論上，團隊可能只負責單一服務，因此服務絕不是微小的。相反，如果服務需要大型團隊或需要很長時間進行測試，那么拆分團隊或服務可能是有意義的。另外，如果你因為其他服務的變更而不斷需要同步更新自己負責的服務，或者你所負責的服務正在觸發其他服務的同步更新，那么這表明服務沒有實現松耦合。你構建的甚至可能是一個分布式的單體。

微服務架構把應用程序通過一些小的、松耦合的服務組織在一起。結果，這樣的架構提升了開發階段的效率，特別是可維護性、可測試性和可部署性，這也就讓組織的軟件開發速度更快。微服務架構也同時提升了應用程序的可擴展性，盡管這不是微服務的主要目標。為了使用微服務架構開發軟件，你首先需要識別服務，并確定它們之間如何協作。現在我們來看看如何定義一個應用程序的微服務架構。

4 總結

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

新聞名稱：JD架構師分享：微服務架構到底是什么東西
地址分享：http://www.js-pz168.com/news31/98081.html

成都網站建設公司_創新互聯，為您提供網站排名、關鍵詞優化、企業建站、網站營銷、網站設計公司、網站收錄

廣告

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