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

華龍網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián)公司,華龍網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為華龍上1000家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站制作要多少錢，請找那個售后服務(wù)好的華龍做網(wǎng)站的公司定做！

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

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

• 單一職責(zé)

• 高內(nèi)聚

• 低耦合

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

• 避免代碼庫共享

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

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

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

• 最小化硬件共享

• 避免使用平臺獨特性技術(shù)

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

1. 單一職責(zé)

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

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

• 商品分類管理

• 購物車

把它們放在一起看起來問題不大，因為使用的技術(shù)相同、功能和數(shù)據(jù)上會有比較緊密的聯(lián)系，在組織結(jié)構(gòu)上，通常是由同一個開發(fā)小組負(fù)責(zé)。

但是，這會造成兩個功能有大量的代碼耦合。

時間長了之后，會帶來和單體架構(gòu)一樣的問題，維護(hù)難、測試難、部署難 ……

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

2. 高內(nèi)聚

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

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

• 訂單管理

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

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

例如價格、稅、服務(wù)費 ……

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

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

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

因為訂單金額統(tǒng)計服務(wù)的邏輯只與訂單相關(guān)，所以應(yīng)該并入訂單服務(wù)。

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

3. 低耦合

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

此原則涉及到多個方面。

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

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

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

3.2 避免共享代碼庫

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

否則，這種數(shù)據(jù)層面的耦合會帶來噩夢。

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

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

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

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

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

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

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

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

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

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

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

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

到此，關(guān)于“微服務(wù)設(shè)計的原則有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

名稱欄目：微服務(wù)設(shè)計的原則有哪些
本文地址：http://vcdvsql.cn/article26/gjogjg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設(shè)計、品牌網(wǎng)站制作、網(wǎng)站排名、網(wǎng)站營銷、云服務(wù)器、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)