你開始構建一個漂亮的單體系統。也許是一個模塊化的單體系統。隨著時間的推移，系統不斷增長，需求也在不斷變化。漸漸地，系統開始出現裂痕。

這可能是出于組織原因，需要在團隊之間分配工作。也可能是由于擴展性問題和性能瓶頸。你開始評估可能的解決方案，以及每種解決方案的優勢和權衡。最后，你做出了一個決定。是時候將系統的部分部分遷移到獨立的（微）服務中了。

那么，我們如何從單體架構遷移到微服務呢？

使用有界上下文進行解耦

從單體架構轉移到微服務的第一步是識別有界上下文。因為它們代表了可用于提取的領域的內聚部分。

一個解決方案是使用領域驅動設計戰略建模來識別有界上下文。

有界上下文定義了模塊之間的顯式邊界，并分離了各自的責任。這是遷移到微服務時面臨的最大挑戰之一。確定良好的邊界確保微服務專注于一個問題領域。

在單體中定義邊界也更容易，因為你不是在處理分布式系統。重構不良邊界風險較低，你有更多自由度去“搞定”。

接下來你需要解決的問題是耦合。耦合表現為兩種方式：

• 數據庫依賴
• 模塊間的通信

你可以通過構建模塊化單體來從一開始解決這些問題。但我也會解釋你可以使用的指導原則來解決耦合。

模塊化單體如何解決耦合

模塊化單體是一個響亮的名字，指的是由幾個有界上下文（模塊）構建的單體系統，并遵循一系列控制耦合的原則。每個模塊包含一組內聚的功能，并且在系統中與其他模塊隔離。這種隔離涉及數據庫依賴和模塊間的通信。

你可以把一個模塊看作系統中的一個獨立應用程序。一個模塊擁有自己的領域、實體、用例和數據庫表。模塊作為一個單一可執行應用程序一起部署。但在其他方面它們是獨立的。

你可以對每個模塊應用不同的架構方法，比如清晰架構。

我提到你需要減少模塊間的耦合。

以下是解決數據庫耦合的兩個原則：

• 模塊不能在數據庫中共享表
• 模塊不能直接查詢其他模塊的數據庫表

共享數據庫表會導致高度耦合，而這恰恰是你要避免的。你可以使用模式在邏輯層面或物理上使用不同的數據庫為每個模塊隔離數據。

一個模塊應該暴露一個其他模塊可以調用的公共 API。這個公共 API 是模塊的入口點。這是模塊間通信的唯一方式。

模塊間通信可以是同步的，使用方法調用，或者異步的，使用消息總線。

我更傾向于使用消息傳遞的異步通信。它耦合度低，使得向微服務的轉變更加容易。

為系統添加消息代理

為了在模塊間實現異步通信，你可以引入一個消息代理。但你無需從一開始引入一個完整的消息代理。

你可以使用諸如MassTransit這樣的抽象來在模塊之間實現消息傳遞，同時將傳輸機制抽象化。

MassTransit 有一個內存傳輸機制，可以很好地在單個進程中工作。它非常快速。但它不是持久化的，如果總線停止，你可能會丟失消息。

在引入真正的消息代理時，你只需要配置不同的傳輸機制。但你不需要改變你的消息傳遞代碼。

在模塊化單體中引入消息傳遞的目的是什么？

這樣設計系統可以使模塊之間松耦合和獨立。在項目成熟后，你在開始時增加的復雜性是合理的。

將模塊提取到微服務中

我們決定從單體系統遷移到微服務。因為我們以模塊化的方式構建了系統，所以遷移的關鍵在于將一個模塊提取到一個新的進程中。

你應該在服務前面引入一個反向代理，來路由進入的流量。這將隱藏微服務系統的實現細節，不讓客戶端應用程序知道。

新的微服務需要連接到消息總線，但我們不需要在代碼中做任何改變。使用消息傳遞在模塊之間進行通信簡化了遷移過程。這可能讓你想起事件驅動架構。

如果你使用方法調用來實現模塊間通信，你必須將這種實現替換為通過網絡的 HTTP 調用。因為你現在正在構建一個分布式系統，之前的方法調用實現將無法工作。你還需要考慮認證、容錯等問題……

從單體系統中提取模塊會用新微服務的功能替換舊系統的所有功能。這個遷移到微服務的過程遵循了榕樹模式。

總結思考

從單體架構遷移到微服務的最大障礙是耦合。耦合是變更的阻止者。因此，這是你需要解決的第一件事。

你需要在數據庫層面和代碼中的組件間解決耦合。以模塊化的方式構建系統可以從一開始就避免這些問題。

這就是為什么模塊化單體是一個很好的方法。

你可以在系統中識別有界上下文，并將它們用作單體中的邊界。在單體中正確劃分邊界要容易得多。

遷移到微服務就是將模塊提取到獨立服務的過程。

當然，你仍然需要考慮安全性和容錯性，因為現在你有了一個分布式系統。

當談論抽象的架構時，可能難以理解，但在討論概念性解決方案時卻是很重要的。