譯者 | 朱鋼

策劃 | 云昭

微服務(wù)架構(gòu)設(shè)計(jì)中，如何拆分單體是一件非常重要且令架構(gòu)師十分頭疼的問題。在這篇文章中，會展現(xiàn)一些關(guān)于如何準(zhǔn)備和執(zhí)行單體應(yīng)用程序拆分的思路和步驟說明。

概述

單體拆分必須追求的一些目標(biāo)：不僅僅是拆分，而是通過拆分獲得一些收益。 如果考慮到拆分的成本和效果，可能其他一些方法（例如應(yīng)用程序擴(kuò)展或數(shù)據(jù)庫硬件更新）可能更可取。

要實(shí)現(xiàn)的另一個好處的例子可能只是應(yīng)用程序現(xiàn)代化。 然而這里是一個或多或少正式的單體拆分方式，它試圖考慮拆分的原因和目標(biāo)。 當(dāng)然這不是教條，你可以找到幾種拆分的方法。 此遷移路線圖旨在將單體應(yīng)用程序遷移到微服務(wù)以此獲得微服務(wù)的優(yōu)勢，而不會（或極?。┰斐蓱?yīng)用程序不可用。

明確基準(zhǔn)線

由于應(yīng)用程序支持性，單體應(yīng)用程序可能看起來非?；靵y，但這是意料之中的。 最好的情況是，期待一個帶有大量調(diào)整的大型耦合分層應(yīng)用程序。 無論如何，第一步是你需要收集有關(guān)當(dāng)前應(yīng)用程序的所有信息：需求、用例、ASR、組件、部署圖等。

理解應(yīng)用程序（整體）

在大多數(shù)情況下，應(yīng)用程序缺少文檔，這些文檔可能描述了基準(zhǔn)線，那么你至少需要收集以下信息：

• 應(yīng)用程序的功能模塊、它們之間的關(guān)系和外部環(huán)境；
• API和服務(wù)接口描述；
• 帶有模塊描述的組件圖就足夠了。這是因?yàn)樵诖蠖鄶?shù)情況下，拆分將按照功能或換句話說應(yīng)用程序功能執(zhí)行；
• 部署圖，顯示物理硬件以及系統(tǒng)和軟件配置。這是因?yàn)橐恍㎞RF可能會受到部署的影響（例如，故障隔離的可擴(kuò)展性）。

理解數(shù)據(jù)

為什么數(shù)據(jù)圖表和潛在數(shù)據(jù)映射很重要？ 在大多數(shù)情況下，微服務(wù)將與底層數(shù)據(jù)和數(shù)據(jù)庫一起抽取。雜亂無章的數(shù)據(jù)可能會影響此類 NRF 的性能。 在任何情況下，它都有助于發(fā)現(xiàn)潛在的問題，例如數(shù)據(jù)缺乏或過多、數(shù)據(jù)混亂以及使用某些微服務(wù)進(jìn)行數(shù)據(jù)抽取的邊界。

理解上下文

在某些情況下，需要抽取的功能可能已經(jīng)作為單獨(dú)的外部服務(wù)存在了。不需要抽取一些業(yè)務(wù)能力，只需要復(fù)用一些已經(jīng)存在的外部服務(wù)。像 TTM 這樣的微服務(wù)優(yōu)勢可以用更少的努力來實(shí)現(xiàn)。

理解用戶

這雖然與上下文重疊，但顯示了用戶/外部系統(tǒng)是如何使用應(yīng)用程序的，以便了解使用什么功能以及如何使用，也許應(yīng)用程序的某些部分已過時(shí)且未使用。  

其余關(guān)于應(yīng)用程序的信息將用于做出決策并顯示拆分的必要性，如何拆分以及抽取什么。

為什么要拆分單體?

可能很難回答為什么我們需要將單體應(yīng)用拆分為微服務(wù)，答案可以更加面向業(yè)務(wù)或更加面向技術(shù)。在大多數(shù)情況下，企業(yè)是看不到將單體架構(gòu)重構(gòu)或拆分為微服務(wù)的任何好處。

業(yè)務(wù)驅(qū)動

乍一看，可以找到以下先決條件，但列表可能會擴(kuò)大。 無論如何，業(yè)務(wù)驅(qū)動都是與增加收入和減少損失有關(guān)的，因此新的項(xiàng)目都只會從這兩個問題中衍生出來。  

• 縮短上市時(shí)間
• 降低 TCO：僅擴(kuò)展必要的部分
• 減少損失：彈性、高可用性和容錯解決方案、測試覆蓋率
• 提供更好的用戶體驗(yàn)

