常見的微服務(wù)組件及概念是什么

本篇內(nèi)容介紹了“常見的微服務(wù)組件及概念是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

什么是微服務(wù)架構(gòu)？

形像一點來說，微服務(wù)架構(gòu)就像搭積木，每個微服務(wù)都是一個零件，并使用這些零件組裝出不同的形狀。通俗來說，微服務(wù)架構(gòu)就是把一個大系統(tǒng)按業(yè)務(wù)功能分解成多個職責(zé)單一的小系統(tǒng)，并利用簡單的方法使多個小系統(tǒng)相互協(xié)作，組合成一個大系統(tǒng)。 如果學(xué)科派一點，微服務(wù)架構(gòu)就是把因相同原因而變化的功能聚合到一起，而把因不同原因而變化的功能分離開，并利用輕量化機制（通常為 HTTP RESTful API）實現(xiàn)通信。

微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務(wù)運行在其獨立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級的通信機制互相協(xié)作（通常是基于 HTTP 協(xié)議的 RESTful API）。每個服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，對具體的服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對其進(jìn)行構(gòu)建 。（摘自王磊先生的《微服務(wù)架構(gòu)與實踐》）

對于我個人，我更喜歡一種延續(xù)性的解釋，微服務(wù)架構(gòu) ≈ 模塊化開發(fā) + 分布式計算。不管微服務(wù)架構(gòu)的定義怎么樣，都是在描述一個核心思想：把大系統(tǒng)拆分成小型系統(tǒng)，把大事化小，以降低系統(tǒng)的復(fù)雜性，從而大幅降低系統(tǒng)建設(shè)、升級、運維的風(fēng)險和成本。

“微服務(wù)” 與 “微服務(wù)架構(gòu)” 是有本質(zhì)區(qū)別的。“微服務(wù)”強調(diào)的是服務(wù)的大小，它關(guān)注的是某一個點。而“微服務(wù)架構(gòu)”則是一種架構(gòu)思想，需要從整體上對軟件系統(tǒng)進(jìn)行通盤的考慮。

常見的微服務(wù)組件及概念

• 服務(wù)注冊，服務(wù)提供方將自己調(diào)用地址注冊到服務(wù)注冊中心，讓服務(wù)調(diào)用方能夠方便地找到自己。

• 服務(wù)發(fā)現(xiàn)，服務(wù)調(diào)用方從服務(wù)注冊中心找到自己需要調(diào)用的服務(wù)的地址。

• 負(fù)載均衡，服務(wù)提供方一般以多實例的形式提供服務(wù)，負(fù)載均衡功能能夠讓服務(wù)調(diào)用方連接到合適的服務(wù)節(jié)點。并且，節(jié)點選擇的工作對服務(wù)調(diào)用方來說是透明的。

• 服務(wù)網(wǎng)關(guān)，服務(wù)網(wǎng)關(guān)是服務(wù)調(diào)用的唯一入口，可以在這個組件是實現(xiàn)用戶鑒權(quán)、動態(tài)路由、灰度發(fā)布、A/B 測試、負(fù)載限流等功能。

• 配置中心，將本地化的配置信息（properties, xml, yaml 等）注冊到配置中心，實現(xiàn)程序包在開發(fā)、測試、生產(chǎn)環(huán)境的無差別性，方便程序包的遷移。

• API 管理，以方便的形式編寫及更新 API 文檔，并以方便的形式供調(diào)用者查看和測試。

• 集成框架，微服務(wù)組件都以職責(zé)單一的程序包對外提供服務(wù)，集成框架以配置的形式將所有微服務(wù)組件（特別是管理端組件）集成到統(tǒng)一的界面框架下，讓用戶能夠在統(tǒng)一的界面中使用系統(tǒng)。

• 分布式事務(wù)，對于重要的業(yè)務(wù)，需要通過分布式事務(wù)技術(shù)（TCC、高可用消息服務(wù)、最大努力通知）保證數(shù)據(jù)的一致性。

• 調(diào)用鏈，記錄完成一個業(yè)務(wù)邏輯時調(diào)用到的微服務(wù)，并將這種串行或并行的調(diào)用關(guān)系展示出來。在系統(tǒng)出錯時，可以方便地找到出錯點。

• 支撐平臺，系統(tǒng)微服務(wù)化后，系統(tǒng)變得更加碎片化，系統(tǒng)的部署、運維、監(jiān)控等都比單體架構(gòu)更加復(fù)雜，那么，就需要將大部分的工作自動化?，F(xiàn)在，可以通過 Docker 等工具來中和這些微服務(wù)架構(gòu)帶來的弊端。 例如持續(xù)集成、藍(lán)綠發(fā)布、健康檢查、性能健康等等。嚴(yán)重點，以我們兩年的實踐經(jīng)驗，可以這么說，如果沒有合適的支撐平臺或工具，就不要使用微服務(wù)架構(gòu)。

什么場景需要用微服務(wù)架構(gòu)？

軟件研發(fā)是一個系統(tǒng)工程，它沒有銀彈，不能夠一招鮮吃遍天。正如當(dāng)年的 CMMI 和敏捷方法一樣，敏捷雖好，但它不一定能適用于所有的場景，它對組織環(huán)境、團隊氛圍、溝通方式、技術(shù)能力這些都是有一些要求的，如果用不好，反而會帶來一些負(fù)面影響。

我們什么時候需要采用微服務(wù)呢？從我個人的經(jīng)驗來看，我認(rèn)為有三種場景可以考慮使用微服務(wù)。

• 規(guī)模大（團隊超過 10 人）

• 業(yè)務(wù)復(fù)雜度高（系統(tǒng)超過 5 個子模塊）

• 需要長期演進(jìn)（項目開發(fā)和維護(hù)周期超過半年）

橫軸是復(fù)雜度，縱軸是生產(chǎn)效率。從生產(chǎn)效率的角度來講，在兩條曲線的交叉點之前，單體架構(gòu)是占優(yōu)勢的，過了交叉點之后，單體架構(gòu)的生產(chǎn)效率將大幅度下降。

“常見的微服務(wù)組件及概念是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！