簡(jiǎn)介：服務(wù)網(wǎng)格是用于處理服務(wù)間通信的專用基礎(chǔ)設(shè)施層。它負(fù)責(zé)通過(guò)包含現(xiàn)代云原生應(yīng)用程序的復(fù)雜服務(wù)拓?fù)鋪?lái)可靠地傳遞請(qǐng)求。

微服務(wù)發(fā)展的這幾年，新的技術(shù)和概念層出不窮，這些技術(shù)的引入本質(zhì)上都是在圍繞服務(wù)穩(wěn)定性和業(yè)務(wù)開發(fā)效率提升，最近兩年服務(wù)網(wǎng)格越來(lái)越被廣大的微服務(wù)用戶所認(rèn)知。

在 Kubernetes 已經(jīng)成為云原生時(shí)代的操作系統(tǒng)的今天，如何更好的擁抱 Kubernetes 生態(tài)，實(shí)現(xiàn)業(yè)務(wù)快速上云，享受云計(jì)算帶來(lái)的能力，其中服務(wù)網(wǎng)格是一個(gè)必須要提的關(guān)鍵技術(shù)，但是在服務(wù)網(wǎng)格使用過(guò)程中我們會(huì)碰到很多的問(wèn)題，比如：如何讓現(xiàn)有的應(yīng)用遷移到服務(wù)網(wǎng)格，如何支持多種語(yǔ)言、框架的互通和治理，如何使用可觀測(cè)產(chǎn)品排查問(wèn)題，接下來(lái)我將從如何接入服務(wù)網(wǎng)格、異構(gòu)服務(wù)框架、語(yǔ)言的互通和可觀測(cè)三個(gè)方面回答這個(gè)問(wèn)題。

遷移應(yīng)用到服務(wù)網(wǎng)格中

服務(wù)網(wǎng)格

服務(wù)網(wǎng)格是用于處理服務(wù)間通信的專用基礎(chǔ)設(shè)施層，它負(fù)責(zé)通過(guò)包含現(xiàn)代云原生應(yīng)用程序的復(fù)雜服務(wù)拓?fù)鋪?lái)可靠地傳遞請(qǐng)求。實(shí)際上，服務(wù)網(wǎng)格通常通過(guò)一組輕量級(jí)網(wǎng)絡(luò)代理來(lái)實(shí)現(xiàn)，這些代理與應(yīng)用程序代碼一起部署，而不需要感知應(yīng)用程序本身。

目前主流的服務(wù)網(wǎng)格開源軟件是 Istio，其整體架構(gòu)如下：

從圖中可以看到服務(wù)網(wǎng)格與業(yè)務(wù)容器是在同一個(gè) Pod 中的不同容器，帶來(lái)的優(yōu)勢(shì)有如下三點(diǎn)：

1.微服務(wù)治理與業(yè)務(wù)邏輯的解耦。服務(wù)網(wǎng)格把 SDK 中的大部分能力從應(yīng)用中剝離出來(lái)，拆解為獨(dú)立進(jìn)程，以 Sidecar 的模式進(jìn)行部署，服務(wù)網(wǎng)格通過(guò)將服務(wù)通信及相關(guān)管控功能從業(yè)務(wù)程序中分離并下沉到基礎(chǔ)設(shè)施層，使其和業(yè)務(wù)系統(tǒng)完全解耦，使開發(fā)人員更加專注于業(yè)務(wù)本身。

2.異構(gòu)語(yǔ)言/框架的統(tǒng)一治理。隨著新技術(shù)的發(fā)展和人員更替，在同一家公司中往往會(huì)出現(xiàn)不同語(yǔ)言、不同框架的應(yīng)用和服務(wù)，為了能夠統(tǒng)一管控這些服務(wù)，以往的做法是為每種語(yǔ)言、每種框架都開發(fā)一套完整的 SDK，維護(hù)成本非常之高，而且給公司的中間件團(tuán)隊(duì)帶來(lái)了很大的挑戰(zhàn)，有了服務(wù)網(wǎng)格之后，通過(guò)將主體的服務(wù)治理能力下沉到基礎(chǔ)設(shè)施，多語(yǔ)言的支持就輕松很多了。

3.服務(wù)網(wǎng)格不但可以承擔(dān)流量代理，對(duì)于業(yè)務(wù)共用的、通用的場(chǎng)景和需求都可以成為服務(wù)網(wǎng)格的一部分，這樣能有效提高業(yè)務(wù)開發(fā)效率。

