【博客336】简述：service mesh(服务网格)

内容： 记录service mesh的概念

先提微服务：

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块
 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能
 区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

service mesh基本概念：

1、Service Mesh是一组轻量级的服务代理和应用逻辑的服务在一起，并且对于应用服务是透明的。
Service Mesh是一种新型的用于处理服务与服务之间通信的技术，尤其适用以云原生应用形式部署
的服务，能够保证服务与服务之间调用的可靠性。在实际部署时，Service Mesh通常以轻量级的网
络代理的方式跟应用的代码部署在一起，从而以应用无感知的方式实现服务治理。用于保证服务与服务
之间调用的可靠性

这与传统的微服务架构有着本质的区别，这么做主要是出于以下原因：

* 跨语言服务调用的需要。在大多数公司内通常都存在多个业务团队，每个团队业务所采用的开发
语言一般都不相同，以微博的业务为例，移动服务端的业务主要采用的是PHP语言开发，API平台的
业务主要采用的是Java语言开发，移动服务端调用API平台使用的是HTTP请求，如果要进行服务化，
改成RPC调用，就需要一种既支持PHP语言又支持支持Java语言的的服务化框架。

* 云原生应用服务治理的需要。在微服务越来越多开始容器化，并使用Kubernetes类似的容器
平台对服务进行管理，逐步朝云原生应用的方向进化。而传统的服务治理要求在业务代码里集成
服务框架的SDK，这显然与云原生应用的理念相悖，因此迫切需要一种对业务代码无侵入的适合
云原生应用的服务治理方式。

2、服务网格(Service Mesh)是指用于微服务应用的可配置基础架构层。它使每个service实例
之间的通信更加流畅、可靠和迅速。

3、服务网格提供了诸如服务发现、负载均衡、加密、身份鉴定、授权、支持熔断器模式以及其它
一系列功能。

4、服务网格的实现通常是提供一个代理实例，我们称之为"sidecar"。sidecar 包含在每一个
service 之中。sidecar 主要处理 service 间的通信、监控、以及一些安全相关的考量通过
这种方式，开发者可以在服务中专注于开发、支持以及维护；运维人员可以维护服务网格并运行app。

其中：Istio( 由Google、IBM、Lyft公司在背后进行支持 ) 是目前最广为人知的一款服务网格
架构。Kubernetes( 由Google最早进行设计并开源 ) 是目前 Istio 唯一支持的容器组织框架。

简述：service mesh就是微服务时代的TCP协议。

service mesh概念图：

第一代service mesh产品：Linkerd

Buoyant公司开发的第一代Service Mesh产品Linkerd应运而生。比如：服务A要调用服务B，
经过Linkerd来代理转发，服务A和服务B的业务代码不需要关心服务框架功能的实现。为此
Linkerd需要具备负载均衡、熔断、超时重试、监控统计以及服务路由等功能。这样的话，
对于跨语言服务调用来说，即使服务消费者和服务提供者采用的语言不同，也不需要集成各自
语言的SDK。

而对于云原生应用来说，可以在每个服务部署的实例上，都同等的部署一个Linkerd实例。比如：
服务A要想调用服务B，首先调用本地的Linkerd实例，经过本地的Linked实例转发给服务B所在节点
上的Linkerd实例，最后再由服务B本地的Linkerd实例把请求转发给服务B。

这样的话，所有的服务调用都得经过Linkerd进行代理转发，所有的Linkerd组合起来就像一个
网格一样，这也是为什么我们把这项技术称为Service Mesh，也就是“服务网格”的原因。

service mesh的出现背景及发展过程：

时代1：原始通信时代

通信需要底层能够传输字节码和电子信号的物理层来完成，在TCP协议出现之前，服务需要自己处理
网络通信所面临的丢包、乱序、重试等一系列流控问题，因此服务实现中，除了业务逻辑外，还夹杂
着对网络传输等各种问题的处理逻辑。使得在处理业务的同时还要花费非常大的精力来处理其它业务
无关的基本问题

缺点：无法专一的开发业务；且基本传输框架一旦需要修改，则全部需要重构

