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

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

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

下面幾個設計原則強烈建議采用：

• 單一職責

• 高內聚

• 低耦合

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

• 避免代碼庫共享

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

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

• 最小化同步調用

• 最小化硬件共享

• 避免使用平臺獨特性技術

這三大原則是面向對象設計中的核心，同樣適用于微服務設計。

1. 單一職責

每個微服務只應擔負一個職責。

比如一個微服務中有兩大功能：

• 商品分類管理

• 購物車

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

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

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

所以，按照“單一職責”原則，應該分為兩個微服務。

2. 高內聚

關系緊密的行為應放在一起。

比如有2個微服務：

• 訂單管理

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

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

例如價格、稅、服務費 ……

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

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

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

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

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

3. 低耦合

一個服務的變更不要影響其他服務。

此原則涉及到多個方面。

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

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

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

3.2 避免共享代碼庫

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

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

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

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

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

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

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

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

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

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

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

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

特殊的屬性應通過另外的接口提供。

過度暴露會增加服務間的耦合度。

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

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

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

3.5 最小化同步調用

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

直接同步調用各個服務的接口嗎？

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

最好使用事件驅動的異步調用。

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

3.6 避免硬件基礎設施的共享

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

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

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

3.7 避免使用平臺特性技術

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

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

名稱欄目：微服務設計的原則有哪些
本文地址：http://chinadenli.net/article26/gjogjg.html

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

廣告

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