app aws_服务网格:Istio和AWS App Mesh

古弘
2023-12-01

app aws

本周在AWS re:Invent上的重大公告之一AWS App Mesh

在谈论它之前,让我们先看一下网格到底是什么……

什么是服务网格?

服务网格是微服务体系结构的基础结构层。 它处理服务之间的通信问题,使该通信更加可见(或“可观察”)且易于管理。 更具体地说,它可以处理诸如服务发现,路由和负载平衡,安全性(例如,加密,TLS,身份验证,授权)之类的事情,并提供错误处理(例如重试和断路)。

控制计划与数据平面

上面提到的功能(服务发现,路由,加密,身份验证/身份验证等)是将数据(网络数据包)执行进出微服务的操作。 结果,它们有时被称为“数据平面”。

我们如何控制对数据的操作称为“控制平面”。 控制平面是用于控制流量的策略和配置。

数据平面通常实现为与每个微服务一起运行的“边车”代理。 最受欢迎的是Envoy代理 (由Lyft的人们创建),而这确实是AWS App Mesh所使用的。 过去,主要控制平面是Istio ,但现在AWS App Mesh也已移入该空间。

数据平面和控制平面一起称为服务网格。

(我想您可能会争论AWS App Mesh是将Envoy用作其数据平面的控制平面,还是App Mesh只是具有相应数据和控制计划的Service Mesh。后者–认为App Mesh仅仅是一个Service Mesh –对我来说似乎更有意义)。

为什么我们需要服务网格?

尽管该术语是新术语,但数据平面的概念却并非如此。 路由,加密等是分布式计算必不可少的。 但是,控制平面的概念新概念,或者至少该概念以前从未真正地正式化或命名过。 马特·克莱因(Matt Klein)(Envoy的架构师) 认为 ,通常通常使用即席配置和脚本工​​具手动完成此操作。 但是确实存在需求。 严重缺乏更容易控制和观察流量的功能。 我当然已经看到微服务的间歇性问题,您很难解释,开发人员耸了耸肩,问“网络问题?”。

使用边车在服务网格中处理这些类型的问题的优点是,它使应用程序(和相关的开发团队)免于必须在每个应用程序中处理这些问题的麻烦。 过去,通常会在每个应用程序中使用通用代码(例如库)来解决此类问题,但缺点是需要特定于语言以及必须与应用程序发行版捆绑在一起。

AWS App网格

新的AWS App网格(当前可作为公共预览使用)旨在使其“易于监视和控制在AWS上运行的微服务”。 App Mesh可以与在EC2上运行的ECSEKSKubernetes一起使用,并且可以与现有的AWS服务(例如CloudWatchX-Ray)结合使用

除了提供流量可观察性之外,App Mesh还旨在帮助进行部署,允许您通过使用虚拟路由器来配置流量路由,并允许使用蓝色/绿色金丝雀部署来推出新的服务版本。

App Mesh没有额外的价格,仅是您与ECS / EKS / EC2等一起使用的计算资源的价格。

那Istio呢?

一段时间以来,Istio一直是服务网格的主要选择,而且AWS App Mesh和Istio之间肯定有很多相似之处。 两者都是服务网格。 两者都包装Envoy作为数据平面。 两者的目的都是为了解决相似的需求,以允许您监视和控制微服务之间的流量。

但是,Istio是开源的,与供应商无关,并且已经存在了很长时间,因此更加成熟。 例如,Istio 安全功能包括通过支持mTLS进行传输(服务到服务)身份验证,以及通过JWT并与Auth0Firebase AuthGoogle Auth集成,进行原始(最终用户)身份验证 。 它还不仅支持使用AWS IAM的服务身份,还支持Kubernetes和GKE / GCE / GCP的服务身份。

AWS App Mesh确实提供了与IAM策略,角色和权限的集成,但是我无法在文档中找到有关身份验证支持的其他信息。 也许我只是想念它。 请注意,Istio通过Envoy提供了其Mutual TLS身份验证,因此大概(?)App Mesh将能够做到这一点。

因此,App Mesh似乎缺少Istio的某些功能。 但是,考虑到AWS是房间中的800磅大猩猩,不仅拥有大量的工程资源,而且在工程界也得到了广泛的普及,因此它似乎有可能成为一种主导工具。 它会取代Istio吗? 观看会很有趣……

参考资料和进一步阅读

翻译自: https://www.javacodegeeks.com/2018/12/service-mesh-istio-aws-app-mesh.html

app aws

 类似资料: