你的團隊決定是時候擺脫那個舊的、笨重的單體了，它運行得很好，但是單體已經(jīng)變得如此之大，以至于你花費更多的精力來維護它而不是添加功能。這里有 12 個技巧，可幫助您盡可能順利地過渡到微服務(wù)。

1.確保你知道你在做什么

重寫從來都不是一件容易的事，但是從單體應(yīng)用到微服務(wù)，你改變的不僅僅是編碼方式；你正在改變公司的運營模式。你不僅需要學(xué)習(xí)一個新的、更復(fù)雜的技術(shù)棧，管理層還需要調(diào)整工作文化，將人員重組為更小的跨職能團隊。

如何最好地重組團隊和公司是值得單獨發(fā)帖的主題。在本文中，我想重點介紹遷移的技術(shù)方面。

首先，在開始之前盡可能多地研究采用微服務(wù)所涉及的權(quán)衡是很重要的。您希望絕對確定微服務(wù)（而不是其他替代解決方案，例如模塊化單體）是適合您的解決方案。

首先學(xué)習(xí)有關(guān)微服務(wù)架構(gòu)的所有知識，并查看一些示例項目以了解其工作原理。這里有些例子

2.制定計劃

拆除單體應(yīng)用需要大量準(zhǔn)備工作，因為舊系統(tǒng)必須在過渡期間保持運行。

遷移步驟可以通過工單進行跟蹤，并像任何其他任務(wù)一樣在每個 sprint 中進行。這不僅有助于獲得動力（實際上有朝一日實現(xiàn)遷移），而且讓業(yè)務(wù)所有者了解團隊如何計劃實施如此大的變化。

在計劃期間，您必須：

• 解開單體內(nèi)部的依賴關(guān)系。
• 確定所需的微服務(wù)。
• 為微服務(wù)設(shè)計數(shù)據(jù)模型。
• 開發(fā)一種在單體和微服務(wù)數(shù)據(jù)庫之間遷移和同步數(shù)據(jù)的方法。
• 設(shè)計 API 并計劃向后兼容。
• 捕獲單體應(yīng)用的基線性能。
• 為新系統(tǒng)的可用性和性能設(shè)定目標(biāo)。

除非您從一個相當(dāng)簡單的單體架構(gòu)遷移，否則您將需要高級技術(shù)，例如領(lǐng)域驅(qū)動設(shè)計 (DDD)。

3.把所有東西都放在一個 monorepo 中

當(dāng)你分解單體時，大量代碼將從單體中移出并轉(zhuǎn)移到新的微服務(wù)中。monorepo可幫助您跟蹤這些類型的更改。此外，將所有東西放在一個地方可以幫助您更快地從故障中恢復(fù)。

您的單體應(yīng)用很可能已經(jīng)包含在一個存儲庫中。因此，只需為微服務(wù)創(chuàng)建新文件夾即可。

4.使用共享 CI 管道

在開發(fā)過程中，您不僅會不斷推出新的微服務(wù)，還會重新部署單體應(yīng)用。這個過程越快、越輕松，你的進步就越快。設(shè)置持續(xù)集成和交付(CI/CD) 以自動測試和部署代碼。

如果您使用 monorepo 進行開發(fā)，則必須牢記以下幾點：

• 通過啟用基于更改的執(zhí)行或使用單存儲庫感知構(gòu)建工具（例如Bazel或Pants ）來保持管道快速。通過僅對更新的代碼運行更改，這將使您的管道更加高效。
• 配置多個促銷，每個微服務(wù)一個，一個單體。使用這些促銷活動進行持續(xù)部署。

配置測試報告以快速發(fā)現(xiàn)和排除故障。

5.確保你有足夠的測試

當(dāng)我們確定代碼沒有回歸時，重構(gòu)會更加令人滿意和有效。自動化測試讓您有信心持續(xù)發(fā)布單體更新。

一個很好的起點是測試金字塔。您將需要大量的單元測試、一些集成測試和一些驗收測試。

旨在像在持續(xù)集成管道中一樣經(jīng)常在本地開發(fā)機器上運行測試。

6.安裝 API 網(wǎng)關(guān)或 HTTP 反向代理

隨著微服務(wù)的部署，您必須隔離傳入流量。遷移的功能由新服務(wù)提供，而尚未準(zhǔn)備好的功能由單體提供。

有幾種路由請求的方法，具體取決于它們的性質(zhì)：

