你開始構(gòu)建一個漂亮的單體系統(tǒng)。也許是一個模塊化的單體系統(tǒng)。隨著時間的推移，系統(tǒng)不斷增長，需求也在不斷變化。漸漸地，系統(tǒng)開始出現(xiàn)裂痕。

這可能是出于組織原因，需要在團(tuán)隊之間分配工作。也可能是由于擴(kuò)展性問題和性能瓶頸。你開始評估可能的解決方案，以及每種解決方案的優(yōu)勢和權(quán)衡。最后，你做出了一個決定。是時候?qū)⑾到y(tǒng)的部分部分遷移到獨(dú)立的（微）服務(wù)中了。

那么，我們?nèi)绾螐膯误w架構(gòu)遷移到微服務(wù)呢？

使用有界上下文進(jìn)行解耦

從單體架構(gòu)轉(zhuǎn)移到微服務(wù)的第一步是識別有界上下文。因?yàn)樗鼈兇砹丝捎糜谔崛〉念I(lǐng)域的內(nèi)聚部分。

一個解決方案是使用領(lǐng)域驅(qū)動設(shè)計戰(zhàn)略建模來識別有界上下文。

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

在單體中定義邊界也更容易，因?yàn)槟悴皇窃谔幚矸植际较到y(tǒng)。重構(gòu)不良邊界風(fēng)險較低，你有更多自由度去“搞定”。

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

• 數(shù)據(jù)庫依賴
• 模塊間的通信

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

模塊化單體如何解決耦合

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

你可以把一個模塊看作系統(tǒng)中的一個獨(dú)立應(yīng)用程序。一個模塊擁有自己的領(lǐng)域、實(shí)體、用例和數(shù)據(jù)庫表。模塊作為一個單一可執(zhí)行應(yīng)用程序一起部署。但在其他方面它們是獨(dú)立的。

你可以對每個模塊應(yīng)用不同的架構(gòu)方法，比如清晰架構(gòu)。

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

以下是解決數(shù)據(jù)庫耦合的兩個原則：

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

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

一個模塊應(yīng)該暴露一個其他模塊可以調(diào)用的公共 API。這個公共 API 是模塊的入口點(diǎn)。這是模塊間通信的唯一方式。

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

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

為系統(tǒng)添加消息代理

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

你可以使用諸如MassTransit這樣的抽象來在模塊之間實(shí)現(xiàn)消息傳遞，同時將傳輸機(jī)制抽象化。

MassTransit 有一個內(nèi)存?zhèn)鬏敊C(jī)制，可以很好地在單個進(jìn)程中工作。它非?？焖?。但它不是持久化的，如果總線停止，你可能會丟失消息。

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

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

這樣設(shè)計系統(tǒng)可以使模塊之間松耦合和獨(dú)立。在項(xiàng)目成熟后，你在開始時增加的復(fù)雜性是合理的。

將模塊提取到微服務(wù)中

我們決定從單體系統(tǒng)遷移到微服務(wù)。因?yàn)槲覀円阅K化的方式構(gòu)建了系統(tǒng)，所以遷移的關(guān)鍵在于將一個模塊提取到一個新的進(jìn)程中。

你應(yīng)該在服務(wù)前面引入一個反向代理，來路由進(jìn)入的流量。這將隱藏微服務(wù)系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)，不讓客戶端應(yīng)用程序知道。

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

如果你使用方法調(diào)用來實(shí)現(xiàn)模塊間通信，你必須將這種實(shí)現(xiàn)替換為通過網(wǎng)絡(luò)的 HTTP 調(diào)用。因?yàn)槟悻F(xiàn)在正在構(gòu)建一個分布式系統(tǒng)，之前的方法調(diào)用實(shí)現(xiàn)將無法工作。你還需要考慮認(rèn)證、容錯等問題……

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

總結(jié)思考

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

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

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

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

遷移到微服務(wù)就是將模塊提取到獨(dú)立服務(wù)的過程。

當(dāng)然，你仍然需要考慮安全性和容錯性，因?yàn)楝F(xiàn)在你有了一個分布式系統(tǒng)。

當(dāng)談?wù)摮橄蟮募軜?gòu)時，可能難以理解，但在討論概念性解決方案時卻是很重要的。