Service Mesh是什么，为我们解决了什么问题？

偏执的太偏执、 2022-11-12 01:59 241阅读 0赞

# 1、Service Mesh介绍 #

`Service Mesh`翻译为“服务网格”，作为**服务间通信的基础设施层**。轻量级高性能网络代理，提供安全的、快速的、可靠地服务间通讯，与实际应用部署一起，但对应用透明。应用作为服务的发起方，只需要用最简单的方式将请求发送给本地的服务网格代理，然后网格代理会进行后续的操作，如服务发现，负载均衡，最后将请求转发给目标服务。

**`Service Mesh`目的是解决系统架构微服务化后的服务间通信和治理问题。** 服务网格由`Sidecar`节点组成，这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦。具体到微服务架构中，即给每一个微服务实例同步部署一个`Sidecar`。  
![Service Mesh部署网络结构图][Service Mesh]  
在`Service Mesh`部署网络结构图中，绿色方块为应用服务，蓝色方块为 `SideCar`，应用服务之间通过`Sidecar`进行通信，整个服务通信形成图中的蓝色网络连线，图中所有蓝色部分就形成了`Service Mesh`。其具备如下主要特点：

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

# 2、Service Mesh解决的问题 #

从上述`Service Mesh`的定义看：

*  **基础设施层是`Service Mesh`的定位**，致力于解决微服务基础设施标准化、配置化、服务化和产品化的问题。
 *  **服务间通信是`Service Mesh`技术层面对的问题**，对微服务屏蔽通信的复杂度，解决微服务的通信治理问题。
 *  请求的可靠传递是`Service Mesh`的目标。
 *  轻量级网络代理是`Service Mesh`的部署方式。
 *  对应用程序透明是`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`），并提供体系化的服务治理能力，如限流、熔断、安全、灰度等。
    
    通过标准化，带来一致的服务治理体验，减少多业务之间由于服务治理标准不一致带来的沟通和转换成本，提升全局服务治理的效率。

# 3、Service Mesh的原理 #

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

![Service Mesh架构图][Service Mesh 1]

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

[Service Mesh]: /images/20221022/016feacc6f9c4dd9bafeb6f98ae0bbf1.png
[Service Mesh 1]: /images/20221022/7cad7fb54e6c464f935300dc4fa8349a.png