聊一聊ServiceMesh

前言

上周公司邀请了IBM的团队来对我们进行Istio相关的介绍，并现场指导我们进行了一次动手实操。说起Istio可以算是家喻户晓，是Service Mesh架构的代表产品，Service Mesh被一致认为是下一代的微服务架构，可以想象到是有多么火爆，我们本篇先讲Service Mesh，针对于Istio我们另起一篇在进行讲述。

什么是Service Mesh

什么是service mesh？直接翻译就是服务网格，这⾥我来谈谈我对Service Mesh的理解。我认为Service Mesh是⼀种新型的⽤于处理服务与服务之间通信的技术，尤其适⽤以云原⽣应⽤形式部署的服务，能够保证服务与服务之间调⽤的可靠性。在实际部署时，Service Mesh通常以轻量级的⽹络代理的⽅式跟应⽤的代码部署在⼀起，从⽽以应⽤⽆感知的⽅式实现服务治理。

Service Mesh的组成以及实现原理

组成之一—SideCar

SIdeCar，挎斗模式，大家多少会看一些抗日剧，小鬼子一般都会骑那种带挎斗的三轮摩托车。在此模式中，挎斗附加到父应用程序，为应用程序提供支持性功能。 此外，挎斗与父应用程序具有相同的生命周期：与父应用程序一起创建，一起停用。 挎斗模式有时也称为搭档模式，这是一种分解模式。
这种模式跟现有的微服务模式有较大区别，传统的微服务模式如下图所示：

可以看到传统的微服务模式中，服务消费者和提供者都要去实现一些业务逻辑之外的属于服务框架的功能，比如上图中的服务消费者端的负载均衡、熔断降级，服务提供者端的限流降级等内容。而在ServiceMesh架构中，服务消费者和服务提供者端都会有一个sidecar去实现属于服务框架的功能，而服务的消费者和服务的提供者仅仅需要做好业务逻辑，其大体流程描述如下：服务消费者发送请求给消费者端的sidecar，消费端的sidecar获取到请求后去注册中心查找服务提供者节点列表，拿到列表后，消费端sidecar会根据一定的负载均衡策略去选择其中一个服务提供者，选择完毕发送请求到相应服务提供者端的sidecar，服务提供者端的sidecar完成一些诸如流量统计、限流等功能后，将请求转发至服务进程，完成一次服务的请求。这个流程大体如下：

其实从上图中可以看出sidecar在消费端相当于一个正向的代理，而在消费端则相当于一个反向的代理。

组成之二–Control Plane

既然SideCar能实现服务之间的调用拦截功能，那么服务之间的所有流量都可以通过SideCar来转发，这样的话所有的SideCar就组成了一个服务网格，再通过一个统一的地方与各个SideCar交互，就能控制网格中流量的运转了，这个在Sevice Mesh中就被称为Control Plane。在service mesh中，一般Control Plane具有以下功能
1，服务注册发现。在Control Plane中有一个注册中心，服务提供者会往注册中心注册服务，服务消费者的sidercar在接收到请求后会到Control Plane中的注册中心查找服务列表。
2，负载均衡。可以在Control Plane中配置相应的负载均衡策略，服务消费端的sidecar拿到服务节点列表后会按照这个策略进行选择节点。
3，请求路由。比如实现AB测试或者灰度发布，可动态配置
4，故障处理。比如服务的降级和熔断，可动态配置
5，安全认证。主要是权限的控制，比如谁可以访问谁不可以访问。
6，监控上报。所有SideCar转发的请求信息，都会发送到Control Plane，再由Control Plane发送给监控系统，⽐如Prometheus等。
7，日志管理。所有SideCar转发的⽇志信息，也会发送到Control Plane，再由Control Plane发送给⽇志系统，⽐如Stackdriver等。
8，配额管理。。可以在Control Plane⾥给服务的每个调⽤⽅配置最⼤调⽤次数，在SideCar转发请求给某个服务时，会审计调⽤是否超出服务对应的次数限制。