如何在實(shí)踐中將單體架構(gòu)遷移到微服務(wù)

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

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

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

　　決定

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

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

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

　　團(tuán)隊(duì)規(guī)模——隨著團(tuán)隊(duì)的成長，保持凝聚力是一項(xiàng)挑戰(zhàn)。這是可以通過審查團(tuán)隊(duì)的成長來輕松進(jìn)行基準(zhǔn)測試的部分。密切關(guān)注入職速度和其他指標(biāo)，例如解決問題的時間。這些可能是衡量項(xiàng)目復(fù)雜性的最佳指標(biāo)。

　　相互依賴——如果項(xiàng)目高度相互依賴并且沒有明確的分隔線，那么微服務(wù)的好處可能會成為障礙。一些項(xiàng)目本質(zhì)上是深度混合的，并且沒有清晰地分離各個部分。要注意不同模塊之間的事務(wù)完整性。事務(wù)管理等功能不能在微服務(wù)之間進(jìn)行。如果用戶有一個必須可靠一致的系統(tǒng)，例如需要始終保持一致的銀行系統(tǒng)，則事務(wù)的邊界必須位于單個服務(wù)中。這些類型的事情會使遷移過程變得特別困難。

　　測試——如果沒有大量特定于模塊的測試和大量集成測試，就無法進(jìn)行這樣的工作。審查測試代碼將比任何其他方法更能了解準(zhǔn)備情況。那么，在邏輯上能孤立地測試一個模塊嗎?

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

　　從哪里開始?

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

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

　　查看問題跟蹤器/版本控制——哪個模塊最容易出現(xiàn)故障?

　　檢查模塊化——哪個模塊最小且相互依賴最少?數(shù)據(jù)可以清晰地分離嗎?最好從容易實(shí)現(xiàn)的目標(biāo)開始。

　　分析應(yīng)用程序——哪個模塊最昂貴并且可以從擴(kuò)展中受益?

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

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

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

　　當(dāng)可部署服務(wù)宕機(jī)時，系統(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)和實(shí)際代碼中。意外繞過網(wǎng)關(guān)并直接訪問服務(wù)器或底層基礎(chǔ)設(shè)施。這些是在遺留代碼和大型系統(tǒng)中難以檢測到的微妙事物。

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

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

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

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

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

　　沖洗-重復(fù)

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

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

　　其中一些相互依賴關(guān)系可以從代碼中推斷出來并重構(gòu)掉，轉(zhuǎn)換為消息傳遞和異步調(diào)用。使用消息服務(wù)是最有效的解耦方式之一，許多語言和平臺支持各個部分之間的模塊屏障。這可以將整個模塊與應(yīng)用程序的其余部分隔離開來，并將交互限制在一個狹窄的界面中。通過設(shè)置這樣的障礙，可以使用編譯器和IDE來強(qiáng)制執(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àn)證部署是否成功比使用單體應(yīng)用程序更具挑戰(zhàn)性。當(dāng)一切正常時，用戶體驗(yàn)是相似的，但是如何驗(yàn)證呢?

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