?譯者 | 李睿

審校 | 孫淑娟

關(guān)于從單體（Monoliths）架構(gòu)遷移到微服務(wù)架構(gòu)的主題有一些很好的文章，單體架構(gòu)的優(yōu)點和缺點非常簡單。不過可以了解其他事項——策略。構(gòu)建單體是因為它們更容易上手。當(dāng)系統(tǒng)已經(jīng)投入生產(chǎn)時，微服務(wù)通常是出于需要而出現(xiàn)的。

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

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

決定  

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

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

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

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

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

從哪里開始？  

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

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

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

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

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

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

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

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

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

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

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

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

這就是日志和快照的來源?？梢詫⑺鼈兲砑拥胶蠖薃PI以及斷開的服務(wù)中，以驗證得到的結(jié)果確實是來自網(wǎng)關(guān)緩存的結(jié)果。  

沖洗-重復(fù)  

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

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

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

結(jié)語

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

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

這就是工具的用武之地；可以使用開發(fā)人員的可觀察性工具（日志、計數(shù)器、日志）來驗證。即使生產(chǎn)失敗，跨服務(wù)邊界的修復(fù)仍然有效。但這絕非易事，因為松散耦合只是第一步。不同形式的故障期間的行為只能在生產(chǎn)中進行測試，畢意人們不想僅僅為了證明自己的觀點是否正確而導(dǎo)致生產(chǎn)失敗。

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