服务网格：Istio和AWS App Mesh

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

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

什么是服务网格？

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

控制计划与数据平面

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

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

数据平面通常实现为与每个微服务一起运行的“边车”代理。最受欢迎的是Envoy Proxy （由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上运行的ECS ， EKS和Kubernetes一起使用，并且可以与现有的AWS服务（例如CloudWatch和X-Ray）结合使用。

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

App Mesh没有额外的定价，仅针对您与ECS / EKS / EC2等一起使用的计算资源。

那Istio呢？

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

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

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

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