微服務(wù)設(shè)計(jì)的原則有哪些

這篇文章主要介紹“微服務(wù)設(shè)計(jì)的原則有哪些”，在日常操作中，相信很多人在微服務(wù)設(shè)計(jì)的原則有哪些問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”微服務(wù)設(shè)計(jì)的原則有哪些”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

良好的微服務(wù)設(shè)計(jì)可以使后期的升級(jí)維護(hù)更加輕松，否則將會(huì)令人非常頭疼。

下面幾個(gè)設(shè)計(jì)原則強(qiáng)烈建議采用：

• 單一職責(zé)

• 高內(nèi)聚

• 低耦合

• 隱藏內(nèi)部實(shí)現(xiàn)

• 避免代碼庫(kù)共享

• 避免數(shù)據(jù)過(guò)度暴露

• 避免數(shù)據(jù)庫(kù)共享

• 最小化同步調(diào)用

• 最小化硬件共享

• 避免使用平臺(tái)獨(dú)特性技術(shù)

這三大原則是面向?qū)ο笤O(shè)計(jì)中的核心，同樣適用于微服務(wù)設(shè)計(jì)。

1. 單一職責(zé)

每個(gè)微服務(wù)只應(yīng)擔(dān)負(fù)一個(gè)職責(zé)。

比如一個(gè)微服務(wù)中有兩大功能：

• 商品分類管理

• 購(gòu)物車

把它們放在一起看起來(lái)問(wèn)題不大，因?yàn)槭褂玫募夹g(shù)相同、功能和數(shù)據(jù)上會(huì)有比較緊密的聯(lián)系，在組織結(jié)構(gòu)上，通常是由同一個(gè)開(kāi)發(fā)小組負(fù)責(zé)。

但是，這會(huì)造成兩個(gè)功能有大量的代碼耦合。

時(shí)間長(zhǎng)了之后，會(huì)帶來(lái)和單體架構(gòu)一樣的問(wèn)題，維護(hù)難、測(cè)試難、部署難 ……

所以，按照“單一職責(zé)”原則，應(yīng)該分為兩個(gè)微服務(wù)。

2. 高內(nèi)聚

關(guān)系緊密的行為應(yīng)放在一起。

比如有2個(gè)微服務(wù)：

• 訂單管理

• 訂單金額統(tǒng)計(jì)

“訂單金額統(tǒng)計(jì)” 服務(wù)需要請(qǐng)求 “訂單管理” 服務(wù)，以獲取所需數(shù)據(jù)。

例如價(jià)格、稅、服務(wù)費(fèi) ……

剛開(kāi)始一切安好，但突然某一天上頭增加稅種了，需要更改新的計(jì)算規(guī)則。

那么，訂單服務(wù)就要提供新的數(shù)據(jù)，金額統(tǒng)計(jì)服務(wù)也需要更改計(jì)算方式。

也就是說(shuō)，每次變更基本都需要兩個(gè)服務(wù)一起改，是緊耦合的。

因?yàn)橛唵谓痤~統(tǒng)計(jì)服務(wù)的邏輯只與訂單相關(guān)，所以應(yīng)該并入訂單服務(wù)。

把緊密相關(guān)的行為放在一起，實(shí)現(xiàn)高內(nèi)聚。

3. 低耦合

一個(gè)服務(wù)的變更不要影響其他服務(wù)。

此原則涉及到多個(gè)方面。

3.1 隱藏內(nèi)部實(shí)現(xiàn)

比如上一節(jié) “高內(nèi)聚” 中，把金額統(tǒng)計(jì)服務(wù)并入了訂單管理服務(wù)，那么，之前金額統(tǒng)計(jì)服務(wù)中的 “統(tǒng)計(jì)接口” 還需要對(duì)外暴露嗎？

