一文讀懂微服務架構的分解設計

語言: CN / TW / HK

如果您在設計大型併發應用程式或者準備拆解之前的老系統時,我想你第一考慮的是微服務架構方式。

前面我們瞭解到微服務架構將應用程式構建為一系列鬆散耦合的服務,是為了通過實現持續交付和靈活部署來加速軟體開發。

出於很原因,分解很重要

有利於分工和知識共享。使用它,具有特殊知識的多個人(或團隊)可以在一個應用程式上高效地合作。

它描述了多個元素如何互動。

在微服務下,有兩種型別的專案

待重新開發專案—國外譯名:Brownfield projects,是指在現有或遺留系統的背景下開發和部署新的軟體系統。因此,將單體應用程式轉換為微服務是屬於這種型別專案。

新建專案——是指從頭開始為一個全新的系統,而無需使用任何遺留程式碼。當您從頭開始時,沒有任何限制或依賴性。

一、按業務能力模式分解

為了建立微服務架構,一種策略是基於業務能力進行分解。作為一家企業,專案是為了創造價值。例如,在電子商務業務中,訂單管理、庫存管理、支付、運輸等都涉及。

這種模式有以下好處

業務能力比較穩定,架構依賴的業務邏輯比較穩定。

開發團隊是跨職能的、自主的,並且圍繞交付業務價值而非技術特性進行組織。

服務是鬆散耦合和內聚的。

二、按子域模式分解

領域驅動設計 (DDD) 方法是一種構建複雜軟體應用程式的方法,它基於面向物件領域模型的開發。DDD 為每個子域定義了單獨地域模型。每個子域都屬於一個域。識別子領域與識別業務能力的過程比較相似,即分析業務和識別專業領域。最有可能的是,大多數是業務熟悉的子域。領域模型的範圍在 DDD 中稱為有界上下文。有界上下文包括實現模型的程式碼元件。

子域可以分類如下

核心—業務的最大差異化因素和應用程式最有價值的部分,在一些公司經常有核心繫統專案,有核心報價子系統,核心定價子系統等

支援—不是差異化因素,而是與業務提供的內容相關。通常在內部或外包實施。

通用—不特定於業務,最好使用現成的軟體實施。

這種模式有以下好處

子域職能比較穩定,架構相對也比較穩定。

開發團隊(通常會設計到組建虛擬團隊)是跨職能的、自主的,並且專注於交付業務價值而不是技術特性。

服務是鬆散耦合和內聚的。

三、將單體應用程式分解為微服務時的挑戰

在分解單體應用程式時,可能會出現挑戰。

網路延遲—在分散式系統中,網路延遲是一個持續關注的問題。您可能會發現對服務的特定分解會導致兩個服務之間的大量往返。

資料一致性—每個服務都有自己的資料庫,因此維護跨服務的資料一致性會非常困難。

神類(捂臉哭一下)—神類是控制系統中太多其他物件的物件,它超越了邏輯,成為了無所不能的類。由於其規模和複雜性,它是一個集中系統智慧的類,並使用來自其他類的資訊。

四、扼殺者模式

將遺留的單體應用程式遷移到微服務架構時,會使用 Strangler 模式。通過用新服務替換特定功能,可以使用這種模式逐步轉換單體應用程式。新服務一旦準備好,舊元件就被扼殺,新服務投入使用,而舊元件退役。

單體應用最終會縮小功能,而微服務將接管整體功能。