全国服务热线:

服务网格的最佳实践

来源: 发布日期:2021-02-09 07:51 浏览:

原标题:服务网格的最佳实践

简介: 服务网格是用于处理服务间通讯的专用基础设施层。它担任经过包括现代云原生运用程序的杂乱服务拓扑来可靠地传递恳求。

微服务开展的这几年,新的技能和概念层出不穷,这些技能的引进本质上都是在环绕服务稳定性和事务开发功率进步,最近两年服务网格越来越被广阔的微服务用户所认知。

在 Kubernetes 现已成为云原生年代的操作体系的今日,怎么更好的拥抱 Kubernetes 生态,完结事务快速上云,享用云核算带来的才能,其间服务网格是一个必需求提的要害技能,可是在服务网格运用进程中咱们会碰到许多的问题,比方:怎么让现有的运用搬迁到服务网格,怎么支撑多种言语、结构的互通和办理,怎么运用可观测产品排查问题,接下来我将从怎么接入服务网格、异构服务结构、言语的互通和可观测三个方面答复这个问题。

搬迁运用到服务网格中

服务网格

服务网格是用于处理服务间通讯的专用基础设施层,它担任经过包括现代云原生运用程序的杂乱服务拓扑来可靠地传递恳求。实际上,服务网格一般经过一组轻量级网络署理来完结,这些署理与运用程序代码一同布置,而不需求感知运用程序本身。

现在干流的服务网格开源软件是 Istio,其全体架构如下:

从图中能够看到服务网格与事务容器是在同一个 Pod 中的不同容器,带来的优势有如下三点:

1.微服务办理与事务逻辑的解耦。服务网格把 SDK 中的大部分才能从运用中剥离出来,拆解为独立进程,以 Sidecar 的形式进行布置,服务网格经过将服务通讯及相关管控功用从事务程序中别离并下沉到基础设施层,使其和事务体系彻底解耦,使开发人员愈加专心于事务本身。

2.异构言语/结构的一致办理。跟着新技能的开展和人员替换,在同一家公司中往往会呈现不同言语、不同结构的运用和服务,为了能够一致管控这些服务,以往的做法是为每种言语、每种结构都开发一套完好的 SDK,保护本钱十分之高,并且给公司的中间件团队带来了很大的应战,有了服务网格之后,经过将主体的服务办理才能下沉到基础设施,多言语的支撑就轻松许多了。

3.服务网格不光能够承当流量署理,关于事务共用的、通用的场景和需求都能够成为服务网格的一部分,这样能有用进步事务开发功率。

打开全文

运用接入服务网格

现在服务网格对 Kubernetes 支撑最完好,一起也支撑了 VM 的运用接入,可是需求较多的装备,咱们引荐首要将 VM 上的服务容器化后在接入网格中,逐渐搬迁已有的运用,经过网关来打通服务网格中的运用和 VM 中没有接入服务网格的运用。

服务网格的接入首要是需求装置 Istiod,然后经过对 Namespace 打标来完结 Sidecar 的主动注入,能够挑选性的对一些服务不进行 Sidecar 的注入,比方相似 MySQL、Redis 等中间件运用,首要是削减 Envoy 带来的推迟,在 EDAS 中能够针对每个运用进行打标,对需求参加服务网格的运用才进行 Sidecar 的注入。

异构微服务的互通、办理

因为事务的开展,根据事务产品的挑选,事务开发言语越来越多种多样,这些言语之间的互通成为咱们重视的问题,现在常见的场景如 Java 言语和非 Java 言语的互通,互通中最重要的问题便是服务发现和通讯协议的支撑。

服务发现

一般咱们在运用 Kubernetes 上布置服务如下,其间界说了 Kubernetes Service 用于服务间恳求的域名:

apiVersion: apps/v1

kind: Deployment

metadata:

name: details-v1

labels:

app: details

version: v1

spec:

replicas: 1

selector:

matchLabels:

app: details

version: v1

template:

metadata:

labels:

app: details

version: v1

spec:

containers:

- name: details

image: docker.io/istio/examples-bookinfo-details-v1:1.16.2

imagePullPolicy: IfNotPresent

ports:

- containerPort: 9080

apiVersion: v1

kind: Service

metadata:

name: details

labels:

app: details

service: details

spec:

ports:

- port: 9080

name: http

selector:

app: details

Istio 监听 Kubernetes Api Server,获取服务的 Service、Pod 等数据,经过 XDS 方法供给给 Envoy,Envoy 会经过获取的数据做负载均衡。

许多微服务结构都在运用如 Nacos、Consul、Zookeeper 等注册中心,这部分微服务怎么在不进行大规模改造下运用服务网格呢,这就规划到 Istiod 跟注册中心的打通,现在社区供给了以下的几种方法完结注册中心数据打通:

1.MCP Server

编写自界说的 MCP Server 从第三方注册中心获取服务数据,转化为 ServiceEntry 和 WorkloadEntry 资源,经过 MCP 协议供给给 Istio 中的 MCP Config Controller, Istiod 需求装备MCP Server地址,现在在开源项目中包括 MCP Server 的注册中心的有许多,阿里云 MSE 供给保管的 Nacos 注册中心,直接供给 MCP Server 才能。

2.ServiceEntry 和 WorkloadEntry

编写独立的第三方组件,该组件从注册中心中获取服务数据,然后转化为 Istio 中 ServiceEntry 和 WorkloadEntry CRD,写入到 Kubernetes API Server 中。Pilot 的 Kube Controller 会监听 Kubernetes API Server 中和 Istio 相关资源的改变,并将 ServiceEntry 和 WorkloadEntry 转化为内部Service模型,经过Xds协议同步给Sidecar。

3.自界说适配器

