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

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

出于很原因，分解很重要

• 有利于分工和知識共享。使用它，具有特殊知識的多個人（或團隊）可以在一個應用程序上高效地合作。
• 它描述了多個元素如何交互。

在微服務下，有兩種類型的項目

1. 待重新開發項目—國外譯名：Brownfield projects，是指在現有或遺留系統的背景下開發和部署新的軟件系統。因此，將單體應用程序轉換為微服務是屬于這種類型項目。
2. 新建項目——是指從頭開始為一個全新的系統，而無需使用任何遺留代碼。當您從頭開始時，沒有任何限制或依賴性。

一、按業務能力模式分解

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

這種模式有以下好處

1. 業務能力比較穩定，架構依賴的業務邏輯比較穩定。
2. 開發團隊是跨職能的、自主的，并且圍繞交付業務價值而非技術特性進行組織。
3. 服務是松散耦合和內聚的。

二、按子域模式分解

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

子域可以分類如下

1. 核心—業務的最大差異化因素和應用程序最有價值的部分，在一些公司經常有核心系統項目，有核心報價子系統，核心定價子系統等
2. 支持—不是差異化因素，而是與業務提供的內容相關。通常在內部或外包實施。
3. 通用—不特定于業務，最好使用現成的軟件實施。

這種模式有以下好處

1. 子域職能比較穩定，架構相對也比較穩定。
2. 開發團隊(通常會設計到組建虛擬團隊)是跨職能的、自主的，并且專注于交付業務價值而不是技術特性。
3. 服務是松散耦合和內聚的。

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

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

1. 網絡延遲—在分布式系統中，網絡延遲是一個持續關注的問題。您可能會發現對服務的特定分解會導致兩個服務之間的大量往返。
2. 數據一致性—每個服務都有自己的數據庫，因此維護跨服務的數據一致性會非常困難。
3. 神類(捂臉哭一下)—神類是控制系統中太多其他對象的對象，它超越了邏輯，成為了無所不能的類。由于其規模和復雜性，它是一個集中系統智能的類，并使用來自其他類的信息。

四、扼殺者模式

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

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