服务网格：service_mesh

简介

Service Mesh 翻译为“服务网格”，作为服务间通信的基础设施层。

• 它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。
• 在实践中，Service Mesh 通常以轻量级网络代理的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。

提出目的

• Service Mesh 目的是 解决系统架构微服务化后的服务间通信和治理问题。
• 服务网格由Sidecar节点组成，这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦。
• 具体到微服务架构中，即给每一个微服务实例同步部署一个Sidecar。这个 Sidecar 就是该服务的 Proxy，所有的流量都会走Proxy
  

  在Service Mesh部署网络结构图中，绿色方块为应用服务，蓝色方块为 Sidecar，应用服务之间通过 Sidecar 进行通信，整个服务通信形成图中的蓝色网络连线，图中所有蓝色部分就形成了Service Mesh。

其具备如下主要特点：

• 应用程序间通讯的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh 对于应用程序来说是透明的，应用程序的服务发现、服务注册、负载均衡、过载保护、流量调度等工作均被 Service Mesh 接管。

Service Mesh 功能

Service Mesh 作为微服务架构中负责网络通信的基础设施层，具备网络处理的大部分功能。下面列举了一些主要的功能：

• 动态路由。 可通过路由规则来动态路由到所请求的服务，便于不同环境、不同版本等的动态路由调整。
• 故障注入。 通过引入故障来模拟网络传输中的问题（如延迟）来验证系统的健壮性，方便完成系统的各类故障测试。
• 熔断。 通过服务降级来终止潜在的关联性错误。
• 安全。 在Service Mesh上实现安全机制（如TLS），并且很容易在基础设施层完成安全机制更新。
• 多语言支持。 作为独立运行且对业务透明的 Sidecar 代理，Service Mesh 很轻松地支持多语言的异构系统。
  多协议支持。 同多语言一样，也支持多协议。
  指标和分布式链路追踪。

概括起来，Service Mesh 主要体现在以下 4 个方面：

• 可见性： 运行时指标遥测、分布式跟踪。
• 可管理性： 服务发现、负载均衡、运行时动态路由等。
• 健壮性： 超时、重试、熔断等弹性能力。
• 安全性： 服务间访问控制、TLS 加密通信。

Service Mesh 解决的问题

综合上述，Service Mesh主要解决用户如下 3 个维度的痛点需求：

• 完善的微服务基础设施
  通过将微服务通信下沉到基础设施层，屏蔽了微服务处理各种通信问题的复杂度，形成微服务之间的抽象协议层。开发者无需关心通信层的具体实现，也无需关注RPC通信（包含服务发现、负载均衡、流量调度、流量降级、监控统计等）的一切细节，真正像本地调用一样使用微服务，通信相关的一起工作直接交给Service Mesh。

• 语言无关的通信和链路治理
  功能上，Service Mesh并没有提供任何新的特性和能力，Service Mesh提供的所有通信和服务治理能力在Service Mesh之前的技术中均能找到，比如Spring Cloud就实现了完善的微服务RPC通信和服务治理支持。 Service Mesh 改变的是通信和服务治理能力提供的方式，通过将这些能力实现从各语言业务实现中解耦，下沉到基础设施层面，以一种更加通用和标准化的方式提供，屏蔽不同语言、不同平台的差异性，有利于通信和服务治理能力的迭代和创新，使得业务实现更加方便
  Service Mesh避免了多语言服务治理上的重复建设，通过Service Mesh语言无关的通信和服务治理能力，助力于多语言技术栈的效率提升。

• 通信和服务治理的标准化

  • 微服务治理层面，Service Mesh 是标准化、体系化、无侵入的分布式治理平台。
  • 标准化方面，Sidecar 成为所有微服务流量通信的约束标准，同时Service Mesh的数据平台和控制平面也通过标准协议进行交互。
  • 体系化方面，从全局考虑，提供多维度立体的微服务可观测能力（Metric、Trace、Logging），并提供体系化的服务治理能力，如限流、熔断、安全、灰度等。

通过标准化，带来一致的服务治理体验，减少多业务之间由于服务治理标准不一致带来的沟通和转换成本，提升全局服务治理的效率。

Service Mesh 原理

Service Mesh 的核心是数据平面 Sidecar 与控制平面 Control Plane，如下图：

• 数据平面： Sidecar，与服务部署在一起的轻量级网络代理，用于实现服务框架的各项功能（如，服务发现、负载均衡、限流熔断等），让服务回归业务本质。

  • 数据平台可以认为是将 Spring Cloud、Dubbo 等相关的微服务框架中通信和服务治理能力独立出来的一个语言无法的进程，并且更注重通用性和扩展性。
  • 在 Service Mesh 中，不再将数据平面代理视为一个个独立的组件，而是将这些代理连接在一起形成一个全局的分布式网格。
  • 在传统的微服务架构中，各种服务框架的功能（如，服务发现、负载均衡、限流熔断等）代码逻辑或多或少的都需要耦合到服务实例的代码中，给服务实例增加了很多无关业务的代码，同时带来了一定的复杂度。有了 Sidecar之后，服务节点只做业务逻辑自身的功能，服务之间的调用只需交给 Sidecar，由Sidecar 完成注册服务、服务发现、请求路由、熔断限流、日志统计等业务无关功能。
  • 在这种新的微服务架构中，所有的 Sidecar 组成在一起，就形成了服务网格。那么这个大型的服务网格并不是完全自治的，它还需要一个统一的控制节点 Control Plane。

• 控制平面： 是用来从全局的角度上控制 Sidecar，相当于 Service Mesh 架构的大脑，控制着 Sidecar 来实现服务治理的各项功能。比如，它负责所有 Sidecar 的注册，存储统一的路由表，帮助各个 Sidecar 进行负载均衡和请求调度；它收集所有 Sidecar的监控信息和日志数据。