建站
咨詢
售后
建站咨詢
新聞中心
你開(kāi)始構(gòu)建一個(gè)漂亮的單體系統(tǒng)。也許是一個(gè)模塊化的單體系統(tǒng)。隨著時(shí)間的推移，系統(tǒng)不斷增長(zhǎng)，需求也在不斷變化。漸漸地，系統(tǒng)開(kāi)始出現(xiàn)裂痕。
創(chuàng)新互聯(lián)從2013年開(kāi)始，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都做網(wǎng)站、成都網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元內(nèi)鄉(xiāng)做網(wǎng)站,已為上家服務(wù),為內(nèi)鄉(xiāng)各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:13518219792
這可能是出于組織原因，需要在團(tuán)隊(duì)之間分配工作。也可能是由于擴(kuò)展性問(wèn)題和性能瓶頸。你開(kāi)始評(píng)估可能的解決方案，以及每種解決方案的優(yōu)勢(shì)和權(quán)衡。最后，你做出了一個(gè)決定。是時(shí)候?qū)⑾到y(tǒng)的部分部分遷移到獨(dú)立的（微）服務(wù)中了。
那么，我們?nèi)绾螐膯误w架構(gòu)遷移到微服務(wù)呢？
使用有界上下文進(jìn)行解耦
從單體架構(gòu)轉(zhuǎn)移到微服務(wù)的第一步是識(shí)別有界上下文。因?yàn)樗鼈兇砹丝捎糜谔崛〉念I(lǐng)域的內(nèi)聚部分。
一個(gè)解決方案是使用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)戰(zhàn)略建模來(lái)識(shí)別有界上下文。
有界上下文定義了模塊之間的顯式邊界，并分離了各自的責(zé)任。這是遷移到微服務(wù)時(shí)面臨的最大挑戰(zhàn)之一。確定良好的邊界確保微服務(wù)專注于一個(gè)問(wèn)題領(lǐng)域。
在單體中定義邊界也更容易，因?yàn)槟悴皇窃谔幚矸植际较到y(tǒng)。重構(gòu)不良邊界風(fēng)險(xiǎn)較低，你有更多自由度去“搞定”。
接下來(lái)你需要解決的問(wèn)題是耦合。耦合表現(xiàn)為兩種方式：
- 數(shù)據(jù)庫(kù)依賴
- 模塊間的通信
你可以通過(guò)構(gòu)建模塊化單體來(lái)從一開(kāi)始解決這些問(wèn)題。但我也會(huì)解釋你可以使用的指導(dǎo)原則來(lái)解決耦合。
模塊化單體如何解決耦合
模塊化單體是一個(gè)響亮的名字，指的是由幾個(gè)有界上下文（模塊）構(gòu)建的單體系統(tǒng)，并遵循一系列控制耦合的原則。每個(gè)模塊包含一組內(nèi)聚的功能，并且在系統(tǒng)中與其他模塊隔離。這種隔離涉及數(shù)據(jù)庫(kù)依賴和模塊間的通信。
你可以把一個(gè)模塊看作系統(tǒng)中的一個(gè)獨(dú)立應(yīng)用程序。一個(gè)模塊擁有自己的領(lǐng)域、實(shí)體、用例和數(shù)據(jù)庫(kù)表。模塊作為一個(gè)單一可執(zhí)行應(yīng)用程序一起部署。但在其他方面它們是獨(dú)立的。
你可以對(duì)每個(gè)模塊應(yīng)用不同的架構(gòu)方法，比如清晰架構(gòu)。
我提到你需要減少模塊間的耦合。
以下是解決數(shù)據(jù)庫(kù)耦合的兩個(gè)原則：
- 模塊不能在數(shù)據(jù)庫(kù)中共享表
- 模塊不能直接查詢其他模塊的數(shù)據(jù)庫(kù)表
共享數(shù)據(jù)庫(kù)表會(huì)導(dǎo)致高度耦合，而這恰恰是你要避免的。你可以使用模式在邏輯層面或物理上使用不同的數(shù)據(jù)庫(kù)為每個(gè)模塊隔離數(shù)據(jù)。
一個(gè)模塊應(yīng)該暴露一個(gè)其他模塊可以調(diào)用的公共 API。這個(gè)公共 API 是模塊的入口點(diǎn)。這是模塊間通信的唯一方式。
模塊間通信可以是同步的，使用方法調(diào)用，或者異步的，使用消息總線。
我更傾向于使用消息傳遞的異步通信。它耦合度低，使得向微服務(wù)的轉(zhuǎn)變更加容易。
為系統(tǒng)添加消息代理
為了在模塊間實(shí)現(xiàn)異步通信，你可以引入一個(gè)消息代理。但你無(wú)需從一開(kāi)始引入一個(gè)完整的消息代理。
你可以使用諸如MassTransit這樣的抽象來(lái)在模塊之間實(shí)現(xiàn)消息傳遞，同時(shí)將傳輸機(jī)制抽象化。
MassTransit 有一個(gè)內(nèi)存?zhèn)鬏敊C(jī)制，可以很好地在單個(gè)進(jìn)程中工作。它非?？焖?。但它不是持久化的，如果總線停止，你可能會(huì)丟失消息。
在引入真正的消息代理時(shí)，你只需要配置不同的傳輸機(jī)制。但你不需要改變你的消息傳遞代碼。
在模塊化單體中引入消息傳遞的目的是什么？
這樣設(shè)計(jì)系統(tǒng)可以使模塊之間松耦合和獨(dú)立。在項(xiàng)目成熟后，你在開(kāi)始時(shí)增加的復(fù)雜性是合理的。
將模塊提取到微服務(wù)中
我們決定從單體系統(tǒng)遷移到微服務(wù)。因?yàn)槲覀円阅K化的方式構(gòu)建了系統(tǒng)，所以遷移的關(guān)鍵在于將一個(gè)模塊提取到一個(gè)新的進(jìn)程中。
你應(yīng)該在服務(wù)前面引入一個(gè)反向代理，來(lái)路由進(jìn)入的流量。這將隱藏微服務(wù)系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)，不讓客戶端應(yīng)用程序知道。
新的微服務(wù)需要連接到消息總線，但我們不需要在代碼中做任何改變。使用消息傳遞在模塊之間進(jìn)行通信簡(jiǎn)化了遷移過(guò)程。這可能讓你想起事件驅(qū)動(dòng)架構(gòu)。
如果你使用方法調(diào)用來(lái)實(shí)現(xiàn)模塊間通信，你必須將這種實(shí)現(xiàn)替換為通過(guò)網(wǎng)絡(luò)的 HTTP 調(diào)用。因?yàn)槟悻F(xiàn)在正在構(gòu)建一個(gè)分布式系統(tǒng)，之前的方法調(diào)用實(shí)現(xiàn)將無(wú)法工作。你還需要考慮認(rèn)證、容錯(cuò)等問(wèn)題……
從單體系統(tǒng)中提取模塊會(huì)用新微服務(wù)的功能替換舊系統(tǒng)的所有功能。這個(gè)遷移到微服務(wù)的過(guò)程遵循了榕樹(shù)模式。
總結(jié)思考
從單體架構(gòu)遷移到微服務(wù)的最大障礙是耦合。耦合是變更的阻止者。因此，這是你需要解決的第一件事。
你需要在數(shù)據(jù)庫(kù)層面和代碼中的組件間解決耦合。以模塊化的方式構(gòu)建系統(tǒng)可以從一開(kāi)始就避免這些問(wèn)題。
這就是為什么模塊化單體是一個(gè)很好的方法。
你可以在系統(tǒng)中識(shí)別有界上下文，并將它們用作單體中的邊界。在單體中正確劃分邊界要容易得多。
遷移到微服務(wù)就是將模塊提取到獨(dú)立服務(wù)的過(guò)程。
當(dāng)然，你仍然需要考慮安全性和容錯(cuò)性，因?yàn)楝F(xiàn)在你有了一個(gè)分布式系統(tǒng)。
當(dāng)談?wù)摮橄蟮募軜?gòu)時(shí)，可能難以理解，但在討論概念性解決方案時(shí)卻是很重要的。
分享標(biāo)題：從單體架構(gòu)向微服務(wù)遷移：模塊化單體是如何提供幫助的
轉(zhuǎn)載源于：http://www.fisionsoft.com.cn/article/cdodsco.html
