在將單體遷移到微服務之前需要了解的模式 - Abhishek

不要做大爆炸重寫
Big Bang Rewrite，顧名思義，我們必須在微服務中重寫整個單體應用的程式碼，並一次性將其部署到生產中。有一次馬丁福勒正確地說：

Big Bang 重寫唯一能保證的就是 Big Bang！

大爆炸重寫總是危險的。Big bang 重寫需要大量時間來開發，因為您必須對單體應用程式中的所有內容進行編碼。此外，在微服務架構的開發過程中，您必須凍結單體應用中的進一步開發，因為單體應用中所做的每個更改也必須在微服務中進行。對於大多數公司來說，凍結應用程式開發可能是危險的，因為他們必須根據業務環境的變化進行調整。
對於一個組織來說，從單體架構逐漸轉向微服務總是更好的。一些可用的設計模式可以幫助您逐步從單體架構轉向微服務架構。
 

扼殺者模式
Strangler fig 是 Martin Fowler 設計的一種模式。在 Strangler Fig 中，我們圍繞現有單體的邊緣建立了新服務。
（banq注：這是一種理想型模式，整體單體架構之所以需要切換到微服務，是因為是糨糊一團，耦合在一起，邊緣和核心都耦合在一起，如何拆？如何開始？動一遷百）
 

抽象分支
當您必須提取其他模組所依賴的模組時，按抽象模式分支可能會很有用。假設在前面的示例中，我們想將通知管理轉換為微服務。在這種情況下，我們將使用抽象分支。我們需要執行以下步驟來提取模組。

1. 建立抽象。您需要圍繞要替換的模組建立抽象。
2. 將現有功能的客戶端更改為使用新抽象：您需要重構舊程式碼，以便舊實現實現在步驟 1 中建立的抽象。
3. 建立新的實現。您需要為功能建立一個新的微服務實現，並將其部署到生產中並執行一些測試。
4. 開關實現。一旦您執行了一些測試並且您有一定的信心，那麼您就可以切換到新程式碼。
5. 清理。一旦您的微服務啟動並執行，最好清理舊程式碼庫並刪除舊模組。如果需要，您也可以刪除抽象。在許多情況下，您之前建立的抽象只會改進您的程式碼庫，在這些情況下，保留它完全沒問題。

並行執行
無論您測試多少，仍然存在錯誤的可能性。當您遷移一個關鍵系統時，您不能為運氣留下任何東西。在這種情況下，並行執行模式可能會有所幫助。在這種模式中，我們將在生產中部署我們新開發的微服務和單體應用。我們將讓資料從兩個系統流出。Monolith 系統最初將是唯一的真相來源。我們將新開發的微服務的結果與單體的結果進行比較。如果我們發現任何不匹配，我們將在我們的微服務應用程式中修復它。一段時間後，當我們對我們的新微服務系統有足夠的信心時，我們就可以從整體中停用功能，並使微服務成為唯一的事實來源。
 

裝飾器模式
這個模式的靈感來自我們已經知道和喜愛的模式之一，裝飾者模式。在這種情況下，就像扼殺者模式一樣，我們必須引入代理。我們將讓呼叫透過一個代理傳遞給單體應用，並且基於單體應用的響應，代理將呼叫我們新建立的微服務。
 
更改資料捕獲模式
在這種模式中，我們將對資料庫中發生的變化做出反應。
 
banq注：遷移最重要的是切分單體，最有用方式是：用事件風暴分解單體設計微服務 - capital
重寫比重構好，而且微服務本身特點就是能夠重寫一個微服務，如果一個微服務不能輕鬆重寫，就不是微服務。