常見的微服務組件及概念是什么

本篇內容介紹了“常見的微服務組件及概念是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

什么是微服務架構？

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

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

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

“微服務” 與 “微服務架構” 是有本質區別的。“微服務”強調的是服務的大小，它關注的是某一個點。而“微服務架構”則是一種架構思想，需要從整體上對軟件系統進行通盤的考慮。

常見的微服務組件及概念

• 服務注冊，服務提供方將自己調用地址注冊到服務注冊中心，讓服務調用方能夠方便地找到自己。

• 服務發現，服務調用方從服務注冊中心找到自己需要調用的服務的地址。

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

• 服務網關，服務網關是服務調用的唯一入口，可以在這個組件是實現用戶鑒權、動態路由、灰度發布、A/B 測試、負載限流等功能。

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

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

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

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

• 調用鏈，記錄完成一個業務邏輯時調用到的微服務，并將這種串行或并行的調用關系展示出來。在系統出錯時，可以方便地找到出錯點。

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

什么場景需要用微服務架構？

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

我們什么時候需要采用微服務呢？從我個人的經驗來看，我認為有三種場景可以考慮使用微服務。

• 規模大（團隊超過 10 人）

• 業務復雜度高（系統超過 5 個子模塊）

• 需要長期演進（項目開發和維護周期超過半年）

橫軸是復雜度，縱軸是生產效率。從生產效率的角度來講，在兩條曲線的交叉點之前，單體架構是占優勢的，過了交叉點之后，單體架構的生產效率將大幅度下降。

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