微服務架構 - 簡介



微服務是一種基於服務的應用程式開發方法。在這種方法中,大型應用程式將被分解成最小的獨立服務單元。微服務是透過將整個應用程式劃分為相互連線的服務集合來實現面向服務架構 (SOA) 的過程,其中每個服務只服務於一個業務需求。

微型化的概念

在面向服務架構中,整個軟體包將被細分為小型、相互連線的業務單元。這些小型業務單元將使用不同的協議相互通訊,從而為客戶提供成功的業務。現在問題是,微服務架構 (MSA) 與 SOA 有何不同?簡單來說,SOA 是一種設計模式,而微服務是實現 SOA 的一種實現方法,或者可以說微服務是一種 SOA。

以下是我們在開發面向微服務的應用程式時需要注意的一些規則。

  • 獨立性 - 每個微服務都應該是獨立部署的。

  • 耦合性 - 所有微服務都應該鬆散耦合,這樣在一個微服務中的更改不會影響其他微服務。

  • 業務目標 - 整個應用程式的每個服務單元都應該是最小的,並且能夠實現一個特定的業務目標。

讓我們以一個線上購物入口網站為例,深入瞭解微服務。現在,讓我們將這個整個電子商務入口網站分解成小型業務單元,例如使用者管理、訂單管理、結賬、支付管理、配送管理等。一個成功的訂單需要在特定時間範圍內透過所有這些模組。以下是與一個電子商務系統相關的不同業務單元的綜合影像。

Electronic Commerce Solutions

每個業務模組都應該有其自身的業務邏輯和利益相關者。它們為了某些特定需求與其他第三方供應商軟體進行通訊,也彼此之間進行通訊。例如,訂單管理可以與使用者管理通訊以獲取使用者資訊。

現在,假設您正在執行一個包含前面提到的所有業務單元的線上購物入口網站,您確實需要一個包含不同層(例如前端、後端、資料庫等)的企業級應用程式。如果您的應用程式沒有擴充套件並且完全在一個 WAR 檔案中開發,那麼它將被稱為典型的單體應用程式。根據 IBM 的說法,典型的單體應用程式在內部應該具有以下模組結構,其中只有一個端點或應用程式負責處理所有使用者請求。

Database

在上圖中,您可以看到不同的模組,例如用於儲存不同使用者和業務資料的資料庫。在前端,我們有不同的裝置,我們通常在這些裝置上呈現使用者或業務資料以供使用。在中間,我們有一個包,它可以是一個可部署的 EAR 或 WAR 檔案,它接受來自使用者端的請求,在資源的幫助下處理它,然後將其呈現回用戶。在業務需要上述示例中的任何更改之前,一切都會很好。

考慮以下根據業務需求更改應用程式的場景。

業務部門需要對“搜尋”模組進行一些更改。然後,您需要更改整個搜尋過程並重新部署您的應用程式。在這種情況下,您正在重新部署其他單元,而沒有任何更改。

Business Unit

現在,您的業務部門再次需要對“結賬”模組進行一些更改,以包含“錢包”選項。您現在必須更改您的“結賬”模組並將相同的模組重新部署到伺服器。請注意,您正在重新部署軟體包的不同模組,而我們對此沒有任何更改。這就是面向服務架構的概念,更具體地說,是微服務架構的概念。我們可以以這樣一種方式開發我們的單體應用程式,即軟體的每個模組都將作為一個獨立單元執行,能夠獨立處理單個業務任務。

考慮以下示例。

在上述架構中,我們沒有建立任何具有緊湊端到端服務的 EAR 檔案。相反,我們透過將軟體的不同部分公開為服務來劃分它們。軟體的任何部分都可以透過使用各自的服務輕鬆地相互通訊。這就是微服務在現代 Web 應用程式中發揮重要作用的方式。