时代2：计算机网络协议时代

为了避免每个服务都需要自己实现一套相似的网络传输处理逻辑，各种计算机网络协议出现了，
它们解决了网络传输中通用的流量控制问题，将技术栈下移，从服务的实现中抽离出来，成为
操作系统网络层的一部分。

时代3：第一代微服务

有了各式各样的计算机网络协议后，机器之间的网络通信不再是一个难题，分布式系统得以蓬勃发展。
这时，分布式系统特有的通信语义又出现了，如熔断策略、负载均衡、服务发现、认证和授权、quota
限制、trace和监控等等，于是服务根据业务需求来实现一部分所需的通信语义。

时代4：第二代微服务

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

时代5：第一代Service Mesh

第二代微服务模式看似完美，但开发人员很快又发现，它也存在一些本质问题：

1、虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和
管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事；

2、开发框架通常只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的
特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地
制宜的用多种语言实现架构体系中的不同模块也很难做到；

3、框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库
的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级；

因此以Linkerd，Envoy，Ngixmesh为代表的代理模式（边车模式）应运而生，这就是第一代
Service Mesh，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、
认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，
和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样
上边所说的三个问题也迎刃而解。

全局视角：

绿色：service
蓝色：sidecar
小网格：pod
整体：service mesh(服务网格)

时代6：第二代Service Mesh

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

全局视角：

service mesh的实现：

service mesh大部分采用了sidecar模式：在你的pod中部署了sidecar容器，使得你的业务
container不再需要处理类似服务发现，负载均衡等基础分布式措施；更加专注于业务。

再来说说sidecar：

抽象：

实际：

sidecar的功能：

（1）服务发现(discovery)

（2）负载均衡(load balancing)

（3）故障恢复(failure recovery)

（4）服务度量(metrics)

（5）服务监控(monitoring)

（6）A/B测试(A/B testing)

（7）灰度发布(canary rollouts)

（8）限流限速(rate limiting)

（9）访问控制(access control)

（10）身份认证(end-to-end authentication)

sidecar：
1、通过抽象出与功能相关的共同基础设施至一个不同层降低了微服务代码的复杂度
2、分离了应用程序代码和底层平台的耦合
3、在微服务开发中,将这些功能相同的组件抽象出来,能够降低微服务架构中代码的重复度

sidecar control作用：
1、服务发现：服务提供者会通过SideCar注册到Control Plane的注册中心，这样的话服务消费者
把请求发送给SideCar后，SideCar就会查询Control Plane的注册中心来获取服务提供者节点
列表。

2、负载均衡。SideCar从Control Plane获取到服务提供者节点列表信息后，就需要按照一定的
负载均衡算法从可用的节点列表中选取一个节点发起调用，可以通过Control Plane动态修改
SideCar中的负载均衡配置。

3、请求路由。SideCar从Control Plane获取的服务提供者节点列表，也可以通过
Control Plane来动态改变，比如需要进行A/B测试、灰度发布或者流量切换时，就可以动态
地改变请求路由。

4、故障处理。服务之间的调用如果出现故障，就需要加以控制，通常的手段有超时重试、熔断等，
这些都可以在SideCar转发请求时，通过Control Plane动态配置。

5、安全认证。可以通过Control Plane控制一个服务可以被谁访问，以及访问哪些信息。

6、监控上报。所有SideCar转发的请求信息，都会发送到Control Plane，再由
Control Plane发送给监控系统，比如Prometheus等。

7、日志记录。所有SideCar转发的日志信息，也会发送到Control Plane，再由
Control Plane发送给日志系统，比如Stackdriver等。

8、配额控制。可以在Control Plane里给服务的每个调用方配置最大调用次数，在SideCar
转发请求给某个服务时，会审计调用是否超出服务对应的次数限制。

整体如下：

展望：service mesh的优点与面临的挑战：

* Service Mesh优点：

1、屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，
服务只用关注业务逻辑；

2、真正的语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可；

3、对应用透明，Service Mesh组件可以单独升级；


* Service Mesh面临的挑战：

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

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