關于從單體(Monoliths)架構遷移到微服務架構的主題有一些很好的文章，單體架構的優點和缺點非常簡單。不過可以了解其他事項——策略。構建單體是因為它們更容易上手。當系統已經投入生產時，微服務通常是出于需要而出現的。

　　但是，在決定何時進行遷移時會出現很多問題——例如如何確定服務的邊界?如何驗證微服務架構的自我修復特性?

　　這對于服務網格的分布式方面尤其具有挑戰性。需要將應用程序視為它的一部分以便中斷。本文的目標是保持在傳統單體應用中所擁有的便利，同時避免與領域相關的緊密耦合。本文將概述一些在執行這一遷移時可以使用的實用方法。

　　決定

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

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

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

　　團隊規模——隨著團隊的成長，保持凝聚力是一項挑戰。這是可以通過審查團隊的成長來輕松進行基準測試的部分。密切關注入職速度和其他指標，例如解決問題的時間。這些可能是衡量項目復雜性的最佳指標。

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

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

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

　　從哪里開始?

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

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

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

　　檢查模塊化——哪個模塊最小且相互依賴最少?數據可以清晰地分離嗎?最好從容易實現的目標開始。

　　分析應用程序——哪個模塊最昂貴并且可以從擴展中受益?

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

　　避免微小的單體架構

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

　　當可部署服務宕機時，系統如何生存?如何測試這樣的產品?

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

　　由于這種復雜的拓撲結構，在本地工作時幾乎不可能正確測試愈合行為。由于部署工作大相徑庭，得到的任何結果都是不準確的。

　　但是不能僅僅為了證明一個觀點就關閉生產微服務。

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

　　例如，可以使用大多數API網關來模擬API的不可用性。然后可以通過調用并驗證斷路器是否被觸發，并且其結果仍然到達來檢查其他服務是否按預期工作。系統似乎已經自我修復。但也許某些用戶代碼直接調用了Web服務并有效地繞過了API網關?如何驗證緩存中的所有內容都正常工作，并使用預期的回退?

　　這就是日志和快照的來源�？梢詫⑺鼈兲砑拥胶蠖薃PI以及斷開的服務中，以驗證得到的結果確實是來自網關緩存的結果。

　　沖洗-重復

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

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

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

　　結語

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

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

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