编写自界说的 Adapter 来集成第三方注册中心,该适配器从注册中心中获取服务和服务实例,转化为 Pilot 内部的Service模型,集成到 Service Controller 中,相似现有的Consul Service Registry的适配方法,这种方法的长处便是不需求经过第三方进行转化,可是跟Istio耦合在一同,在 Istio 版别晋级较快的时分,需求不断的适配对应的新版别。

MSE 注册中心

第一种方法需求注册中心供给支撑,第二种方法需求独立的三方组件进行同步,可用性、保护是一个担负,第三种需求对 Istio 十分了解,保护晋级本钱很高,现在 MSE 注册中心现已支撑 MCP Over XDS 的方法对接 Istio,可用性高,免保护。

咱们经过 Java Agent 支撑Xds协议的方法对接 Istio,一起 Istio 也经过 MCP Over XDS 对接 Nacos 注册中心,这样服务发现的数据在 Java Agent 和 Sidecar 中都能拿到, Java 和非 Java 的服务能够相互发现,相互调用。

服务网格的服务办理

服务网格 Sidecar 经过容器的方法与事务容器同享网络,经过Iptables的方法将 inbound 和 outbound 流量都绑架到 Sidecar 上,Sidecar 解析数据包,获取恳求后经过匹配服务发现数据找到对应的服务端,然后匹配对应的路由规矩找到满意条件的服务端发送恳求。

服务网格的服务办理中Istio的路由规矩最要害的两个CRD是VirtualService和DestinationRule,他们描绘了恳求匹配、路由的进程,如下所示:

apiVersion: networking.istio.io/v1alpha3

kind: DestinationRule

metadata:

name: reviews

spec:

host: reviews

subsets:

- name: v1

labels:

version: v1

- name: v2

labels:

version: v2

- name: v3

labels:

version: v3

---

apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: reviews

spec:

hosts:

- reviews

http:

- route:

- destination:

host: reviews

subset: v1

DestinationRule 中包括了 reviews 服务的三个版别,VirtualService 描绘了对 reviews 服务的恳求会发送到 subset 为 v1 的版别中。其他的服务办理才能还包括了故障注入、服务鉴权、服务超时、熔断等,能够经过写入对应的规矩来完结,现在Istio也没有供给十分好运用的白屏化服务办理界面,在 EDAS/MSE 中供给白屏界面操作如服务鉴权、服务查询、离群去除、金丝雀发布等,确保在操作进程中流量不丢掉,路由规矩的操作需求遵从以下几个准则:

1、一般运用服务网格服务办理的最佳实践方法是从一开端就为每一个服务创立具有默许路由的 VirtualService,即当你只要一个版别的时分,就写入该版别的 VirtualService 规矩,这样在你布置第二个版别中,不至于流量会打到第二个版别中,需求装备路由规矩才能够,确保新版别验证进程中不会呈现因为新版别本身问题导致的大规模报错。

2、VirtualService 和 DestinationRule 在运用的进程中,Envoy 会首要检查 VirtualService 中的路由规矩,以决议是否路由到特定的子集去,只要路由到对应的子集才会激活在 DestinationRule 中对应子集装备的如熔断、离群去除等规矩,一起能够看出 VirtualService 和DestinationRule 的装备也是有次序的,首要装备 DestinationRule,然后在装备 VirtualService,否则会导致找不到对应的 Subset 报错。

3、更新 DestinationRule 增加一个新的 Subset 后,需求等候 DestinationRule 传播到 Envoy Sidecar,然后再更新对应的 VirtualService。

双模微服务办理

互通的问题经过对接注册中心的方法处理了,那异构结构的服务办理则经过 MSE 来支撑,MSE 的服务办理中心能够对接 Java 服务,一起也能够支撑服务网格的服务。

MSE 在操控面上支撑双模微服务办理,即 Java 服务办理和非 Java 服务办理,操控面对外供给一致的办理模型,咱们参阅 Istio 的路由规矩规划模型,提出一个一致的服务办理规矩模型,模型的规划首要考虑到 Dubbo、Spring Cloud 和服务网格办理的通用性。

{

"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{...}

}

]

}

]

}

}

上述模型中包括了注册中心、协议、规矩类型、路由规矩,路由规矩中包括了匹配的规矩和路由的目的地,MSE经过生成对应这样的CRD来界说不同类型的路由规矩,Java Agent 的和服务网格都能够经过监听这样的 CRD 来办理自己的流量,后续咱们也会在 OAM 中推出这一套微服务办理规矩,用于一致服务办理模型。

MSE微服务办理

服务查询:

标签路由:

离群实例去除:

可观测

社区开源计划

可观测是微服务才能的重要组成部分,服务网格能够跟现在开源的可观测产品结合,可观测性上首要环绕 Metrics、Tracing 和 Logging 来打开,在 Metrics 上供给数据供 Prometheus 收集,在 Tracing上,Istio 支撑 Apache SKyWalking、Zipkin、Jaeger 的链路追寻,这三个中间件都支撑 OpenTracing 协议,在 Logging 上,关于日志收集组件的要求也越来越高,现在比较盛行的计划是运用 Fluentd 或许 Filebeat 代替 Logstash。

阿里云 EDAS 计划

阿里云 Xtrace 为服务网格供给可观测才能,包括链路追寻、运用概览、拓扑、Metrics 计算,在运用发布后直接能够经过运用概况检查,如下图所示:

拓扑图如下:

能够经过链路追寻检查每个恳求进程中的问题,帮忙问题定位,一起 Xtrace 也供给了不同言语的 SDK,接入 SDK 后能够检查更细粒度的数据。

作者:中间件小哥

本文为阿里云原创内容,未经答应不得转载回来,检查更多

责任编辑: