?譯者 | 李睿

審校 | 孫淑娟

關(guān)于從單體（Monoliths）架構(gòu)遷移到微服務(wù)架構(gòu)的主題有一些很好的文章，單體架構(gòu)的優(yōu)點(diǎn)和缺點(diǎn)非常簡(jiǎn)單。不過(guò)可以了解其他事項(xiàng)——策略。構(gòu)建單體是因?yàn)樗鼈兏菀咨鲜帧．?dāng)系統(tǒng)已經(jīng)投入生產(chǎn)時(shí)，微服務(wù)通常是出于需要而出現(xiàn)的。

但是，在決定何時(shí)進(jìn)行遷移時(shí)會(huì)出現(xiàn)很多問(wèn)題——例如如何確定服務(wù)的邊界？如何驗(yàn)證微服務(wù)架構(gòu)的自我修復(fù)特性？  

這對(duì)于服務(wù)網(wǎng)格的分布式方面尤其具有挑戰(zhàn)性。需要將應(yīng)用程序視為它的一部分以便中斷。本文的目標(biāo)是保持在傳統(tǒng)單體應(yīng)用中所擁有的便利，同時(shí)避免與領(lǐng)域相關(guān)的緊密耦合。本文將概述一些在執(zhí)行這一遷移時(shí)可以使用的實(shí)用方法。  

決定  

單體應(yīng)該是一個(gè)模塊組成的整體，所以可以很容易將其分解。人們有一個(gè)將單體稱為“互連代碼塊”的誤區(qū)，但情況遠(yuǎn)非如此。大多數(shù)單體應(yīng)用程序使用現(xiàn)代編程語(yǔ)言（例如包和模塊等）的功能來(lái)分離各個(gè)部分。模塊化單體的各個(gè)部分之間的調(diào)用通過(guò)明確定義的接口或事件總線進(jìn)行。支持單體應(yīng)用程序的立場(chǎng)可能源于Java背景，因?yàn)镴ava特別適合大型單體應(yīng)用程序。根據(jù)其架構(gòu)、語(yǔ)言、問(wèn)題域等，而拆分代碼庫(kù)的點(diǎn)將會(huì)完全不同。  

如何在這方面做出客觀的選擇？何時(shí)是開(kāi)始遷移到微服務(wù)的最佳時(shí)機(jī)？  

微服務(wù)架構(gòu)遷移最重要的前提是授權(quán)分離。如果不將其作為外部服務(wù)進(jìn)行分離，則可能沒(méi)有前進(jìn)的空間。這是微服務(wù)遷移中最難的部分。這樣做的好處是可以在保持單體架構(gòu)的同時(shí)采取這一步。如果無(wú)法執(zhí)行這一遷移，那么繼續(xù)前進(jìn)是沒(méi)有意義的。完成這一操作之后，還涉及其他幾個(gè)因素：  

• 團(tuán)隊(duì)規(guī)模——隨著團(tuán)隊(duì)的成長(zhǎng)，保持凝聚力是一項(xiàng)挑戰(zhàn)。這是可以通過(guò)審查團(tuán)隊(duì)的成長(zhǎng)來(lái)輕松進(jìn)行基準(zhǔn)測(cè)試的部分。密切關(guān)注入職速度和其他指標(biāo)，例如解決問(wèn)題的時(shí)間。這些可能是衡量項(xiàng)目復(fù)雜性的最佳指標(biāo)。  
• 相互依賴——如果項(xiàng)目高度相互依賴并且沒(méi)有明確的分隔線，那么微服務(wù)的好處可能會(huì)成為障礙。一些項(xiàng)目本質(zhì)上是深度混合的，并且沒(méi)有清晰地分離各個(gè)部分。要注意不同模塊之間的事務(wù)完整性。事務(wù)管理等功能不能在微服務(wù)之間進(jìn)行。如果用戶有一個(gè)必須可靠一致的系統(tǒng)，例如需要始終保持一致的銀行系統(tǒng)，則事務(wù)的邊界必須位于單個(gè)服務(wù)中。這些類型的事情會(huì)使遷移過(guò)程變得特別困難。  
• 測(cè)試——如果沒(méi)有大量特定于模塊的測(cè)試和大量集成測(cè)試，就無(wú)法進(jìn)行這樣的工作。審查測(cè)試代碼將比任何其他方法更能了解準(zhǔn)備情況。那么，在邏輯上能孤立地測(cè)試一個(gè)模塊嗎？  

一旦對(duì)這些有所了解，就可以開(kāi)始估計(jì)從單體應(yīng)用到微服務(wù)遷移可能獲得的好處。  

從哪里開(kāi)始？  

