微服务架构之「 下一代微服务 Service Mesh 」

Posted 2022-02-13 jsjwk

Service Mesh 被大家称为下一代的微服务，是微服务领域的一颗新星，被大家讨论的非常多。

我在大家的讨论中，还看到有人说 “目前的微服务架构我都没学会呢，现在又来一个下一代微服务，真学不动了”。

哈哈，没办法，互联网技术就是发展得这么快，这些技术其实也都是由于大家所在的公司业务规模和复杂度变大以后所推动出来的。

最开始 Service Mesh 的概念是由Buoyant公司在2016年提出。然后在随后几年，业内就围绕着 Service Mesh 思想探索出了各种实现，其中包括以 Linkerd 为代表的第一代 Service Mesh，随后又有以 Istio 为代表的第二代 Service Mesh。

在国内的一些大厂里，例如 阿里、新浪 等，也都有基于Service Mesh思想的自研实现。既然 Service Mesh 这么火，那它到底是什么呢？又该如何去应用呢？

一、什么是「 Service Mesh 」？

Service Mesh 中文称为 服务网格，为啥，因为它的部署图看起来就像一个网格，如下图：

Service Mesh 就是一个基础设施层，它是用于处理微服务中，服务与服务之间通信的一种技术。在 Service Mesh 的实践方案中，它是由一系列轻量级的网络代理组成的，并且这些网络代理会与咱们的应用部署在一起，特别适用于云原生应用，因为 Service Mesh 可以做到应用是无感知的。

（上图的绿色小块可以理解成是咱们微服务的应用，蓝色小块可以理解成 Service Mesh 的轻量级网络代理）

有了 Service Mesh 之后，微服务中，服务与服务之间的通信就是靠这些 网络代理模块 来保障。

那我们为啥需要采用 Service Mesh 呢，Service Mesh 帮我们解决了目前微服务之间调用的啥痛点了吗？

二、为什么需要「 Service Mesh 」？

在传统微服务架构中，随着业务越来越大，拆分的服务实例也越来越多，那么各个服务之间的依赖就变成了非常复杂的网络拓扑结构，可能就类似于这样了：

哈哈，晕图了、晕图了！

在如此复杂的分布式部署结构下，咱们微服务中服务依赖调用和数据传输所面临的问题也成倍增加，极大的提高了服务治理的难度。

同时，由于 容器化技术 的成熟和规模化，微服务都会采用容器化，并朝着 云原生应用 的方向发展。而传统的微服务架构中，虽然也有服务治理的组件，但是这些组件大多需要在应用代码里进行集成，这是不符合 云原生应用 的思想的。因此，大家急需一个标准化，能高效部署和运维的微服务体系方案。

因此，Service Mesh 就出现了，Service Mesh 就是用来解决这些痛点的，设计的目的就是用来解决微服务架构中 服务间可靠调用、服务治理 等问题。

下面就拿第一代 Service Mesh 产品 Linkerd 举例说明：

图中可以看到，每一个服务实例（Service）的部署都会同时部署一个 Linkerd 实例，并且服务之间的调用并不是直接进行的，而是先经过 Linkerd 模块去代理转发完成的。

例如：Service A 需要调用 Service B 的时候，Service A 是把请求发给与它一起部署的 Linkerd-1 的，然后这个 Linkerd-1 将请求发给 Service B 所部署模块的 Linkerd-2，然后  Linkerd-2 再将请求内容转发给 Service B 处理。因此，在整个流程中，Service A  和 Service B 只需要关注自己的业务逻辑即可，无需关注任何服务框架的功能，这些服务框架的功能都是由Linkerd 去实现，Linkerd 要做 负载均衡、熔断、限流、监控等等。

下面我们具体来看看 Service Mesh 的原理。

三、「 Service Mesh 」的原理与应用？

Service Mesh 的核心其实就2个模块：SideCar 与  Control Plane，如图：

搞懂了 SideCar 与  Control Plane 也就对 Service Mesh 的基础思想原理明白了。

1. SideCar：

   上面说到的与服务部署在一起的轻量级网络代理也就是指SideCar，它的作用就是实现服务框架的各项功能，这样，就可以让服务（Service A 或 Service B）回归业务本质。

   传统的微服务架构中，各种服务框架的功能（例如：服务发现、负载均衡、限流熔断等）都代码逻辑或多或少的都需要耦合到服务实例的代码里，给服务实例增加了很多无关业务的代码，也带来了复杂度。

   有了SideCar之后，服务节点只做业务逻辑自身的功能，服务之间的调用交给了SideCar，由SideCar去注册服务、去做服务发现、去做请求路由、去实现熔断限流、去做日志统计。

   那么在这种新的微服务架构中，所有的 SideCar 组成在一起，其实就是一个服务网格了。那么这个大型的服务网格并不是完全自治的，它还需要一个统一的控制节点，也就是 Control Plane。

2. Control Plane：

   

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

在文章的最开始提到过，以 Linkerd 为代表的被称为第一代 Service Mesh，而以 Istio 为代表的称为了第二代 Service Mesh。主要的不同就是 Istio 引入了 Control Plane 的概念，可以通过  Control Plane 来对服务进行一些精细化控制，所以 Istio 也被称为是实际上的 Service Mesh 标准产品。

以上，就是我对微服务架构中「 Service Mesh」的一些思考，你是怎么看的呢？

码字不易啊，喜欢的话不妨转发朋友，或点击文章右下角的“在看”吧。??

本文原创发布于微信公众号「 不止思考 」，欢迎关注。涉及 思维认知、个人成长、架构、Web技术 等。