現(xiàn)在已經(jīng)是訂單服務(wù)的內(nèi)部功能了，統(tǒng)計(jì)結(jié)果可以作為訂單對(duì)象中的數(shù)據(jù)，所以無(wú)需對(duì)外暴露，防止誤操作和造成不必要的耦合關(guān)系。

3.2 避免共享代碼庫(kù)

共享代碼的確非常方便，但是會(huì)造成底層代碼關(guān)聯(lián)度太強(qiáng)。

對(duì)于以后的升級(jí)非常不便，例如某個(gè)服務(wù)想把語(yǔ)言版本升級(jí)，但共享庫(kù)使用的是低版本，其中某些用法在高版本中是過(guò)期的，這就很尷尬了。

想要完美的避免也是不現(xiàn)實(shí)的，只能盡量規(guī)避。

例如不共享，各服務(wù)重新造輪子，這樣服務(wù)之間就有邊界了。

但這個(gè)方式只適用于需要共享的庫(kù)是非常穩(wěn)定的，不怎么需要改了，否則的話相關(guān)服務(wù)都需要改。

再比如把共享庫(kù)的粒度縮小，避免形成功能特別全的大庫(kù)。

大庫(kù)必然導(dǎo)致被引用的范圍非常廣，影響面大。

如果粒度很小的話，涉及的服務(wù)也就少。

3.3 避免數(shù)據(jù)過(guò)度暴露

例如用戶服務(wù)有一個(gè)獲取用戶詳情的接口，返回用戶所有信息。

購(gòu)物車服務(wù)獲取用戶信息時(shí)，就會(huì)拿到很全的數(shù)據(jù)，例如包括支付信息。

這是沒(méi)必要的，只需要返回用戶的基本屬性即可。

特殊的屬性應(yīng)通過(guò)另外的接口提供。

過(guò)度暴露會(huì)增加服務(wù)間的耦合度。

3.4 避免數(shù)據(jù)庫(kù)共享

一個(gè)服務(wù)想獲取另一個(gè)服務(wù)的數(shù)據(jù)時(shí)，只應(yīng)該通過(guò)接口，而不是直接從對(duì)方的數(shù)據(jù)庫(kù)中拿。

否則，這種數(shù)據(jù)層面的耦合會(huì)帶來(lái)噩夢(mèng)。

3.5 最小化同步調(diào)用

比如訂單服務(wù)創(chuàng)建訂單的時(shí)候需要調(diào)用很多其他服務(wù)，例如用戶、商品、支付、庫(kù)存、物流。

直接同步調(diào)用各個(gè)服務(wù)的接口嗎？

不現(xiàn)實(shí)，如果其中有一個(gè)服務(wù)接口調(diào)用失敗，那么創(chuàng)建訂單就失敗了。

最好使用事件驅(qū)動(dòng)的異步調(diào)用。

同步調(diào)用會(huì)產(chǎn)生網(wǎng)絡(luò)的阻塞，對(duì)被調(diào)用服務(wù)的可用性要求極高，所以要慎重使用。

3.6 避免硬件基礎(chǔ)設(shè)施的共享

服務(wù)設(shè)計(jì)得很好，但如果硬件部署沒(méi)有規(guī)劃好，一樣非常痛苦。

例如兩個(gè)服務(wù)部署在一臺(tái)服務(wù)器上，服務(wù)B 非常消耗資源，那么服務(wù)A可能就沒(méi)法用了。

所以，不能忽略硬件這個(gè)關(guān)鍵點(diǎn)，要根據(jù)各個(gè)服務(wù)的特點(diǎn)做好均衡部署。

3.7 避免使用平臺(tái)特性技術(shù)

例如 Java RMI 做遠(yuǎn)程調(diào)用不錯(cuò)，但它是平臺(tái)特性，要求服務(wù)雙方都用一套技術(shù)，這種高耦合就不如平臺(tái)獨(dú)立的 REST 更自由了。

到此，關(guān)于“微服務(wù)設(shè)計(jì)的原則有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！