服务网格下的东西向与南北向流量管理实践|学习笔记(一)

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 快速学习服务网格下的东西向与南北向流量管理实践

开发者学堂课程【服务网格技术最佳实践服务网格下的东西向与南北向流量管理实践】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/752/detail/13223


服务网格下的东西向与南北向流量管理实践

 

内容介绍:

一、为什么使用服务网格技术

二、什么是阿里云服务网格 ASM

三、托管的服务网格 ASM 产品架构

四、托管模式下的优势

五、东西向与南北向流量管理


一、为什么使用服务网格技术

1、本课的主题是在托管式服务网格 ASM 中,如何通过定义声明式的规则来管理服务之间的东西向和南北向流量。首先要了解使用服务网格技术的原因。在服务网格技术使用之前,常常会把一个单体的应用程序,分拆为分布式的微服务架购。在这个过程当中,通常以代码或 ladery 的方式,把服务具体的能力构建在应用程序的软件中。在这些代码库中,通常会兼有流量管理,从事客户端、负载均衡、安全以及可观测性这些能力。这些代码库随着功能的不断增强,版本也会随之变换。随着代码库的版本变换,尽管应用程序本身逻辑没有任何变更,应用也会随着版本库的变更而不断更新。由此可见随着应用规模的增长,服务数量的不断增加,针对服务实现服务治理能力依赖于代码库的方式会变得非常复杂。通过把服务治理的能力进行统一化、求强化,变成一个独立应用服务逻辑组件的 Sidecar,就能很好把服务治理的能力与应用程序本身进行解耦,可以更好地支持多种编程语言。同时这些 Sidecar 能力也不需要依赖于某种特定技术框架。

2、在下面这幅图中

image.png

可以很清晰的看到业务运用所使用的逻辑组件,与服务治理能力网格的代理实现的解耦。随着 slidcar 代理功能的不断增强,原本需要在代码库中实现服务治理能力会被主件抽象话,成一个一个通用的组件,组件也可以不断沉淀到基础设施层中。通过对这些服务治理能力的标准化和统一化,可以解决复杂系统中微服务实现面临的多能编程语言,可以很好的支持支持不同编程框架,不同编程语言实现的分布式系统。通过把应用服务、通信能力、服务管理能力进行抽象下沉到基础设施之后,可以帮助开发人员可以更加聚焦与业务应用本身,而不需要过多关注服务治理组件的这些管理。因为这些服务治理的能力,可以通过基础设施统一进行提供。这些 sildcar 里会形成一个网状的数据平面,通过这个数据平面可以有效的处理和观测在这个网格中服务之间的流量调用情况,数据里面扮演着一个保护和通过控制网格的这些应用流量和管理的决策。如何对 sildcar 代理进行统一管理?这就是服务网格中定义的控制平面要解决的问题。负责数据平面如何进行执行的管理组建,称之为控制平面。控制平面是整个服务网格的大脑,它能够起到一个统一关联的决策,能够为网格的使用、副网格的行为人员提供更好地统一的 iti ,从而更加容易去操纵网格的一些行为。其余的服务网格技术之后,可以看到开发人员、应用人员和 SRE 团队都可以用统一的声明式的方式来定义服务之间的路由规则,来统一定义服务之间的安全任用规则,来统一定义声明式发声的可观测性能力,从而可以很好的去解决应用服务这些管理的问题,而且管理的手段也变得更加统一,而且使用声明式的方式解决。

 

二、什么是阿里云服务网格 ASM

1、阿里云服务网格 ASM 全称是 Alibaba cloud service mesh,这是服务网格的一个平台,在阿里云上面提供一个全托管式的平台。在 ASM 产品中,整个服务网格的控制平台组件是被托管,是运行与阿里云的对策。通过这种托管模式希望能够帮助开发人员降低使用产品门槛,降低使用的复杂度,使用户可以更加专注于业务应用开发过程本身。与此同时 ASM 产品本身保持社区 Istio 的兼容能力,可以用支持应用声明式的方式来统一定义这些路由规则。一个 ASM 实例可以支持来自多个 Kubernetes 集群应用服务,也可以去管理来自 service Kubernetes 包括一些 pod上的应用服务。此外,也可以把一些非 Kubernetes 的服务,包括运行的虚拟机,运行的物理机上的应用服务,这些非容器化的应用服务,可以集群到同一个 ASM 服务网格中。通过 ASM 实例可以很好的减化服务的治理能力,包括服务调用之间的流量路由和流量拆分的一些能力,同时也可以更好的管理服务之间通讯的任由安全能力,可以更好地定义、实现服务之间的可观测性能力。ASM 产品的目标尽可能减轻开发人员与运维人员的工作负担,提升应用服务管理的能力。