此外，一些奇怪的卻動力可能默默地出現(xiàn)，但不會展現(xiàn)出來：它很主流并且也拆散了整體。

技術(shù)驅(qū)動

技術(shù)驅(qū)動只是擴(kuò)展了業(yè)務(wù)驅(qū)動的列表，可能如下所示:

• 擺脫過時(shí)的技術(shù)并順利遷移到現(xiàn)代/受支持的技術(shù)
• 降低復(fù)雜性
• 提高可支持性
• 提高測試覆蓋率
• 可重用性
• 透明且可預(yù)測的變化
• 團(tuán)隊(duì)重用

微服務(wù)的優(yōu)勢

下面提供了微服務(wù)的好處以及它們?nèi)绾螡M足業(yè)務(wù)和技術(shù)需求。 當(dāng)然，表格可以通過幾個額外的微服務(wù)好處進(jìn)行擴(kuò)展，但它們大多是派生出來的，并與表格內(nèi)容重疊。

記住優(yōu)勢的同時(shí)，也請不要忘記缺點(diǎn)。

拆分步驟

1、準(zhǔn)備

以下是或多或少拆分單體應(yīng)用的正式步驟。這些步驟可能會根據(jù)業(yè)務(wù)需求、單體狀態(tài)、CI/CD 程序等進(jìn)行調(diào)整。

在建立基線時(shí)早期獲得的模塊/服務(wù)列表應(yīng)圍繞業(yè)務(wù)能力進(jìn)行組織，并且可能更深一層。例如欺詐檢測系統(tǒng)和促銷服務(wù)可能需要地址。

可以在拆分過程的中間實(shí)現(xiàn)期望的目標(biāo)。從業(yè)務(wù)的角度來看，這可能是件好事，但從技術(shù)的角度來看，繼續(xù)使用包含多個抽取服務(wù)的單體應(yīng)用程序就很糟糕。  

2、重構(gòu)優(yōu)先

需要拆分的應(yīng)用程序幾乎不可能具備良好的形態(tài)。因此可能會在單體應(yīng)用中執(zhí)行幾輪服務(wù)重構(gòu)，一些服務(wù)可能正在重構(gòu)中，而另一個正在抽取中。  

3、典型的分層應(yīng)用

這是服務(wù)抽取的起點(diǎn)，此時(shí)應(yīng)用程序的主要層，如控制器、應(yīng)用程序服務(wù)、DAO 等，是可觀察和可理解的。

4、服務(wù)/功能邊界和 API

DDD 可能有助于定義服務(wù)邊界，但我們需要從現(xiàn)有應(yīng)用程序中提取業(yè)務(wù)功能，而不是對業(yè)務(wù)模型進(jìn)行建模。只需開始將業(yè)務(wù)功能映射到現(xiàn)有的應(yīng)用程序服務(wù)和域模型中以識別服務(wù)邊界即可。

在分層應(yīng)用程序中，控制器可以描述要提取的 API。API 可能會被調(diào)整/擴(kuò)展，但這里的重點(diǎn)是整個應(yīng)用程序必須與服務(wù)一起工作，并且更改最少。更改與我們需要使用抽取功能（代理和外觀）的原因和方式有關(guān)。

5、創(chuàng)建服務(wù)facade

當(dāng)定義服務(wù)邊界時(shí)需要改變與功能交互的方式，而不是處理一組代表業(yè)務(wù)功能的應(yīng)用程序服務(wù)，我們需要在單體應(yīng)用程序中創(chuàng)建一個外觀并通過facade工作。

換句話說，我們需要在提取服務(wù)之前獲得一個松散耦合的單體。

6、重構(gòu)數(shù)據(jù)

使用數(shù)據(jù)庫抽取一項(xiàng)服務(wù)可能會影響單體應(yīng)用的多個不同服務(wù)。所以只能通過 API 訪問服務(wù)數(shù)據(jù)，而不是通過數(shù)據(jù)庫。因此，由于直接訪問了數(shù)據(jù)，即使是一個服務(wù)的提取，也可能需要大量工作。  

7、停止將新功能寫入單體應(yīng)用程序

拆分到微服務(wù)和向解決方案中添加新功能著兩個活動并行執(zhí)行，這是一種常見的情況，因此從一開始就將新功能創(chuàng)建為單獨(dú)的微服務(wù)是有意義的。

8、拆分

大多數(shù)情況下，所有準(zhǔn)備步驟都應(yīng)在實(shí)際拆分之前完成。應(yīng)用程序應(yīng)呈現(xiàn)為松散耦合的單體，具有細(xì)粒度的服務(wù)、良好描述的 API 和邊界以及每個服務(wù)的隔離數(shù)據(jù)（避免跨數(shù)據(jù)庫共享數(shù)據(jù)）。

