當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

微服务（Microservices）和服务网格（Service Mesh）架构概念整理

發布時間：2023/12/2 编程问答 37 豆豆

生活随笔收集整理的這篇文章主要介紹了微服务（Microservices）和服务网格（Service Mesh）架构概念整理小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

微服務（Microservices）

在過去的 2016 年和 2017 年，微服務技術迅猛普及，和容器技術一起成為這兩年中最吸引眼球的技術熱點。而以 Spring Cloud 為代表的傳統侵入式開發框架，占據著微服務市場的主流地位。

微服務（Microservices）是一種架構風格，一個大型復雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。

形像一點來說，微服務架構就像搭積木，每個微服務都是一個零件，并使用這些零件組裝出不同的形狀。通俗來說，微服務架構就是把一個大系統按業務功能分解成多個職責單一的小系統，并利用簡單的方法使多個小系統相互協作，組合成一個大系統。

如果學科派一點，微服務架構就是把因相同原因而變化的功能聚合到一起，而把因不同原因而變化的功能分離開，并利用輕量化機制（通常為 HTTP RESTful API）實現通信。

微服務架構 ≈ 模塊化開發 + 分布式計算。

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

微服務架構示意圖：

常見的微服務組件及概念：

服務注冊：服務提供方將自己調用地址注冊到服務注冊中心，讓服務調用方能夠方便地找到自己。
服務發現：服務調用方從服務注冊中心找到自己需要調用的服務的地址。
負載均衡：服務提供方一般以多實例的形式提供服務，負載均衡功能能夠讓服務調用方連接到合適的服務節點。并且，節點選擇的工作對服務調用方來說是透明的。
服務網關：服務網關是服務調用的唯一入口，可以在這個組件是實現用戶鑒權、動態路由、灰度發布、A/B 測試、負載限流等功能。
配置中心：將本地化的配置信息（properties, xml, yaml 等）注冊到配置中心，實現程序包在開發、測試、生產環境的無差別性，方便程序包的遷移。
API 管理：以方便的形式編寫及更新 API 文檔，并以方便的形式供調用者查看和測試。
集成框架：微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將所有微服務組件（特別是管理端組件）集成到統一的界面框架下，讓用戶能夠在統一的界面中使用系統。
分布式事務：對于重要的業務，需要通過分布式事務技術（TCC、高可用消息服務、最大努力通知）保證數據的一致性。
調用鏈：記錄完成一個業務邏輯時調用到的微服務，并將這種串行或并行的調用關系展示出來。在系統出錯時，可以方便地找到出錯點。
支撐平臺：系統微服務化后，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加復雜，那么，就需要將大部分的工作自動化。現在，可以通過 Docker 等工具來中和這些微服務架構帶來的弊端。例如持續集成、藍綠發布、健康檢查、性能健康等等。嚴重點，以我們兩年的實踐經驗，可以這么說，如果沒有合適的支撐平臺或工具，就不要使用微服務架構。

微服務架構的優點：

降低系統復雜度：每個服務都比較簡單，只關注于一個業務功能。
松耦合：微服務架構方式是松耦合的，每個微服務可由不同團隊獨立開發，互不影響。
跨語言：只要符合服務 API 契約，開發人員可以自由選擇開發技術。這就意味著開發人員可以采用新技術編寫或重構服務，由于服務相對較小，所以這并不會對整體應用造成太大影響。
獨立部署：微服務架構可以使每個微服務獨立部署。開發人員無需協調對服務升級或更改的部署。這些更改可以在測試通過后立即部署。所以微服務架構也使得 CI／CD 成為可能。
Docker 容器：和 Docker 容器結合的更好。
DDD 領域驅動設計：和 DDD 的概念契合，結合開發會更好。

微服務架構的缺點：

