浅谈对service mesh 的一点点理解

原来使用的istio对应的版本为0.8,还只是在kubernetes没有落地的环境下使用,可以解决现在微服务框架下的服务注册与发现、身份验证与授权,熔断(过载保护),降级,流量控制等功能。

有人说“有了ISTIO,你的服务就不再需要任务微服务开发框架(springcloud ,dubbo的框架对服务治理,需要自己手动写程序处理)了!”

现在已发布了istio v1.0版本,并且官方说可以直接使用于生产环境,又基于我使用的是kubernetes环境,并且一直以为它是对kubernetes支持*好的,真是欣喜甚慰!

istio = 微服务框架 + 服务治理

istio的关键特性:

  • HTTP/1.1,HTTP/2,gRPC和TCP流量的自动区域感知和故障切换;
  • 路由规则丰富,容错和故障注入,对流行为提供细粒度控制;
  • 支持访问控制,速率限制和配额的可插拔和配置API;
  • 集群内所有流量的自动量度,日志和跟踪,包括 集群INGRESS和ENGRESS;
  • 安全的服务到服务身份验证;

没有service mesh前,微服务对运维带来了什么?

解耦的各个服务,可能多达几十上百个,怎么管理各个服务之间的连接,部署,版本控制,安全,故障转移,微略执行,遥测和和监控等,更不说常见的A/B测试。金丝雀发布 ,限流,访问控制,端对端认证。

痛点:

“找个Spring Cloud或者Dubbo的成熟框架,直接搞定服务注册,服务发现,负载均衡,熔断等基础功能。然后自己开发服务路由等高级功能, 接入Zipkin等Apm做全链路监控,自己做加密、认证、授权。 想办法搞定灰度方案,用Redis等实现限速、配额。 诸如此类,一大堆的事情, 都需要自己做,无论是找开源项目还是自己操刀,*后整出一个带有一大堆功能的应用程序,上线部署。然后给个配置说明到运维,告诉他说如何需要灰度,要如何如何, 如果要限速,配置哪里哪里。”—转载自数人云

service mesh是基础设施层,轻量级高性能网络代理,对应用透明。

 

%title插图%num

然,Istio也可以视为是一种服务网格。

  • 数据面板由一组智能代理(Envoy)组成,代理部署为边车(sidecar),调解和控制微服务之间所有的网络通信。
  • 控制面板负责管理和配置代理来路由流量,以及在运行时执行策略。

istio的架构图如下:

 

%title插图%num

它让开发专注于业务逻辑的处理和实现!

关于对envoy,pilot,mixer,auth的各个模块的介绍,可去数人云了解。

有了微服务和云原生,为什么还要懂Service Mesh?

Service Mesh技术作为新一代微服务架构,有效的解决了当前微服务架构和治理过程中的痛点问题,一经推出便引起很大的反响,近两年持续成为架构领域的热点。特别是Google联合Lyft等公司推出的Istio,架构优雅,功能强大,迅速成为Service Mesh领域的明星项目。

什么是Service Mesh
作为Service Mesh技术探索和实践的先行者,全球*个真正的Service Mesh项目Linkerd负责人、Buoyant公司创始人兼CEO William Morgan*次完整地阐述了Service Mesh。按照William Morgan的定义,Service Mesh是一个致力于解决服务间通信的基础设施层,其负责在现代云原生应用的复杂服务拓扑下实现请求的可靠传递,在实践中Service Mesh通常实现为一组轻量级网络代理,这些代理与应用程序部署在一起,并且对应用程序透明。

从上述Service Mesh的定义看,基础设施层是Service Mesh的定位,致力于解决本书第1章提出的微服务基础设施标准化、配置化、服务化和产品化问题;服务间通信是Service Mesh技术面对的问题域,对微服务屏蔽通信的复杂度,解决微服务的通信治理问题;请求的可靠传递是Service Mesh的目标;轻量级网络代理是Service Mesh的部署方式;对应用程序透明是Service Mesh的亮点和特色,Service Mesh接入对业务无侵入,可以非常方便地获取Service Mesh带来的便捷性,算是Service Mesh的一大优势。

综合来看,Service Mesh主要解决用户如下3个维度的痛点需求。

完善的微服务基础设施
Service Mesh通过将微服务通信下沉到基础设施层,屏蔽了微服务处理各种通信问题的复杂度,可以看成是微服务之间的抽象协议层,抽象层面可以看成是TCP/IP协议栈的一部分。对于微服务的开发者来说,比如当前使用HTTP或者Thrift进行RPC通信时,你不需要关注TCP/IP这一层的具体实现;有了Service Mesh之后,微服务也不再需要关注RPC通信(包含服务发现、负载均衡、流量调度、限流降级、监控统计等)的一切细节,真正像本地调用一样使用微服务,通信相关的一切工作直接交给Service Mesh。

因此,对于一些需要通过微服务改造提升业务敏捷性,但没有相应技术能力的中小团队来说,可以借助Service Mesh提供的完善微服务基础设施,加速微服务的落地。