• API 網(wǎng)關(guān)允許您根據(jù)經(jīng)過身份驗證的用戶、cookie、功能標(biāo)志或 URI 模式等條件轉(zhuǎn)發(fā) API 調(diào)用。
• HTTP 反向代理的作用相同，但針對的是 HTTP 請求。在大多數(shù)情況下，單體實現(xiàn)了 UI，因此大多數(shù)流量都會流向那里，至少一開始是這樣。

使用 API 網(wǎng)關(guān)和 HTTP 反向代理將請求路由到適當(dāng)?shù)亩它c。您可以在非常細(xì)粒度的級別上在單體和微服務(wù)之間切換。

遷移完成后，網(wǎng)關(guān)和代理將保留——它們是任何微服務(wù)應(yīng)用程序的標(biāo)準(zhǔn)組件，因為它們提供轉(zhuǎn)發(fā)和負(fù)載平衡。如果服務(wù)出現(xiàn)故障，它們還可以充當(dāng)斷路器。

7.考慮一體成型的模式

好的，這僅適用于您計劃將容器或 Kubernetes 用于微服務(wù)的情況。在這種情況下，容器化可以幫助您實現(xiàn)基礎(chǔ)架構(gòu)的同質(zhì)化。一體式整體模式包括在 Docker 等容器內(nèi)運行整體。

如果您以前從未使用過容器，那么這是熟悉該技術(shù)的好機會。這樣一來，您就離了解 Kubernetes 更近了一步。要學(xué)習(xí)的東西很多，所以要為陡峭的學(xué)習(xí)曲線做好計劃：

• 了解 Docker 和容器。
• 在容器中運行你的單體應(yīng)用。
• 在容器中開發(fā)和運行您的微服務(wù)。
• 完成遷移并掌握容器后，了解 Kubernetes。
• 隨著工作的進展，您可以擴展微服務(wù)并逐漸將流量轉(zhuǎn)移到它們。

容器化單體應(yīng)用是標(biāo)準(zhǔn)化部署的一種方式，也是學(xué)習(xí) Kubernetes 的絕佳第一步。

8.熱身于變化

習(xí)慣微服務(wù)需要時間，所以最好從小處著手，為新范式做好準(zhǔn)備。留出足夠的時間讓每個人都進入正確的心態(tài)、提高技能并從錯誤中吸取教訓(xùn)，而不會受到最后期限的壓力。

在這些初步的初步步驟中，您將學(xué)到很多關(guān)于分布式計算的知識。您必須處理云 SLA，為您自己的服務(wù)設(shè)置 SLA，實施監(jiān)控和警報，定義跨團隊通信的渠道，并決定部署策略。

選擇一些容易開始的東西，比如與單體架構(gòu)的其余部分幾乎沒有重疊的邊緣服務(wù)。例如，您可以先構(gòu)建身份驗證微服務(wù)并路由登錄請求。

選擇一些容易開始的東西，比如簡單的邊緣服務(wù)。

9.使用功能標(biāo)志

功能標(biāo)志是一種無需重新部署即可更改系統(tǒng)功能的軟件技術(shù)。您可以使用功能標(biāo)志在遷移時打開和關(guān)閉部分單體應(yīng)用、試驗替代配置或運行 A/B 測試。

啟用功能標(biāo)志的遷移的典型工作流程是：

• 確定要遷移到微服務(wù)的單體功能的一部分。
• 用功能標(biāo)志包裝功能。重新部署單體。
• 構(gòu)建和部署微服務(wù)。
• 測試微服務(wù)。
• 一旦滿意，通過關(guān)閉該功能來禁用單體應(yīng)用上的該功能。
• 重復(fù)直到遷移完成。

因為功能標(biāo)志允許我們將非活動代碼部署到生產(chǎn)環(huán)境并隨時切換它，所以我們可以將功能發(fā)布與實際部署分離。這為開發(fā)人員提供了極大的靈活性和控制力。

10.模塊化單體

如果你的單體應(yīng)用是一堆代碼，那么一旦遷移完成，你很可能會得到一堆分布式代碼。就像在全面翻新之前收拾房子一樣，模塊化整體結(jié)構(gòu)是必要的準(zhǔn)備步驟。

模塊化單體是一種軟件開發(fā)模式，由獨立且可互換的垂直堆疊模塊組成。與模塊化單體相反的是經(jīng)典的 N 層或分層單體。

分層的單體很難解開——代碼往往有太多的依賴關(guān)系（有時是循環(huán)的），使得更改難以實現(xiàn)。