9、優(yōu)先提取服務(wù)

更正確的做法是不進(jìn)行服務(wù)抽取，而是進(jìn)行業(yè)務(wù)特征抽取。嘗試按業(yè)務(wù)能力/領(lǐng)域?qū)ΜF(xiàn)有應(yīng)用進(jìn)行重組/重構(gòu)/分組，每個應(yīng)用可能包含多個應(yīng)用服務(wù)。

潛在的優(yōu)先標(biāo)準(zhǔn):

• 最常更改的服務(wù)：最小化對部署的影響。
• 可能被第三方服務(wù)取代的服務(wù)：只是為了讓代碼庫更輕量級。
• 需要擴(kuò)展的服務(wù)：優(yōu)化性能。
• 與整個單體耦合：使代碼庫更輕巧且更易于理解。
• 服務(wù)的復(fù)雜性：收集經(jīng)驗(yàn)、建立CI/CD流程、溝通方式等。

清單可能會不同， 可能添加諸如將底層數(shù)據(jù)庫模型從關(guān)系數(shù)據(jù)庫模型更改為 NoSQL、技術(shù)更改（編程語言）、團(tuán)隊(duì)利用率等標(biāo)準(zhǔn)。

結(jié)果，可以選擇至少一項(xiàng)服務(wù)進(jìn)行提取。

10、選擇微服務(wù)之間的通信方式

這不是一個非常復(fù)雜的步驟。但是我們不僅需要選擇協(xié)議和序列化類型，還需要考慮云提供商的限制（即廣播支持）。在大多數(shù)情況下，REST 或 gRPC 是請求-響應(yīng)同步通信的首選方式。這是由于相對簡單、團(tuán)隊(duì)經(jīng)驗(yàn)、不同工具的支持等原因。很難想象新的或抽取的微服務(wù)使用干凈的 TCP。

基于消息的通信方式由于異步性、單向（當(dāng)然可以使用“reply to”機(jī)制，但會導(dǎo)致服務(wù)耦合）等原因，不能被視為請求-響應(yīng)的替代方案。異步適用于事件源（即發(fā)即棄），也適用于消費(fèi)者構(gòu)建自己的世界圖景。一個例子是關(guān)于成功付款的通知將反映在訂單履行系統(tǒng)中以組裝交付和財(cái)務(wù)系統(tǒng)，可以使用 SQS、Kafka 或其他一些消息傳遞服務(wù)。 

11、實(shí)施服務(wù)

使用選定的通信方法、擁有的數(shù)據(jù)庫等實(shí)現(xiàn)微服務(wù)。創(chuàng)建一個用于測試目的的服務(wù)模擬來測試單體和其他相關(guān)微服務(wù)是有意義的。

12、創(chuàng)建服務(wù)代理

創(chuàng)建具有額外責(zé)任的服務(wù)代理。在單體應(yīng)用中使用服務(wù)或使用抽取服務(wù)，暗示代理可用于與刪除/抽取的微服務(wù)進(jìn)行通信。

該代理將允許在單體應(yīng)用中的現(xiàn)有服務(wù)實(shí)現(xiàn)和抽取的服務(wù)之間輕松切換。可以使用canary發(fā)布方法。

13、切換到微服務(wù)

經(jīng)過測試，在生產(chǎn)環(huán)境中進(jìn)行測試的canary發(fā)布僅對微服務(wù)使用和從舊代碼中清理單體應(yīng)用有意義。

檢查是否達(dá)到了初始目標(biāo)，并決定停止或繼續(xù)拆分過程。在繼續(xù)的情況下，你需要選擇下一個特征并執(zhí)行提取。

譯者介紹

朱鋼，51CTO社區(qū)編輯，2019年CSDN博客專家20強(qiáng)，2020年騰訊云+社區(qū)優(yōu)秀作者，10年一線開發(fā)經(jīng)驗(yàn)，曾參與獵頭服務(wù)網(wǎng)站架構(gòu)設(shè)計(jì)，企業(yè)智能客服以及大型電子政務(wù)系統(tǒng)開發(fā)，主導(dǎo)某大型央企內(nèi)部防泄密和電子文檔安全監(jiān)控系統(tǒng)的建設(shè)，目前在BIM頭部企業(yè)從事招投標(biāo)軟件開發(fā)。

原文標(biāo)題：??Split the Monolith: What, When, How??，作者：Igor Azarny