2、阿里云服务网格( Alibaba Cloud Service Mesh,简称 ASM )提供了

· 一个全托管式的服务网格平台

·兼容于社区 Istio 开源服务网格

· 用于简化服务的治理,包括:

· 服务调用之间的流量路由与拆分管理

· 服务间通信的认证安全

· 网格可观测性能力

· 目标:尽可能地减轻开发人员与运维人员的工作负担,提升应用服务管理的能力。

 

三、托管的服务网格 ASM 产品架构

1、服务网格 ASM 的架构,作为业内首个全托管服务网格产品 ASM,一开始就从架构上保持了业界的领先性,并且保持与 su 社区的兼容性。

image.png

整个控制平面的组件是托管在阿里云,是运行在阿里云的资源上,与数据面侧的集群相互独立。在托管控制面的一侧提供了支持精细化的流量管理,支持安全管理,也支持可观测性能力的一些组件。通过这种托管的模式可以很好的去解耦控制面的组件,与之所管理的 K8s 集群这些组件的声明逻辑管理,架构非常灵活,也提高了系统的可观测性。再相对于社区的 isito 实践方式,如果不是通过这种解耦方式,有些 Isito 的控制面对运行的依赖的 K8s 版本是有要求的,通过这种托管的模式之后,因为控制面已经在阿里云进行托管,它的升级都是由阿里云这一侧托管的支持,这样可以很好地支持数据面这一侧不同版本的 K8s 集群。深入分析服务网格方面的 ASM 也提供了服务网格诊断能力,可以帮助用户快速定位一些问题,可以分析定义的路由规则之间的冲突,及时找到问题的根本原因反馈给用户。

2、在扩展与集成方面ASM 产品整合了阿里云服务的很多能力,包括可观测性服务能力里面的链路追踪、日志服务、 prometheus 监控等等。在互联互通方面也是基于云企业网的支持,能够支持跨地域、跨 OBC 网络的能力。同时,也优化整合了社区开源的能力,包括 Open polish OT 在策略支持能力,支持 space spirit  安全的能力。此外,将 web service 技术也运用到了服务网格 ASM 中,用来解决在代理扩展方面的一些能力。这样 ASM 产品的架构可以用一句话来表达,是托管的、高科性的、弹性的控制平面,加上一个可扩展的插件式的数据平面这种模式。具体来说,在数据平面这一侧,ASM 产品也支持了多种不同的基础设施,这里面包括了阿里云提供的 ACK Kubernetes 集群,也支持几种不同的形式,包括托管的 K8s 集群,专有的 K8s 集群等等。另外也支持了对无服务器 Kubernetes 容器服务,ESK service K8s 这个集群,它里面支持 ECA pod 的支持能力,例如他也会对一些非容器化的应用,例如运行在应用在 ECA 上面的虚拟机,或者是物理多级上面的应用服务,进行支撑能力。此外,ASM 产品推出了一个支持多应用混合能力,能够针对外部分压力云的一些开发集群,不论集群是在用户实践的 IDC  机房,还是运行在其他的上面,都能通过注册能力把集群注册在阿里云上面,然后通过 ASM 进行统一的服务管理。

 

四、托管模式下的优势

1、在托管模式下到底有哪些优势呢?有很多用户在使用 ASM 产品的过程中,会经常咨询为什么要使用托管模式,它的价值到底是什么?总结了几个方面,首先在托管模式下,服务网格的控制平面实例是运行在阿里云这一侧,他的资源的消耗,运营运维都是由专业的支撑团队来做,托管侧的服务网格控制平面,一定保证他的高可用、免运维,对用户来说是免运维的。里面也包含了一些区别于社区的版本不同,比如说安全的杜假事件,很多地方并没有考虑过多的运行的云梯上,这些安全的点。在托管ASM产品里面,针对一些安全漏洞,针对一些最佳的安全实践,都是把他的托盘侧进行实现。在整个过程中,也不需要用户参与运维、托管的组建,开发人员只需要更加注重业务运用,本身的开发,而不是基础的设置运维,这是很大的一个优势。