模塊化單體是微服務(wù)的下一個最佳選擇，也是邁向微服務(wù)的墊腳石。規(guī)則是模塊只能通過公共 API 進行通信，默認(rèn)情況下一切都是私有的。因此，代碼的交織更少，關(guān)系易于識別，依賴關(guān)系清晰。

有兩種模式可以幫助你重構(gòu)單體：Strangler Fig 和 Anticorruption Layer。

Strangler Fig 

在Strangler Fig模式中，我們將整體重構(gòu)從邊緣到中心。我們在邊緣咀嚼，逐步重寫孤立的功能，直到整體重做。

模塊之間的調(diào)用通過“扼殺外觀”進行路由，該外觀模擬和解釋遺留代碼的輸入和輸出。一點一點地，模塊被創(chuàng)建并慢慢取代舊的單體。

單體是一次模塊化的。最終，舊的巨石消失了，取而代之的是新的。

反腐敗層模式

您會發(fā)現(xiàn)，在某些情況下，當(dāng)您重構(gòu)整體時，一個模塊中的更改會傳播到其他模塊。為了解決這個問題，您可以在快速變化的模塊之間創(chuàng)建一個轉(zhuǎn)換層。此防腐敗層可防止一個模塊中的更改影響其余模塊。

反腐敗層通過轉(zhuǎn)換模塊和單體之間的調(diào)用來防止更改傳播。

11.解耦數(shù)據(jù)

超級強大的微服務(wù)使您能夠隨時部署任何微服務(wù)，而與其他微服務(wù)幾乎沒有協(xié)調(diào)。這就是為什么必須不惜一切代價避免數(shù)據(jù)耦合的原因，因為它會在服務(wù)之間產(chǎn)生依賴關(guān)系。每個微服務(wù)都必須有一個私有且獨立的數(shù)據(jù)庫。

意識到您必須將單體應(yīng)用的共享數(shù)據(jù)庫非規(guī)范化為（通常是冗余的）較小的數(shù)據(jù)庫，這可能會令人震驚。但數(shù)據(jù)局部性最終將讓微服務(wù)自主工作。

上圖是將數(shù)據(jù)解耦到獨立的數(shù)據(jù)庫中。

解耦后，您必須安裝機制以在轉(zhuǎn)換過程中保持新舊數(shù)據(jù)同步。例如，您可以設(shè)置數(shù)據(jù)鏡像服務(wù)或更改代碼，以便將事務(wù)寫入兩組數(shù)據(jù)庫。

在開發(fā)過程中使用數(shù)據(jù)復(fù)制來保持表同步。

12.添加可觀察性

新系統(tǒng)必須比舊系統(tǒng)更快、性能更高、可擴展性更強。否則，為什么要打擾微服務(wù)呢？

您需要一個基線來比較舊的和新的。在開始遷移之前，請確保您有良好的指標(biāo)和日志可用。安裝一些集中式日志記錄和監(jiān)控服務(wù)可能是一個好主意，因為它是任何微服務(wù)應(yīng)用程序可觀察性的關(guān)鍵組件。

結(jié)論

微服務(wù)之旅絕非易事。但我希望通過這些提示，您可以節(jié)省一些時間和挫敗感。

請記住以小增量進行迭代，利用 CI/CD 來保證單體應(yīng)用程序正在接受回歸測試，并將所有內(nèi)容保存在一個存儲庫中，以便在出現(xiàn)問題時隨時回退。

banq注：該文以小增量小心翼翼謹(jǐn)慎的方式重構(gòu)原來系統(tǒng)，但是沒有充分認(rèn)識到單體與微服務(wù)是兩種完全不同風(fēng)格的架構(gòu)，是南轅北轍的戰(zhàn)略方向性區(qū)別，為什么？因為微服務(wù)比單體切分更小，如何?。渴且罁?jù)DDD有界上下文去切分的，而上下文需要從戰(zhàn)略大背景大景觀圖下考慮的，所以，是團隊認(rèn)知上對業(yè)務(wù)理解巨大升遷，變革，這種忽然開朗的結(jié)果往往是方向上南北大區(qū)別，而摸著石頭過河的小增量重構(gòu)只適合方向未定或方向大概沒有偏向情況下。

這種重構(gòu)是聽上去很有道理，但是完全不實用，從單體到微服務(wù)的遷移，不只是技術(shù)上的變化，還有業(yè)務(wù)知識的進步，更可能是團隊徹底改變。新團隊能忍受在舊思維舊單體下委曲求全嗎？