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

Service Mesh 被你们称为下一代的微服务，是微服务领域的一颗新星，被你们讨论的很是多。

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

哈哈，没办法，互联网技术就是发展得这么快，这些技术其实也都是因为你们所在的公司业务规模和复杂度变大之后所推进出来的。

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

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

1、什么是「 Service Mesh 」？

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

Service Mesh 就是一个基础设施层，它是用于处理微服务中，服务与服务之间通讯的一种技术。在 Service Mesh 的实践方案中，它是由一系列轻量级的网络代理组成的，而且这些网络代理会与我们的应用部署在一块儿，特别适用于云原生应用，由于 Service Mesh 能够作到应用是无感知的。

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

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

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

2、为何须要「 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 的原理。

3、「 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技术 等。