2、第二个是增强数据平面能力,在 ASM 产品中是优化整合了阿里云很多中间件云产品,像刚才提到的可观测性能力、链路追踪、prometheus 监控、告警、日志等等这一系列产品,都是由相应的团队提供一系列的支持。同时在数据这一侧也是跟社区和其他团队也是提供了基于 WebAssembly 技术来实现统一代理可扩展能力。在ASM产品中,可以代理 Procee 进行标准的扩展,就是我们的用户、服务网格 ASM 的行为人员可以把扩展的 WebAssembly theatre 通过一些插件能力,通过 ASM 可以很容易地顾及到数据面集群中,进行使用,进行扩展。通过我们提供的一个自然地 ASM 一个 theatre 主要的组件,可以支持动态的加载的扩展插件,做的一个简单应用,同时也支持更新的一些能力。

3、第三个是在跨集群、跨区域的统一流量管理。一个网格实例可以管理来自不同环境下、不同地域的多个 K8s 集群,同时结合了阿里云的云企业网,可以轻松实现跨地域、跨 VPC 的、跨网络的这种混合云应用流量统一管理。

4、第四个是支持多种基础设施的应用,能够支持除了 K8s 集群上面的应用服务之外,也可以支持其他一些非容器化的一些运用,包括运行的处理机、运行的物理机上面的这些服务的流量管理,这种比较适合容器化上的云的平滑迁移场景。在 ASM 这个产品里面,实现了服务网格控制面的组件,与数据面 K8s 集群的组件,两者生命周期管理进行一个很好的解耦,从而可以支持各自版本的升级,版本升级的维护以及更多的版本兼容能力,这就是整个托管模式下 AMS 产品为用户提供的一些优势。

5、(1)托管的服务网格控制平面实例:

高可用、免运维、内建安全最佳实践;开发人员可以更专注于业务应用而非基础设施运维。

2)增强的数据平面能力:

优化整合阿里云中间件云产品,提供托管的链路追踪、监控、告警、日志等可观测能力。基于 WebAssembly 实现统一的代理可扩展能力。

3)跨集群跨区域的统一流量管理:

一个网格实例可管理不同环境下的多个集群,结合阿里云云企业网等,轻松实现跨地域混合云应用流量统一管理。

4)支持多种基础设施的应用:

支持容器应用和虚拟机应用间的流量管理,适合容器化上云的平滑迁移场景。

5)服务网格控制面组件与数据面K8s集群的生命周期管理解耦,以支持各自的升级维护、更多版本的兼容。


五、东西向与南北向流量管理

1、下面介绍东西向与南北向流量管理。大家可能对东西向与南北向流量在服务网络中的定义不是很了解,简单介绍一下。在服务网络中东西向流量管理在一个数据面,一个集群里,他是服务与服务之间的流量管理,在一个服务内的,在一个网格内的流量管理,这个时候才称为东西向。在一个网格内的流量管理称为东西向,与之相对应的就是南北向。南北向指将集群外部的客户端连接到集群内运行的服务,或者说从集群内的服务去访问集群外的服务,称之为南北向。

2、在下面这个图里可以看到

image.png

北向在图的左侧,左侧在服务网格边界里面提供了两个网关。一个 Ingress Gateway,提供了一个公共网络的,可以具备公有的 IP 地址,可以通过这个公有 IP 地址来访问这个网关;另外一个提供私有 IP 地址,可以通过私有的方式来访问 inter 网关,这是入口网关的一个定义。在这个图的右侧可以看到,在集群内的一个服务想访问集群外的,集群外的这样一个服务,这是指南向的。从集群内访问到集群外,可以通过 Egress 出库网络的方式来访问,也可以通过 Service entry 的另一个方式 sidecar 的方式来访问外部服务。处于服务网格边界的指的是南北向的,在网格内的称为东西向的流量管理。大家可以看到,在网格内部的这些服务之间,就是东西向的流量管理,他本身服务之间的调用是不需要 inter 网关的,而是通过他注入的 sidecar proxy 来执行这个服务,进行管理。这些服务之间的调用也是可以通过集群本地的服务名称进行相互访问,在没有启用服务网格技术的时候,K8s 直接的服务调用可以通过服务云的方式进行发现、进行路由、进行调用。在服务网格技术使用之后,这个方式并没有发生改变。在集群内部通过服务名的方式进行访问。