假設(shè)單體代碼已經(jīng)相對(duì)模塊化并且支持單點(diǎn)登錄（SSO），可以選擇任何想要的模塊。那么如何知道哪一個(gè)將在大量的時(shí)間和精力投入中獲得最佳回報(bào)？  

在理想情況下，用戶希望定位那些能帶來(lái)最大利益并且最容易遷移的部分：  

• 查看問(wèn)題跟蹤器/版本控制——哪個(gè)模塊最容易出現(xiàn)故障？  
• 檢查模塊化——哪個(gè)模塊最小且相互依賴最少？數(shù)據(jù)可以清晰地分離嗎？最好從容易實(shí)現(xiàn)的目標(biāo)開(kāi)始。  
• 分析應(yīng)用程序——哪個(gè)模塊最昂貴并且可以從擴(kuò)展中受益？  

這些事情在本地運(yùn)行時(shí)非常簡(jiǎn)單，但應(yīng)用程序在生產(chǎn)中的行為通常與其本地或暫存環(huán)境有很大不同。在這些情況下，可以使用開(kāi)發(fā)人員可觀察性工具（例如運(yùn)行時(shí)行計(jì)數(shù)器）來(lái)評(píng)估使用情況。而在選擇要突破的模塊時(shí)，需要在利益和效用之間取得平衡。  

避免微小的單體架構(gòu)  

微服務(wù)用戶將繼續(xù)構(gòu)建不遵循一般規(guī)則的產(chǎn)品。“自我修復(fù)”就是最明顯的例子。將單體應(yīng)用程序解耦成微服務(wù)應(yīng)用程序非常困難。需要隔離各個(gè)部分，并確保一切都在規(guī)模上合理運(yùn)行。或者更糟糕的是在停機(jī)期間進(jìn)行。  

當(dāng)可部署服務(wù)宕機(jī)時(shí)，系統(tǒng)如何生存？如何測(cè)試這樣的產(chǎn)品？  

這種架構(gòu)的最大問(wèn)題之一是部署規(guī)模。將單個(gè)服務(wù)打包在發(fā)現(xiàn)系統(tǒng)和API網(wǎng)關(guān)中，并使用斷路器來(lái)啟用修復(fù)屬性。API網(wǎng)關(guān)和類似服務(wù)通常是基于SaaS的解決方案，但即使用戶自己部署它們，準(zhǔn)確地復(fù)制生產(chǎn)也很困難。典型的復(fù)雜性包括將URL編碼到網(wǎng)關(guān)和實(shí)際代碼中。意外繞過(guò)網(wǎng)關(guān)并直接訪問(wèn)服務(wù)器或底層基礎(chǔ)設(shè)施。這些是在遺留代碼和大型系統(tǒng)中難以檢測(cè)到的微妙事物。  

由于這種復(fù)雜的拓?fù)浣Y(jié)構(gòu)，在本地工作時(shí)幾乎不可能正確測(cè)試愈合行為。由于部署工作大相徑庭，得到的任何結(jié)果都是不準(zhǔn)確的。  

但是不能僅僅為了證明一個(gè)觀點(diǎn)就關(guān)閉生產(chǎn)微服務(wù)。

這是微服務(wù)架構(gòu)的巨大好處之一。在發(fā)現(xiàn)代碼中，可以添加一個(gè)特例，為特定用戶提供“虛擬”或失敗的微服務(wù)。問(wèn)題是這些癥狀可能很難驗(yàn)證，因?yàn)椤白晕倚迯?fù)”服務(wù)看起來(lái)好像正在運(yùn)行。在這種情況下，可以使用日志或快照來(lái)驗(yàn)證代碼是否正確，并且模塊確實(shí)已經(jīng)斷開(kāi)連接。  

例如，可以使用大多數(shù)API網(wǎng)關(guān)來(lái)模擬API的不可用性。然后可以通過(guò)調(diào)用并驗(yàn)證斷路器是否被觸發(fā)，并且其結(jié)果仍然到達(dá)來(lái)檢查其他服務(wù)是否按預(yù)期工作。系統(tǒng)似乎已經(jīng)自我修復(fù)。但也許某些用戶代碼直接調(diào)用了Web服務(wù)并有效地繞過(guò)了API網(wǎng)關(guān)？如何驗(yàn)證緩存中的所有內(nèi)容都正常工作，并使用預(yù)期的回退？

這就是日志和快照的來(lái)源。可以將它們添加到后端API以及斷開(kāi)的服務(wù)中，以驗(yàn)證得到的結(jié)果確實(shí)是來(lái)自網(wǎng)關(guān)緩存的結(jié)果。  

