服务网格简介

发展历史

原始通讯时代

然而现实远比想象的复杂，在实际情况中，通信需要底层能够传输字节码和电子信号的物理层来完成，在TCP协议出现之前，服务需要自己处理网络通信所面临的丢包、乱序、重试等一系列流控问题，因此服务实现中，除了业务逻辑外，还夹杂着对网络传输问题的处理逻辑。

tcp时代

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

第一代微服务

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

第二代微服务

为了避免每个微服务框架都需要实现一套分布式系统通信的语义给你,随着技术发展,一些面向微服务的开发架构出现了,如Twitter的Finagle,Facebook的proxygen以及SpringCloud等,这些框架时效内了分布式系统通信需要各种通用的语义功能:如负载均衡和服务器发现等,因此一定程度上屏蔽了通信细节,使得开发人员使用较少的空间代码就能开发出健壮的分布式系统

缺点

• springcloud中加cloud依赖,写cloud注解,写配置,打jar包的时候还必须要吧非业务代码也融合在一起,称为侵入式框架
• 微服务中的服务支持不同语言开发,也需要维护不同语言和非业务代码的成本
• 业务代码开发者一个把更多精力投入到业务上,而不是其他,springcloud虽然能解决很多微服务领域的问题,但是学习成本你比较大
• 互联网公司产品升级非常频繁,维护了各个版本的兼容性,权限流量等,业务springcloud是代码入侵式框架,这时候版本的升级注定要让非业务代码在一起,一旦出现问题,加上多语言之间的调用,工程师会非常痛苦

第一代service mesh

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

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

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

从全局去看就会得到如下部署图

它看起来确实就像是一个由若干服务代理所组成的错综复杂的网格

第二代service mesh

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

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

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

服务网格是一个基础设施层,用于处理服务间通信.云原生应用有着复杂的服务拓扑,服务网格保证请求在这些拓扑中可靠的穿梭,在实际应用中,服务网格通常是由一系轻量级的网络代理组成的,它们与应用程序部署在一起,但对应用程序透明

四个关键词

基础设施+请求在这些拓扑中可靠的穿梭,这俩个次加起来描述了Service Mesh的定位和功能

网络代理:描述了service mesh的实现形态

对应用透明:描述了service mesh的关键特点,正是由于这个特点,Service mesh能够解决一Spring Cloud为代表的的第二代微服务框架面临的三个本质问题

优点

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

缺点

• service mesh组件代理模式计算并转发请求,一定程度上会降低通信系统的性能,并增加系统资源开销
• service mesh组件接管了网络流量,因此服务的整体稳定性依赖于service mesh ,同时额外引入大量的service mesh服务实例的运维管理也是一个挑战

历史总是惊人的相似。为了解决端到端的字节码通信问题，TCP协议诞生，让多机通信变得简单可靠；微服务时代，Service Mesh应运而生，屏蔽了分布式系统的诸多复杂性，让开发者可以回归业务，聚焦真正的价值。

组件

SideCar

它降低了与微服务架构相关的复杂性,并且提供了负载均衡,服务发现,流量管理,电路中断,遥测,故障注入等功能特性

Sidercar 模式是一种讲应用功能从应用本身玻璃出来作为单独进程的方式.该模式允许我们向应用无侵入添加多种功能,避免了为满足第三方组件需求而向应用添加额外配置代码

总结:sidecar是一个代理,管理服务的进出口流量,对流量有一定的治理功能

sidecar的探索之路,

• 2014年netflix发布了prana
• 2015年唯品会发布了local proxy
• 2016年推特发布了第一款service mesh 项目 linkerd

linkerd

linkerd结合了kubernetes提供的所有功能,以此为基础在每个k8s node上都部署运行一个linkerd实例,用代理方式假如mesh的pod通信转借给linkerd,这样linkerd就能在通信链路中完成对通信的监控

• 无需侵入业务代码就能管理服务流量
• 兼容k8s提供的所有功能
• 由scala语言编写
• 屏蔽通信细节

linkerd通过在每个服务实例旁边安装一组超轻,透明的代理来工作.这些代码会自动处理进出服务的所有流量.由于它们是透明的,这些代理充当highy instrumented的进程外网络堆栈,向控制泡面发送遥测数据并从控制平面接受控制信号.这种设计允许linkerd 侧脸和操纵服务进出的流量,而不会引入过多的延迟

istio

由谷歌IBM和lyft共同发起的项目,由go语言编写

lstio提供一种简单的方式来建立已部署的服务网格,具备均衡负载,服务认真,监控等等功能,而不需要改动任何代码,简单说有了lstio你的服务就不需要任何微服务开发框架,也不需要自己手动实现复杂的服务治理功能(很多是spring cloud,dubbo也不能提供的,需要自己动手).只需要服务的客户端和服务端进行简单的直接网络访问,就可以通过将网络层委托lstio,从而获得一系列完备功能.可以近似理解为lstio=微服务框架+服务治理

istio既有数据平面也有控制平面(linkerd只有数据平面)

流量控制：控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。

可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。

策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。

服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。

除此之外，Istio针对可扩展性进行了设计，以满足不同的部署需要：

平台支持：Istio旨在在各种环境中运行，包括跨云， 预置，Kubernetes，Mesos等。最初专注于Kubernetes，但很快将支持其他环境。

集成和定制：策略执行组件可以扩展和定制，以便与现有的ACL，日志，监控，配额，审核等解决方案集成。

服务网格简介

服务网格指的是微服务网络原因之间的交互,随着规模和复杂性的增加,服务跟服务调用错综复杂

特点

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

service mesh

Service Mesh又译作“服务网格”，作为服务间通信的基础设施层。Willian Morgan（Linkerd的CEO）如下定义Service Mesh。

Service Mesh 是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，Service Mesh 保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中，Service Mesh 通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。

Service Mesh 实际上就是处于 TCP/IP 之上的一个抽象层，它假设底层的 L3/L4 网络能够点对点地传输字节（当然，它也假设网络环境是不可靠的，所以 Service Mesh 必须具备处理网络故障的能力）。

CNCF云原生

istio是开源的服务管理,保护和监控框架,istio为希腊语,意思是起航

CNCF是一个开源软件基金会,致力于云与安生计算具有普遍性和可持续性,云原生计算使用开源软件技术栈将应用程序部署为服务,将每个部分打包到自己的容器中,并动态编排以优化资源利用率.云原生技术使软件开发人员能够更快速地构建出色的产品

解决问题

• 统一寄出平台
• 日志监控:prometheus
• 需要代理Envoy
• 需要分布式链路跟踪

国内的服务网格

在service mesh这个概念得到具体定义之间,很多厂商就开始了微服务的新尝试,这一动作必引发对微服务治理的强力需求.在service mesh概念普及后,厂商也意识到自己茶农具备service mesh特点,将自有的服务治理平台进行完善和改造,退出自己的service mesh产品

蚂蚁金服sofa mesh

前身是SOFA RPC,go语言编写,使用了自研的代理mosn支持更加丰富的协议,在2018年开源

还有腾讯云的service mesh,Tencent Service mesh

华为云的CSE mesher