语言无关的通信和链路治理
功能上,Service Mesh并没有提供任何新的特性和能力,Service Mesh提供的所有通信和服务治理能力在Service Mesh之前的技术中均能找到,比如Spring Cloud就实现完善的微服务RPC通信和服务治理支持。Service Mesh改变的是通信和服务治理能力提供的方式,通过将这些能力实现从各语言业务实现中解耦,下沉到基础设施层面,以一种更加通用和标准化的方式提供,屏蔽不同语言、不同平台的差异性,这样不仅有利于通信和服务治理能力的迭代和创新,业务使用的时候也会更加方便。

Service Mesh避免了多语言服务治理上的重复建设,通过Service Mesh语言无关的通信和服务治理能力,助力多语言技术栈的效率提升。

通信和服务治理的标准化
微服务治理层面,Service Mesh是标准化、体系化、无侵入的分布式服务治理平台。
标准化方面,Sidecar成为所有微服务流量通信的约束标准,同时Service Mesh的数据平面和控制平面也通过标准协议进行交互。
体系化方面,从全局考虑,提供多维度立体的微服务可观测能力(Metric、Trace、Logging),并且提供体系化的服务治理能力,比如限流、熔断、安全、灰度等;*为重要的是,Service Mesh通过透明无侵入的方式提供全面的服务治理能力,对微服务本身不会带来直接影响。
通过标准化,带来一致的服务治理体验,减少多业务之间由于服务治理标准不一致带来的沟通和转换成本,提升全局服务治理的效率。

Service Mesh的基本模式
根据Service Mesh的发展历程和使用方式,我们可以把Service Mesh划分为两个模式。

Sidecar模式
在Service Mesh发展早期,Service Mesh以Sidecar的形态存在。Sidecar模式下,网络代理服务在微服务旁边,为微服务提供通信和链路治理功能。因此,数据平面代理服务也经常被简称为Sidecar。

此时,只有数据平面的网络代理服务没有控制平面,和外部基础设施服务的交互直接在网络代理服务中进行。

Sidecar模式可以看作是*代Service Mesh,代表有早期的Linkerd和Envoy。

*代Service Mesh通过采用Sidecar模式,通过将通信和通信链路治理功能从微服务中剥离出来,实现了通信基础设施的下沉和服务化,这里也体现了架构解耦的思想,通过解耦减少了微服务的负担。

第二代Service Mesh模式
Sidecar模式的Service Mesh有一个突出的问题,将通信和通信链路治理的所有功能都放到这个代理服务中,导致数据平面代理很重,并且由于承载了太多的特性和功能,使得数据平面代理的更新和修改特别频繁,频繁的更新和升级会导致代理服务出问题的概率增大,影响代理服务的稳定性。同时,Service Mesh模式下,数据平面代理承载了微服务通信的全部流量,对稳定性要求*高,这个服务的任何故障都会对整个系统的稳定性产生很大的影响。为了解决上述频繁升级和稳定性之间的矛盾,将策略和配置决策逻辑从代理服务中脱离出来,形成了独立的控制平面,这就是第二代Service Mesh。

第二代Service Mesh*重要的标志就是控制平面和数据平面分离。数据平面和控制平面并不是新的概念,路由器/交换机等数据通信产品架构上,就有运行于专门处理器上的控制平面和多个独立运行、用于路由或交换功能的数据平面。SDN(Software Defined Network,软件定义网络)将数据平面和控制平面分离,控制平面具有可编程性,使得网络更加智能、灵活和易扩展,激发了网络技术的又一次革命。

第二代Service Mesh借鉴了SDN的思路,基于控制平面和数据平面分离思想,有了完善的控制平面:①所有的代理服务都由控制平面掌控,因为控制平面可以控制整个系统,所以提供了强大的控制能力和策略能力;②将具体的控制逻辑从数据平面移除,简化了数据平面的设计,数据平面不需要和外部系统进行交互,数据平面完全聚焦在变更频率很低的流量路由和转发逻辑上,提升了数据平面的稳定性。

Service Mesh架构
第二代Service Mesh的基本架构上分为数据平面和控制平面两个部分,大致如下图所示。
%title插图%num

数据平面
数据平面负责代理微服务之间的通信,具体包含RPC通信、服务发现、负载均衡、降级熔断、限流容错等,数据平面可以认为是将Spring Cloud、Dubbo等语言相关的微服务框架中通信和服务治理能力独立出来的一个语言无关的进程,并且更注重通用性和扩展性。在Service Mesh中,不再将数据平面代理视为一个个孤立的组件,而是将这些代理连接在一起形成一个全局的分布式网络。

控制平面
控制平面负责对数据平面进行管理,定义服务发现、路由、流量控制、遥测统计等策略,这些策略可以是全局的,也可以通过配置某个数据平面节点单独指定。控制平面通过一定的机制将策略下发到各个数据平面节点,数据平面节点在通信时会使用这些策略。
————————————————

原文链接:https://blog.csdn.net/xingduan5153/article/details/103085259