Service Mesh相關知識點有哪些

本篇內容主要講解“Service Mesh相關知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Service Mesh相關知識點有哪些”吧!

什么是ServiceMesh

Service Mesh是一種非入侵、透明化的微服務治理框架。作為服務與服務直接通信的透明化管理框架，Service Mesh不限制服務開發語言、使用輕量級的通信協議（HTTP、gRPC等），并插件式的提供各類功能，如服務發現、負載均衡、智能路由、流量管控、性能分析等等，換而言之，用戶通過Service Mesh得以用簡單的方式獲取高級的功能。

Rainbond原生支持Service Mesh，接下來我們將從服務發現和注冊、彈性伸縮與負載均衡、容錯處理（斷路器與限流）、監控與報警、數據存儲與共享、日志分析等方面進行解讀。

服務發現和注冊

服務注冊是任何一個SOA/服務化/微服務框架必不可少的關鍵部分，與之密切相關的是一些強一致性分布式存儲：Zookeeper、Etcd、Consul，其中Consul和Etcd基于Raft協議實現，Zookeeper基于PAXOS協議實現。

幾乎所有的服務注冊和發現都需要基于以上強一致性分布式存儲實現，例如SpringCloud的兩個重要的子項目Spring_Cloud_Consul/Spring_Cloud_Zookeeper。

對于Rainbond來說，通過應用/服務統一管理實現了所有部署應用/服務的自動注冊。其原理在于Rainbond內部基于Kubernetes實現應用調度，注冊于Kubernetes集群中的應用/服務信息，實際也是注冊到了Etcd之中。應用實例每次重啟，Rianbond都會為其分配不同的IP地址，服務注冊信息將動態地改變。

我們知道，應用與應用直接通信之前必須首先發現對方，在這方面，Rainbond采用了聲明式的發現機制，即當A服務需要與B服務通信，那么首先需要在A服務聲明依賴B服務，而Rainbond應用運行時模塊會基于用戶聲明發現對方服務地址，注入到A服務內部, 賦予A服務一個本地訪問地址（127.0.0.1）訪問B服務。

平臺服務間的依賴關系

彈性伸縮與負載均衡

說到服務發現和注冊，彈性伸縮與負載均衡也就不得不談。

上文中A服務連接B服務，B服務可以是有狀態的數據庫服務，例如Mysql、MongoDB等，也可以是無狀態的restfulAPI服務。

對于可以水平伸縮的應用（無狀態應用或者分布式有狀態應用），服務發現注入多個端點地址，必然需要負載均衡，因此A服務內部需要支持4層網絡代理或者7層網絡代理，通過應用運行時模塊發現的后端地址注入到代理插件內部。

Rainbond默認的代理插件支持4層負載均衡，借助Service Mesh便于擴展得特性，我們可以再針對各種應用層協議匹配不同的網絡治理插件，實現7層負載均衡，例如HTTP、gRPC、Redis等協議。

為什么需要7層負載均衡這樣的高級功能？原因在于對于一些在線環境，我們希望可以對服務間調用實現熱更改或者更好的容錯，比方說A/B測試、灰度發布等等，必須要在7層負載均衡上完成。

Rainbond目前提供“基于envoy的7層網絡治理插件”（envoy本身可以與安生運行于Rainbond插件體系之中），用戶也可以選擇和實現其他插件，Rainbond運行時將提供完善的基礎服務。

配置7層高級負載均衡的方式

容錯處理（斷路器與限流）

能夠容忍其中某些服務異常情況的微服務架構，才稱得上是健壯的生產級微服務架構。

比方說某購物網站，訂單頁面會推薦其他相關商品，在大流量異常情況下，為了保證訂單功能可用，將推薦功能（計算耗時，性能不好）限制可用，需要優雅的服務降級，將有限的資源用于關鍵服務的同時，保證整個系統穩定。

這里有兩種方案：限流，將某個服務設置其最大的請求量或者連接數，硬性保護下游服務；斷路器，當下游服務錯誤率到達一個閥值，將上游請求快速失敗返回，保護上游服務穩定，同時又不給下游服務增加壓力，做到快速失敗、快速返回。

以上功能的實現對于業務系統來說相對復雜，而在上文提到的Rainbond高級負載均衡支持下，僅需為每個調用線路配置簡單的限流參數或者熔斷參數，即可實現斷路器和限流機制開箱即用。

監控與報警

傳統運維關注監控物理資源，例如內存、CPU、負載等指標數據。Rainbond在監控和警報方面，重點沒有放在這些側面體現運行狀況的方式，除了基礎的資源監控之外，Rainbond核心選擇了能夠直接體現服務運行情況的吞吐率和響應時間作為關鍵指標，如吞吐率異常降低，響應時間增大證明當前服務壓力過大，就表示需要擴容了。

Rainbond的業務級監控分析如下圖：

對于不同的服務協議，Rainbond使用不同的指標實時表現吞吐率、響應時間，例如HTTP協議，使用Path的請求量和相應時間表達，Mysql協議使用SQL執行量和響應時間表達。

后續Rainbond將支持除上述兩種協議之外的更多的應用協議，包括gRPC、Redis、postgreSQL等。用戶可以自動或手動在這些指標之上配置規則或自動學習規則，實現提供業務報警和自動伸縮。

數據存儲與共享

分布式是微服務架構中不可缺少的部分，在運行多種不同類型應用、需求不同存儲，并且不同數據中心和不同基礎設施提供不同存儲類型的情況下，實現和處理起來并不容易。

Rainbond的實現方式是將存儲和應用進行解耦和，插件式支持不同的存儲類型，例如基于NFS的分布式文件存儲、塊設備存儲、內存虛擬存儲等，

當然不同的存儲具有不同的屬性，Rainbond分布式無狀態應用最常用的是共享文件存儲，為每個應用分配的存儲區域將掛載到所有實例之上，實時同步數據。用戶可以自定義需要掛載的路徑，應用到哪里，數據就跟到哪里。

日志分析

微服務架構中服務產生的日志處理也是一個難點，日志需要統一收集，同一個應用的多個實例產生的日志需要匯聚，然后需要分析和報警。

服務的日志一般會分為兩部分：系統日志和訪問日志，Rainbond推薦將兩類日志區別處理。

對于系統日志，其主要作用是調試系統、記錄異常，Rainbond提供基于應用級別的應用日志匯聚和實時展示，因此只需要將系統日志輸出到標準輸出(stdout)，系統將自動收集和匯聚，以應用的維度存儲。

對于訪問日志，我們一般需要對其進行分析和監控，日志分析常用的方案是ELK系統，Rainbond建議的方式是將訪問日志輸出到指定文件，并安裝Elasticsearch插件，以便將收集文件日志發送到指定Elasticsearch服務端（平臺一鍵部署ELK完整服務）。如果使用其他分析系統，同樣使用插件的形式將應用日志輸送到指定服務端即可。

到此，相信大家對“Service Mesh相關知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！