應(yīng)用接入服務(wù)網(wǎng)格

目前服務(wù)網(wǎng)格對(duì) Kubernetes 支持最完整，同時(shí)也支持了 VM 的應(yīng)用接入，但是需要較多的配置，我們推薦首先將 VM 上的服務(wù)容器化后在接入網(wǎng)格中，逐步遷移已有的應(yīng)用，通過(guò)網(wǎng)關(guān)來(lái)打通服務(wù)網(wǎng)格中的應(yīng)用和 VM 中沒有接入服務(wù)網(wǎng)格的應(yīng)用。

服務(wù)網(wǎng)格的接入首先是需要安裝 Istiod，然后通過(guò)對(duì) Namespace 打標(biāo)來(lái)完成 Sidecar 的自動(dòng)注入，可以選擇性的對(duì)一些服務(wù)不進(jìn)行 Sidecar 的注入，比如類似 MySQL、Redis 等中間件應(yīng)用，主要是減少 Envoy 帶來(lái)的延遲，在 EDAS 中可以針對(duì)每個(gè)應(yīng)用進(jìn)行打標(biāo)，對(duì)需要加入服務(wù)網(wǎng)格的應(yīng)用才進(jìn)行 Sidecar 的注入。

異構(gòu)微服務(wù)的互通、治理

由于業(yè)務(wù)的發(fā)展，基于業(yè)務(wù)產(chǎn)品的選擇，業(yè)務(wù)開發(fā)語(yǔ)言越來(lái)越多種多樣，這些語(yǔ)言之間的互通成為大家關(guān)注的問(wèn)題，目前常見的場(chǎng)景如 Java 語(yǔ)言和非 Java 語(yǔ)言的互通，互通中最重要的問(wèn)題就是服務(wù)發(fā)現(xiàn)和通信協(xié)議的支持。

服務(wù)發(fā)現(xiàn)

通常我們?cè)谑褂?Kubernetes 上部署服務(wù)如下，其中定義了 Kubernetes Service 用于服務(wù)間請(qǐng)求的域名：

apiVersion: apps/v1 kind: Deployment metadata:name: details-v1labels:app: detailsversion: v1 spec:replicas: 1selector:matchLabels:app: detailsversion: v1template:metadata:labels:app: detailsversion: v1spec:containers:- name: detailsimage: docker.io/istio/examples-bookinfo-details-v1:1.16.2imagePullPolicy: IfNotPresentports:- containerPort: 9080apiVersion: v1 kind: Service metadata:name: detailslabels:app: detailsservice: details spec:ports:- port: 9080name: httpselector:app: details

Istio 監(jiān)聽 Kubernetes Api Server，獲取服務(wù)的 Service、Pod 等數(shù)據(jù)，通過(guò) XDS 方式提供給 Envoy，Envoy 會(huì)通過(guò)獲取的數(shù)據(jù)做負(fù)載均衡。

很多微服務(wù)框架都在使用如 Nacos、Consul、Zookeeper 等注冊(cè)中心，這部分微服務(wù)如何在不進(jìn)行大規(guī)模改造下使用服務(wù)網(wǎng)格呢，這就設(shè)計(jì)到 Istiod 跟注冊(cè)中心的打通，目前社區(qū)提供了以下的幾種方式實(shí)現(xiàn)注冊(cè)中心數(shù)據(jù)打通：

1.MCP Server

編寫自定義的 MCP Server 從第三方注冊(cè)中心獲取服務(wù)數(shù)據(jù)，轉(zhuǎn)換為 ServiceEntry 和 WorkloadEntry 資源，通過(guò) MCP 協(xié)議提供給 Istio 中的 MCP Config Controller， Istiod 需要配置MCP Server地址，目前在開源項(xiàng)目中包含 MCP Server 的注冊(cè)中心的有很多，阿里云 MSE 提供托管的 Nacos 注冊(cè)中心，直接提供 MCP Server 能力。

2.ServiceEntry 和 WorkloadEntry

編寫?yīng)毩⒌牡谌浇M件，該組件從注冊(cè)中心中獲取服務(wù)數(shù)據(jù)，然后轉(zhuǎn)換為 Istio 中 ServiceEntry 和 WorkloadEntry CRD，寫入到 Kubernetes API Server 中。Pilot 的 Kube Controller 會(huì)監(jiān)聽 Kubernetes API Server 中和 Istio 相關(guān)資源的變化，并將 ServiceEntry 和 WorkloadEntry 轉(zhuǎn)換為內(nèi)部Service模型，通過(guò)Xds協(xié)議同步給Sidecar。

