服务网格Service Mesh学习整理

zmm0420

已于 2022-06-15 15:05:36 修改

阅读量2.7k

点赞数

分类专栏：微服务文章标签：学习 mesh

于 2022-06-15 14:49:15 首次发布

本文链接：https://blog.csdn.net/zmm0420/article/details/125296895

版权

微服务专栏收录该内容

7 篇文章 0 订阅

订阅专栏

服务网格从总体架构上来讲，就是一堆紧挨着各项服务的用户代理，外加一组任务管理流程组成。

代理在服务网格中被称为数据层或数据平面（data plane），

管理流程被称为控制层或控制平面（control plane）。

数据平面截获不同服务之间的调用并对其进行“处理”；

控制平面协调代理的行为，并为运维人员提供 API，用来操控和测量整个网络。

服务网格是一个专用的基础设施层，旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格，而是一个“代理”的网格，服务可以插入这个代理，从而使网络抽象化。在典型的服务网格中，这些代理作为一个 sidecar（边车）被注入到每个服务部署中。服务不直接通过网络调用服务，而是调用它们本地的 sidecar 代理，而 sidecar 代理又代表服务管理请求，从而封装了服务间通信的复杂性。相互连接的 sidecar 代理集实现了所谓的数据平面，这与用于配置代理和收集指标的服务网格组件（控制平面）形成对比。

Service Mesh 的基础设施层主要分为两部分：控制平面与数据平面。当前流行的两款开源服务网格 Istio 和 Linkerd 实际上都是这种构造。

控制平面的特点：

不直接解析数据包。
与控制平面中的代理通信，下发策略和配置。
负责网络行为的可视化。
通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。

数据平面的特点：

通常是按照无状态目标设计的，但实际上为了提高流量转发性能，需要缓存一些数据，因此无状态也是有争议的。
直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
对应用来说透明，即可以做到无感知部署。

在Service Mesh中，当我们将一个服务部署在Kubernetes之后，安装在Kubernetes中的Service Mesh组件（例如Istio）就会自动在该微服务的同一个Pod之中启动一个与之对应的代理进程（例如istio-proxy），这个保姆式的代理进程会代替微服务本身去实现原先在Spring Cloud体系中需要微服务自身完成的服务注册、负载均衡、熔断限流等微服务治理功能。并且，这些代理进程并不是孤军奋战，而是会通过像xDS协议（Service Mesh中数据面与控制面通信的通用协议）与Service Mesh控制组件保持连接。

这也就引出了Service Mesh架构中关键的两个概念：控制面与数据面。前面我们所示的Sidecar（例如istio-proxy，实际上是envoy）就是数据面，与微服务治理逻辑相关的信息都存储在数据面中，而控制面则是Service Mesh的中心控制组件（例如Istio中的Pilot组件），控制面可以通过xDS协议（具体又分为LDS、CDS...）向数据面下发各种服务治理相关的规则，例如限流规则、路由规则、服务节点更新信息等等。

这种设计方式就是Service Mesh最核心的设计逻辑——通过Sidecar的方式代理微服务进行服务治理逻辑（数据面），通过控制面感知外界环境的变化并通过xDS协议支持各种微服务治理策略规则的集中管理和下发，而这里的控制面和数据面都会被融合进像Kubernetes这样的基础架构环境中，对于普通微服务的开发，研发人员要做的只是将一个应用以编排的方式部署进k8s集群即可！而所有与微服务治理相关的逻辑都由代理数据面与控制面协作完成。

这里我们以Service Mesh最著名的开源方案Istio的架构图来解释上面所说的逻辑，具体如下：