如果您在設(shè)計大型并發(fā)應(yīng)用程序或者準(zhǔn)備拆解之前的老系統(tǒng)時，我想你第一考慮的是微服務(wù)架構(gòu)方式。

前面我們了解到微服務(wù)架構(gòu)將應(yīng)用程序構(gòu)建為一系列松散耦合的服務(wù)，是為了通過實現(xiàn)持續(xù)交付和靈活部署來加速軟件開發(fā)。

出于很原因，分解很重要

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

在微服務(wù)下，有兩種類型的項目

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

一、按業(yè)務(wù)能力模式分解

為了創(chuàng)建微服務(wù)架構(gòu)，一種策略是基于業(yè)務(wù)能力進(jìn)行分解。作為一家企業(yè)，項目是為了創(chuàng)造價值。例如，在電子商務(wù)業(yè)務(wù)中，訂單管理、庫存管理、支付、運輸?shù)榷忌婕啊?/p>

這種模式有以下好處

1. 業(yè)務(wù)能力比較穩(wěn)定，架構(gòu)依賴的業(yè)務(wù)邏輯比較穩(wěn)定。
2. 開發(fā)團(tuán)隊是跨職能的、自主的，并且圍繞交付業(yè)務(wù)價值而非技術(shù)特性進(jìn)行組織。
3. 服務(wù)是松散耦合和內(nèi)聚的。

二、按子域模式分解

領(lǐng)域驅(qū)動設(shè)計 (DDD) 方法是一種構(gòu)建復(fù)雜軟件應(yīng)用程序的方法，它基于面向?qū)ο箢I(lǐng)域模型的開發(fā)。DDD 為每個子域定義了單獨地域模型。每個子域都屬于一個域。識別子領(lǐng)域與識別業(yè)務(wù)能力的過程比較相似，即分析業(yè)務(wù)和識別專業(yè)領(lǐng)域。最有可能的是，大多數(shù)是業(yè)務(wù)熟悉的子域。領(lǐng)域模型的范圍在 DDD 中稱為有界上下文。有界上下文包括實現(xiàn)模型的代碼組件。

子域可以分類如下

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

這種模式有以下好處

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

三、將單體應(yīng)用程序分解為微服務(wù)時的挑戰(zhàn)

在分解單體應(yīng)用程序時，可能會出現(xiàn)挑戰(zhàn)。

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

四、扼殺者模式

將遺留的單體應(yīng)用程序遷移到微服務(wù)架構(gòu)時，會使用 Strangler 模式。通過用新服務(wù)替換特定功能，可以使用這種模式逐步轉(zhuǎn)換單體應(yīng)用程序。新服務(wù)一旦準(zhǔn)備好，舊組件就被扼殺，新服務(wù)投入使用，而舊組件退役。

單體應(yīng)用最終會縮小功能，而微服務(wù)將接管整體功能。