讓我們按照微服務的思路比較我們的購物車示例。我們可以將我們的購物車分解成不同的模組,例如“搜尋”、“篩選”、“結賬”、“購物車”、“推薦”等。如果我們想要構建一個購物車入口網站,那麼我們必須以這樣一種方式構建上述模組,使它們能夠相互連線,從而為您提供 24x7 的良好購物體驗。

優點和缺點

以下是使用微服務而不是單體應用程式的一些優點。

優點

  • 體積小 - 微服務是 SOA 設計模式的實現。建議您儘可能保持服務的精簡。基本上,一個服務不應該執行多個業務任務,因此它顯然比任何其他單體應用程式都更小且更容易維護。

  • 專注性 - 如前所述,每個微服務都旨在僅執行一項業務任務。在設計微服務時,架構師應該關注服務的焦點,即其可交付成果。根據定義,一個微服務應該本質上是全棧的,並且應該致力於交付唯一的業務屬性。

  • 自主性 - 每個微服務都應該是整個應用程式的自主業務單元。因此,應用程式變得更加鬆散耦合,這有助於降低維護成本。

  • 技術異構性 - 微服務支援不同的技術在單個業務單元中相互通訊,這有助於開發人員在正確的地方使用正確的技術。透過實現異構系統,可以獲得最大的安全性和速度,並構建可擴充套件的系統。

  • 彈性 - 彈性是隔離軟體單元的屬性。微服務在構建方法中遵循高水平的彈性,因此當一個單元出現故障時,它不會影響整個業務。彈性是另一個實現高度可擴充套件和鬆散耦合系統的屬性。

  • 易於部署 - 由於整個應用程式被細分為小的單元,每個元件都應該是全棧的。與同類型的其他單體應用程式不同,所有這些都可以在任何環境中非常輕鬆地部署,時間複雜度更低。

以下是微服務架構的一些缺點。

缺點

  • 分散式系統 - 由於技術異構性,將使用不同的技術來開發微服務的不同部分。需要大量的熟練專業人員來支援這個大型異構分散式軟體。因此,分散式和異構性是使用微服務的主要缺點。

  • 成本 - 微服務成本很高,因為您必須為不同的業務任務維護不同的伺服器空間。

  • 企業就緒性 - 微服務架構可以被認為是不同技術的集合,因為技術日新月異。因此,與傳統的軟體開發模型相比,很難使微服務應用程式達到企業就緒狀態。

微服務優於 SOA

下表列出了 SOA 和微服務的某些特性,突出了使用微服務優於 SOA 的重要性。

元件 SOA 微服務
設計模式 SOA 是一種計算機軟體設計範例,其中軟體元件以服務的形式向外部世界公開以供使用。 微服務是 SOA 的一部分。它是 SOA 的一種專門實現。
依賴性 業務單元相互依賴。 所有業務單元都是相互獨立的。
大小 軟體大小大於傳統軟體。 軟體大小較小。
技術 技術棧少於微服務。 微服務本質上是異構的,因為使用精確的技術來執行特定任務。微服務可以被認為是許多技術的集合。
自主性和焦點 SOA 應用程式構建用於執行多個業務任務。 微服務應用程式構建用於執行單個業務任務。
性質 單體性質。 全棧性質。
部署 部署耗時。 部署非常容易。因此,它將不那麼費時。
成本效益 更具成本效益。 成本效益較低。
可擴充套件性 與微服務相比較低。 完全可擴充套件。
示例 讓我們考慮一個線上計程車預訂應用程式。如果我們想使用 SOA 構建該應用程式,則其軟體單元將是:
  • GetPayments 和 DriverInformation 和 MappingDataAPI
  • AuthenticateUsersAnd DriversAPI
如果使用微服務架構構建相同的應用程式,則其 API 將是:
  • SubmitPaymentsService
  • GetDriverInfoService
  • GetMappingDataService
  • AuthenticateUserService
  • AuthenticateDriverService
廣告
© . All rights reserved.