3.自定義適配器

編寫自定義的 Adapter 來(lái)集成第三方注冊(cè)中心，該適配器從注冊(cè)中心中獲取服務(wù)和服務(wù)實(shí)例，轉(zhuǎn)換為 Pilot 內(nèi)部的Service模型，集成到 Service Controller 中，類似現(xiàn)有的Consul Service Registry的適配方式，這種方式的優(yōu)點(diǎn)就是不需要通過(guò)第三方進(jìn)行轉(zhuǎn)換，但是跟Istio耦合在一起，在 Istio 版本升級(jí)較快的時(shí)候，需要不斷的適配對(duì)應(yīng)的新版本。

MSE 注冊(cè)中心

第一種方式需要注冊(cè)中心提供支持，第二種方式需要獨(dú)立的三方組件進(jìn)行同步，可用性、維護(hù)是一個(gè)負(fù)擔(dān)，第三種需要對(duì) Istio 非常熟悉，維護(hù)升級(jí)成本很高，目前 MSE 注冊(cè)中心已經(jīng)支持 MCP Over XDS 的方式對(duì)接 Istio，可用性高，免維護(hù)。

我們通過(guò) Java Agent 支持Xds協(xié)議的方式對(duì)接 Istio，同時(shí) Istio 也通過(guò) MCP Over XDS 對(duì)接 Nacos 注冊(cè)中心，這樣服務(wù)發(fā)現(xiàn)的數(shù)據(jù)在 Java Agent 和 Sidecar 中都能拿到， Java 和非 Java 的服務(wù)可以互相發(fā)現(xiàn)，互相調(diào)用。

服務(wù)網(wǎng)格的服務(wù)治理

服務(wù)網(wǎng)格 Sidecar 通過(guò)容器的方式與業(yè)務(wù)容器共享網(wǎng)絡(luò)，通過(guò)Iptables的方式將 inbound 和 outbound 流量都劫持到 Sidecar 上，Sidecar 解析數(shù)據(jù)包，獲取請(qǐng)求后通過(guò)匹配服務(wù)發(fā)現(xiàn)數(shù)據(jù)找到對(duì)應(yīng)的服務(wù)端，然后匹配對(duì)應(yīng)的路由規(guī)則找到滿足條件的服務(wù)端發(fā)送請(qǐng)求。

服務(wù)網(wǎng)格的服務(wù)治理中Istio的路由規(guī)則最關(guān)鍵的兩個(gè)CRD是VirtualService和DestinationRule，他們描述了請(qǐng)求匹配、路由的過(guò)程，如下所示：

apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata:name: reviews spec:host: reviewssubsets:- name: v1labels:version: v1- name: v2labels:version: v2- name: v3labels:version: v3 --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata:name: reviews spec:hosts:- reviewshttp:- route:- destination:host: reviewssubset: v1

DestinationRule 中包含了 reviews 服務(wù)的三個(gè)版本，VirtualService 描述了對(duì) reviews 服務(wù)的請(qǐng)求會(huì)發(fā)送到 subset 為 v1 的版本中。其他的服務(wù)治理能力還包括了故障注入、服務(wù)鑒權(quán)、服務(wù)超時(shí)、熔斷等，可以通過(guò)寫入對(duì)應(yīng)的規(guī)則來(lái)完成，目前Istio也沒有提供非常好使用的白屏化服務(wù)治理界面，在 EDAS/MSE 中提供白屏界面操作如服務(wù)鑒權(quán)、服務(wù)查詢、離群摘除、金絲雀發(fā)布等，保證在操作過(guò)程中流量不丟失，路由規(guī)則的操作需要遵循以下幾個(gè)原則：

1、通常使用服務(wù)網(wǎng)格服務(wù)治理的最佳實(shí)踐方式是從一開始就為每一個(gè)服務(wù)創(chuàng)建具有默認(rèn)路由的 VirtualService，即當(dāng)你只有一個(gè)版本的時(shí)候，就寫入該版本的 VirtualService 規(guī)則，這樣在你部署第二個(gè)版本中，不至于流量會(huì)打到第二個(gè)版本中，需要配置路由規(guī)則才可以，保證新版本驗(yàn)證過(guò)程中不會(huì)出現(xiàn)由于新版本自身問(wèn)題導(dǎo)致的大規(guī)模報(bào)錯(cuò)。

