Service Mesh

Service Mesh

参考如下文章：可以将此文章看作为下面文章的结合：

https://zhuanlan.zhihu.com/p/61901608

https://philcalcado.com/2017/08/03/pattern_service_mesh.html

https://zhuanlan.zhihu.com/p/153105848?from_voters_page=true

微服务演化进程

0. 想象中，不同服务间通信的方式：A和B之间通信

1. 原始通信时代

   然而现实很骨感。在实际情况中，通信需要底层能够传输字节码和电子信号的物理层来完成。

   在TCP协议出现之前，服务需要自己处理网络通信所面临的丢包、乱序、重试等一系列流控问题。

   因此服务实现中，除了业务逻辑外，还夹杂着对网络传输问题的处理逻辑。

2. TCP时代

   为了避免每个服务都需要自己实现一套相似的网络传输处理逻辑.

   TCP协议出现了，它解决了网络传输中通用的流量控制问题，将技术栈下移，从服务的实现中抽离出来，成为操作系统网络层的一部分。
   

3. 第一代微服务

   在TCP出现之后，机器之间的网络通信不再是一个难题.

   以GFS/BigTable/MapReduce为代表的分布式系统得以蓬勃发展。

   这时，分布式系统特有的通信语义又出现了，如熔断策略、负载均衡、服务发现、认证和授权、quota限制、trace和监控等等，于是服务根据业务需求来实现一部分所需的通信语义。
   

4. 第二代微服务

   为了避免每个服务都需要自己实现一套分布式系统通信的语义功能.

   随着技术的发展，一些面向微服务架构的开发框架出现了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等等，这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。

边车模式迭代到服务网格

Sidecar pattern

Deploy components of an application into a separate process or container to provide isolation and encapsulation.

将应用程序的组件部署到单独的进程或容器中，以提供隔离和封装。

— Sidecar pattern

边车模式的通俗理解：

边车模式最好的例子无疑是三轮摩托车，边车就是主摩托车上加装的来达到扩展功能的装置。比如：

• 增强稳定性
• 载人和载物等
• 行驶更加稳定
• 给驾驶员提供其余服务等

在软件架构中，边车模式就是给应用服务加装一个边车来达到控制和逻辑分离的目的。在分布式中：比如日志记录，监控，流量控制，服务注册与发现，服务熔断和限流等在业务服务中不需要实现的控制面功能，可以交给边车。业务服务只需要专注实现业务逻辑即可。如上图一样，与分布式微服务架构完美契合，体现了控制和逻辑的分离与解耦。

边车模式解决的问题和Service Mesh出现的契机

边车模式解决的问题

分析第二代微服务模式存在的问题：

• 其一，虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事；
• 其二，开发框架通常只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到；
• 其三，框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级；

在软件设计上这个边车可以理解为一个agent，这个agnet和服务一起创建、销毁。将服务注册与发现、监控、流量控制、日志记录、服务限流与熔断等功能做成标准化的组件和模块，不需要在单独实现其功能来消耗业务开发的精力和时间来开发和调试这些功能，这样可以开发出真正高内聚低耦合的软件。

边车模式是基于将控制与逻辑分离和解耦的思想，即让专业的人做专业的事，业务代码只需要关心其复杂的业务逻辑，其他的事情”边车“会帮其处理。

例如：Linkerd，Envoy，NginxMesh为代表的代理模式（边车模式）

Service Mesh的出现

边车模式有效的分离了系统控制和业务逻辑，可以将所有的服务进行统一管理，让开发人员更专注于业务开发，显著的提升开发效率。而遵循这种模式进行实践从很早以前就开始了。

开发人员一直尝试将上文中我们提到的功能（如：流量控制、服务注册、服务发现、服务限流、服务熔断等）提取成一个标准化的 Sidecar ，通过 Sidecar 代理来与其他系统进行交互，这样可以大大简化业务开发和运维。而随着分布式架构和微服务被越来越多的公司和开发者接受并使用，这一需求日益凸显。这就是 Service Mesh 服务网格诞生的契机。

Service Mesh 有如下几个特点：

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

Service Mesh 将底层那些难以控制的网络通讯统一管理，诸如：流量管控，丢包重试，访问控制等。而上层的应用层协议只需关心业务逻辑即可。Service Mesh 是一个用于处理服务间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求。

Service Mesh

现在，我们再看Buoyant的CEO William Morgan，也就是Service Mesh这个词的发明人，对Service Mesh的定义：

服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭**。

在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。

这个定义中，有四个关键词：

基础设施层+请求在这些拓扑中可靠穿梭：这两个词加起来描述了Service Mesh的定位和功能，是不是似曾相识？没错，你一定想到了TCP；

网络代理：这描述了Service Mesh的实现形态；

对应用透明：这描述了Service Mesh的关键特点，正是由于这个特点，Service Mesh能够解决以Spring Cloud为代表的第二代微服务框架所面临的三个本质问题；

第一代Service Mesh

我们从上图的边车模式示例中从全局视角来看：会得到下图

如果我们省略服务，只看Service Mesh的单机组件组成的网格：会得到下图

这就是所谓的Service Mesh，也就是服务网格了。它看起来确实就像是一个由若干服务代理所组成的错综复杂的网格

第二代Service Mesh

第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。

只看单机代理组件(数据面板)和控制面板的Service Mesh全局部署视图如下：

目前最受开发者欢迎的服务网格是Istio项目，该项目最初由谷歌、IBM和Lyft开发

Service Mesh优点

• 屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，服务只用关注业务逻辑；
• 真正的语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可；
• 对应用透明，Service Mesh组件可以单独升级；

Service Mesh缺点

• 需要的专业知识: 在容器编排器(如Kubernetes)之上添加Istio之类的服务网格通常需要运维人员成为这两种技术的专家。

• Service Mesh组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销；

• Service Mesh组件接管了网络流量，因此服务的整体稳定性依赖于Service Mesh，同时额外引入的大量Service Mesh服务实例的运维和管理也是一个挑战；

当然，优缺点还有很多，这里只是个别列举

总结

历史总是惊人的相似。

在网络通信层面上

Service Mesh 是微服务时代的 TCP/IP 协议。连接不同的微服务！

在管理层面上

spring 将 对象逐一管理，Servide Mesh将微服务逐一管理！

如有描述错的地方，欢迎指正