3、在南北向流量管理中有所不同,以入口网关来举例。在 istio 入口网关里面,可以看到他的调用电路是什么样的。他是跟 K8s egress 入口有所类似,又有所不同。在 istio 网关里面,他使用一个新的 CRD,就是 custom resource definition 一个新的资源类型,他里面用了一个类似于 BTV 的资源类型,像虚拟服务 Work service 主要类型来控制整个入口的流量。他们之间通过性能工作将流量路由到网络中。

相关文章
|
5月前
|
Cloud Native 容器 Kubernetes
基于阿里云服务网格流量泳道的全链路流量管理(三):无侵入式的宽松模式泳道
本文简要讨论了使用流量泳道来实现全链路流量灰度管理的场景与方案,并回顾了阿里云服务网格 ASM 提供的严格与宽松两种模式的流量泳道、以及这两种模式各自的优势与挑战。接下来介绍了一种基于 OpenTelemetry 社区提出的 baggage 透传能力实现的无侵入式的宽松模式泳道,这种类型的流量泳道同时具有对业务代码侵入性低、同时保持宽松模式的灵活特性的特点。同时,我们还介绍了新的基于权重的流量引流策略,这种策略可以基于统一的流量匹配规则,将匹配到的流量以设定好的比例分发到不同的流量泳道。
73528 16
基于阿里云服务网格流量泳道的全链路流量管理(三):无侵入式的宽松模式泳道
|
Kubernetes API 容器
基于阿里云服务网格流量泳道的全链路流量管理(二):宽松模式流量泳道
基于阿里云服务网格流量泳道的全链路流量管理(二):宽松模式流量泳道
10968 12
|
运维 负载均衡 监控
服务网格下的东西向与南北向流量管理实践|学习笔记
快速学习服务网格下的东西向与南北向流量管理实践
1405 0
服务网格下的东西向与南北向流量管理实践|学习笔记
|
Kubernetes Cloud Native 安全
基于阿里云服务网格流量泳道的全链路流量管理(一)严格模式流量泳道
灰度发布是一种常见的对新版本应用服务的发布手段,其特点在于能够将流量在服务的稳定版本和灰度版本之间时刻切换,以帮助我们用更加可靠的方式实现服务的升级。
29943 18
|
存储 Kubernetes 负载均衡
【服务网格】最佳实践在哪里-2:多集群流量管理
各位,多集群这个场景在服务网格这一块也算是越来越热了。早在1.4版本,istio社区就已经提出了多集群环境下istio的部署模型,提供统一的控制面管理多集群中服务的能力。而最近随着服务网格的配套可观测项目kiali推出v1.69版本,我们更是可以在一个kiali实例中就纵览多集群中的流量规则、流量拓扑与服务详情,多集群的使用体验逐渐完善,利用这个场景玩法的用户也是越来越多了。不过,任何新事物的引入
|
API 微服务 调度
基于网关服务治理的研究与实践(六)服务编排
本文是基于网关服务治理的研究与实践系列的第六篇文章,从以上几篇文章中,介绍了网关服务治理相关内容,包括微服务架构、服务治理相关概念、服务治理技术框架、API网关技术及自研网关,服务编排也是以上架构技术基础上的进一步深入的研究,也是服务治理领域非常值得研究的内容。
2568 7
基于网关服务治理的研究与实践(六)服务编排
|
弹性计算 Kubernetes 负载均衡
服务网格下的东西向与南北向流量管理实践|学习笔记(二)
快速学习服务网格下的东西向与南北向流量管理实践
服务网格下的东西向与南北向流量管理实践|学习笔记(二)
|
负载均衡 Kubernetes API
服务网格下的东西向与南北向流量管理实践|学习笔记(三)
快速学习服务网格下的东西向与南北向流量管理实践
服务网格下的东西向与南北向流量管理实践|学习笔记(三)
|
负载均衡 开发者 微服务
服务网格下的东西向与南北向流量管理实践(三)|学习笔记
快速学习服务网格下的东西向与南北向流量管理实践(三)
399 0
服务网格下的东西向与南北向流量管理实践(三)|学习笔记
|
弹性计算 开发框架 负载均衡
服务网格下的东西向与南北向流量管理实践(二)|学习笔记
快速学习服务网格下的东西向与南北向流量管理实践(二)
1136 0
服务网格下的东西向与南北向流量管理实践(二)|学习笔记
下一篇
无影云桌面