2、VirtualService 和 DestinationRule 在使用的過(guò)程中，Envoy 會(huì)首先查看 VirtualService 中的路由規(guī)則，以決定是否路由到特定的子集去，只有路由到對(duì)應(yīng)的子集才會(huì)激活在 DestinationRule 中對(duì)應(yīng)子集配置的如熔斷、離群摘除等規(guī)則，同時(shí)可以看出 VirtualService 和DestinationRule 的配置也是有順序的，首先配置 DestinationRule，然后在配置 VirtualService，否則會(huì)導(dǎo)致找不到對(duì)應(yīng)的 Subset 報(bào)錯(cuò)。

3、更新 DestinationRule 添加一個(gè)新的 Subset 后，需要等待 DestinationRule 傳播到 Envoy Sidecar，然后再更新對(duì)應(yīng)的 VirtualService。

雙模微服務(wù)治理

互通的問(wèn)題通過(guò)對(duì)接注冊(cè)中心的方式解決了，那異構(gòu)框架的服務(wù)治理則通過(guò) MSE 來(lái)支持，MSE 的服務(wù)治理中心可以對(duì)接 Java 服務(wù)，同時(shí)也可以支持服務(wù)網(wǎng)格的服務(wù)。

MSE 在控制面上支持雙模微服務(wù)治理，即 Java 服務(wù)治理和非 Java 服務(wù)治理，控制面對(duì)外提供統(tǒng)一的治理模型，我們參考 Istio 的路由規(guī)則設(shè)計(jì)模型，提出一個(gè)統(tǒng)一的服務(wù)治理規(guī)則模型，模型的設(shè)計(jì)主要考慮到 Dubbo、Spring Cloud 和服務(wù)網(wǎng)格治理的通用性。

{"RegisterConfig":Object{...},"protocol":"springcloud","rule_type":"fault_inject","rule":{"hosts":Array[1],"rule_policy":[{"match":Array[1],"fault":Object{...},"route":Array[1],"Timeout":"10s","retries":Object{...},"mirror":Object{...},"mirror_percent":100,"headers":Object{...},"tls":Object{...}},{"route":[{"destination":Object{...},"weight":"100","headers":Object{...}}]}]} }

上述模型中包含了注冊(cè)中心、協(xié)議、規(guī)則類型、路由規(guī)則，路由規(guī)則中包含了匹配的規(guī)則和路由的目的地，MSE通過(guò)生成對(duì)應(yīng)這樣的CRD來(lái)定義不同類型的路由規(guī)則，Java Agent 的和服務(wù)網(wǎng)格都可以通過(guò)監(jiān)聽這樣的 CRD 來(lái)管理自己的流量，后續(xù)我們也會(huì)在 OAM 中推出這一套微服務(wù)治理規(guī)則，用于統(tǒng)一服務(wù)治理模型。

MSE微服務(wù)治理

服務(wù)查詢：

標(biāo)簽路由：

離群實(shí)例摘除：

可觀測(cè)

社區(qū)開源方案

可觀測(cè)是微服務(wù)能力的重要組成部分，服務(wù)網(wǎng)格可以跟目前開源的可觀測(cè)產(chǎn)品結(jié)合，可觀測(cè)性上主要圍繞 Metrics、Tracing 和 Logging 來(lái)展開，在 Metrics 上提供數(shù)據(jù)供 Prometheus 采集，在 Tracing上，Istio 支持 Apache SKyWalking、Zipkin、Jaeger 的鏈路追蹤，這三個(gè)中間件都支持 OpenTracing 協(xié)議，在 Logging 上，對(duì)于日志采集組件的要求也越來(lái)越高，目前比較流行的方案是使用 Fluentd 或者 Filebeat 替代 Logstash。

阿里云 EDAS 方案

阿里云 Xtrace 為服務(wù)網(wǎng)格提供可觀測(cè)能力，包含鏈路追蹤、應(yīng)用概覽、拓?fù)洹etrics 統(tǒng)計(jì)，在應(yīng)用發(fā)布后直接可以通過(guò)應(yīng)用詳情查看，如下圖所示：

拓?fù)鋱D如下：

可以通過(guò)鏈路追蹤查看每個(gè)請(qǐng)求過(guò)程中的問(wèn)題，協(xié)助問(wèn)題定位，同時(shí) Xtrace 也提供了不同語(yǔ)言的 SDK，接入 SDK 后可以查看更細(xì)粒度的數(shù)據(jù)。

原文鏈接：https://developer.aliyun.com/article/781566?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的服务网格的最佳实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。