沖洗-重復(fù)  

當(dāng)從單體應(yīng)用程序中分離出第一個(gè)微服務(wù)時(shí)，這個(gè)過(guò)程最具挑戰(zhàn)性。當(dāng)打破額外的部分時(shí)，通常會(huì)變得更容易，直到單體都消失了。但在這一過(guò)程中也存在挑戰(zhàn)。最初，選擇一個(gè)更容易實(shí)現(xiàn)的目標(biāo)。在前進(jìn)的過(guò)程中遇到了更艱巨的挑戰(zhàn)，需要為可能不太理想的服務(wù)確定邊界。  

問(wèn)題是經(jīng)常需要根據(jù)直覺(jué)采取這些步驟。但是當(dāng)創(chuàng)建模塊時(shí)，可能使用了邏輯分離而不是相互依賴。因此，兩個(gè)模塊可能具有深度依賴關(guān)系，并且作為微服務(wù)可能沒(méi)有意義。將它們拆分到不同的位置，甚至將它們捆綁在一起可能更有意義。例如，可能有一個(gè)管理多個(gè)帳戶的會(huì)計(jì)系統(tǒng)。邏輯分離可能會(huì)將在賬戶之間轉(zhuǎn)移資金的代碼移動(dòng)到單獨(dú)的模塊中， 但這會(huì)使事情變得非常困難。在會(huì)計(jì)系統(tǒng)中，資金必須從一個(gè)帳戶到達(dá)并轉(zhuǎn)移到另一個(gè)帳戶；它永遠(yuǎn)不會(huì)“消失”。當(dāng)向一個(gè)帳戶添加資金時(shí)，必須從另一個(gè)帳戶中減去這些資金，并且兩者都需要在一次交易中發(fā)生。一個(gè)簡(jiǎn)單的解決方法可能是在一個(gè)請(qǐng)求中同時(shí)進(jìn)行扣除和資金轉(zhuǎn)移。但是，這并不能解決一般性問(wèn)題，因?yàn)榭梢詮囊粋€(gè)帳戶中提取資金并分成多個(gè)帳戶。在多個(gè)小型操作中執(zhí)行這一操作可能會(huì)導(dǎo)致副作用。這是可行的，在這種情況下，會(huì)將核心會(huì)計(jì)邏輯與賬戶系統(tǒng)保持在一起。

其中一些相互依賴關(guān)系可以從代碼中推斷出來(lái)并重構(gòu)掉，轉(zhuǎn)換為消息傳遞和異步調(diào)用。使用消息服務(wù)是最有效的解耦方式之一，許多語(yǔ)言和平臺(tái)支持各個(gè)部分之間的模塊屏障。這可以將整個(gè)模塊與應(yīng)用程序的其余部分隔離開(kāi)來(lái)，并將交互限制在一個(gè)狹窄的界面中。通過(guò)設(shè)置這樣的障礙，可以使用編譯器和IDE來(lái)強(qiáng)制執(zhí)行模塊限制。 

結(jié)語(yǔ)

分解單體應(yīng)用程序總是具有挑戰(zhàn)性，而將業(yè)務(wù)邏輯隔離到正確的域中需要時(shí)間和精力。特定服務(wù)的通信開(kāi)銷和功能劃分是在這樣的過(guò)程中產(chǎn)生差異的組件。沒(méi)有交付保證，測(cè)試更加困難。由于API網(wǎng)關(guān)、代理設(shè)置、發(fā)現(xiàn)等原因，生產(chǎn)環(huán)境與開(kāi)發(fā)環(huán)境完全不同。

遺留代碼的成功遷移對(duì)客戶來(lái)說(shuō)是無(wú)縫的，它完全改變了動(dòng)態(tài)。交付不同，驗(yàn)證部署是否成功比使用單體應(yīng)用程序更具挑戰(zhàn)性。當(dāng)一切正常時(shí)，用戶體驗(yàn)是相似的，但是如何驗(yàn)證呢？  

這就是工具的用武之地；可以使用開(kāi)發(fā)人員的可觀察性工具（日志、計(jì)數(shù)器、日志）來(lái)驗(yàn)證。即使生產(chǎn)失敗，跨服務(wù)邊界的修復(fù)仍然有效。但這絕非易事，因?yàn)樗缮Ⅰ詈现皇堑谝徊健２煌问降墓收掀陂g的行為只能在生產(chǎn)中進(jìn)行測(cè)試，畢意人們不想僅僅為了證明自己的觀點(diǎn)是否正確而導(dǎo)致生產(chǎn)失敗。

原文標(biāo)題：??Migrating Monoliths to Microservices in Practice???，作者：Shai Almog?