微服務強調了服務大小，但實際上這并沒有一個統一的標準：業務邏輯應該按照什么規則劃分為微服務，這本身就是一個經驗工程。有些開發者主張 10-100 行代碼就應該建立一個微服務。雖然建立小型服務是微服務架構崇尚的，但要記住，微服務是達到目的的手段，而不是目標。微服務的目標是充分分解應用程序，以促進敏捷開發和持續集成部署。
微服務的分布式特點帶來的復雜性：開發人員需要基于 RPC 或者消息實現微服務之間的調用和通信，而這就使得服務之間的發現、服務調用鏈的跟蹤和質量問題變得的相當棘手。
分區的數據庫體系和分布式事務：更新多個業務實體的業務交易相當普遍，不同服務可能擁有不同的數據庫。CAP 原理的約束，使得我們不得不放棄傳統的強一致性，而轉而追求最終一致性，這個對開發人員來說是一個挑戰。
測試挑戰：傳統的單體WEB應用只需測試單一的 REST API 即可，而對微服務進行測試，需要啟動它依賴的所有其他服務。這種復雜性不可低估。
跨多個服務的更改：比如在傳統單體應用中，若有 A、B、C 三個服務需要更改，A 依賴 B，B 依賴 C。我們只需更改相應的模塊，然后一次性部署即可。但是在微服務架構中，我們需要仔細規劃和協調每個服務的變更部署。我們需要先更新 C，然后更新 B，最后更新 A。
部署復雜：微服務由不同的大量服務構成。每種服務可能擁有自己的配置、應用實例數量以及基礎服務地址。這里就需要不同的配置、部署、擴展和監控組件。此外，我們還需要服務發現機制，以便服務可以發現與其通信的其他服務的地址。因此，成功部署微服務應用需要開發人員有更好地部署策略和高度自動化的水平。
總的來說（問題和挑戰）：API Gateway、服務間調用、服務發現、服務容錯、服務部署、數據調用。

不過，現在很多微服務的框架（比如 Spring Cloud、Dubbo）已經很好的解決了上面的問題。

服務網格（Service Mesh）

2017 年底，非侵入式的 Service Mesh 技術從萌芽到走向了成熟。

Service Mesh 又譯作“服務網格”，作為服務間通信的基礎設施層。

如果用一句話來解釋什么是 Service Mesh，可以將它比作是應用程序或者說微服務間的 TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。對于編寫應用程序來說一般無須關心 TCP/IP 這一層（比如通過 HTTP 協議的 RESTful 應用），同樣使用 Service Mesh 也就無須關系服務之間的那些原來是通過應用程序或者其他框架實現的事情，比如 Spring Cloud、OSS，現在只要交給 Service Mesh 就可以了。

Service Mesh 的來龍去脈：

從最原始的主機之間直接使用網線相連

網絡層的出現

集成到應用程序內部的控制流

分解到應用程序外部的控制流

應用程序的中集成服務發現和斷路器

出現了專門用于服務發現和斷路器的軟件包/庫，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時候還是集成在應用程序內部

出現了專門用于服務發現和斷路器的開源軟件，如 Netflix OSS、Airbnb 的 synapse 和 nerve

最后作為微服務的中間層 Service Mesh 出現

Service Mesh 有如下幾個特點：

應用程序間通訊的中間層
輕量級網絡代理
應用程序無感知
解耦應用程序的重試/超時、監控、追蹤和服務發現

Service Mesh 架構圖：

目前流行的 Service Mesh 開源軟件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（開源 Linkerd 的公司）又發布了基于 Kubernetes 的 Service Mesh 開源項目 Conduit。

Service Mesh 開源項目簡介：

Linkerd（https://github.com/linkerd/linkerd）：第一代 Service Mesh，2016 年 1 月 15 日首發布，業界第一個 Service Mesh 項目，由 Buoyant 創業小公司開發（前 Twitter 工程師），2017 年 7 月 11 日，宣布和 Istio 集成，成為 Istio 的數據面板。
Envoy（https://github.com/envoyproxy/envoy）：第一代 Service Mesh，2016 年 9 月 13 日首發布，由 Matt Klein 個人開發（Lyft 工程師），之后默默發展，版本較穩定。
Istio（https://github.com/istio/istio）：第二代 Service Mesh，2017 年 5 月 24 日首發布，由 Google、IBM 和 Lyft 聯合開發，只支持 Kubernetes 平臺，2017 年 11 月 30 日發布 0.3 版本，開始支持非 Kubernetes 平臺，之后穩定的開發和發布。
Conduit（https://github.com/runconduit/conduit）：第二代 Service Mesh，2017 年 12 月 5 日首發布，由 Buoyant 公司開發（借鑒 Istio 整體架構，部分進行了優化），對抗 Istio 壓力山大，也期待 Buoyant 公司的毅力。
nginMesh（https://github.com/nginmesh/nginmesh）：2017 年 9 月首發布，由 Nginx 開發，定位是作為 Istio 的服務代理，也就是替代 Envoy，思路跟 Linkerd 之前和 Istio 集成很相似，極度低調，GitHub 上的 star 也只有不到 100。
Kong（https://github.com/Kong/kong）：比 nginMesh 更加低調，默默發展中。

關于微服務和服務網格的區別，我的一些理解：微服務更像是一個服務之間的生態，專注于服務治理等方面，而服務網格更專注于服務之間的通信，以及和 DevOps 更好的結合。

轉載于:https://www.cnblogs.com/jking10/p/11038519.html

總結

以上是生活随笔為你收集整理的微服务（Microservices）和服务网格（Service Mesh）架构概念整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。