向微服务的转变面临着一系列挑战。如果认为微服务的架构，设计和开发很复杂，那么部署和管理它们也同样复杂。
开发人员需要确保跨服务的通信是安全的。他们还需要实施分布式跟踪，以告知每次调用需要多长时间。重试，断路器等分布式服务的一些最佳实践为服务带来了弹性。微服务通常是多语言的，并使用不同的库和SDK。编写通用的可重用软件来管理跨HTTP，gRPC和GraphQL等不同协议的服务内通信非常复杂，昂贵且耗时。
部署基于微服务的应用程序后，上线之后的运维将由DevOps团队执行。他们需要监视服务运行状况，延迟，日志，事件和跟踪。 DevOps团队还有望实施基于策略的路由，以配置蓝/绿部署，金丝雀版本和滚动升级。最后，需要将源自多个微服务的指标，事件，日志和警报进行汇总，并与现有的可观察性和监视技术栈集成。
服务网格是云原生和微服务世界中的一种新现象，它试图为开发人员和运营商解决这些问题。在容器编排之后，如果有一项技术引起了开发人员和操作员的注意，那么绝对是服务网格。云原生倡导者建议在生产环境中运行微服务时使用服务网格。
服务网格使开发人员无需构建特定于语言的SDK和工具来管理服务内通信。对于运营商而言，服务网格可提供即用型流量策略，可观察性以及来自堆栈的洞察力。
服务网格的最好之处在于它是一种“零侵入”软件，不会强制更改代码或配置。通过利用sidecar的模式，服务网格将代理注入到每个服务中，充当主机服务的代理。由于代理会拦截每个入站和出站调用，因此它可以在调用堆栈中获得无与伦比的可见性。与服务相关联的每个代理将从调用堆栈收集的遥测发送到集中式组件，该组件还充当控制平面。运营商配置流量策略时，会将其提交到控制平面，控制平面将该策略推送到代理中以影响流量。软件可靠性工程师（SRE）利用服务网格的可观察性来深入了解应用程序。
服务网格与现有的API网关或Kubernetes入口控制器集成在一起。 API网关和入口处理南北流量时，服务网格负责东西向流量。
总而言之，服务网格是实现安全的服务到服务通信的基础结构层。它依赖于与每个微服务一起部署的轻量级网络代理。集中式控制平面协调代理以管理流量策略，安全性和可观察性。
即使服务网格主要与打包为容器的微服务一起使用，它也可以与VM甚至物理服务器集成。通过有效利用服务网格的流量策略，可以无缝集成跨多个环境运行的应用程序。这个因素使服务网格成为混合云和多云的关键推动因素之一。
有多种服务网格可供企业选择。本文试图帮助比较和对比云原生生态系统中可用的一些主流服务网格平台。
AWS App Mesh
AWS App Mesh在AWS re：Invent 2018上推出，旨在将服务网格的优势带到Amazon Web Services的计算和容器服务中。可以使用Amazon EC2，Amazon ECS，AWS Fargate，Amazon EKS甚至AWS Outposts轻松配置它。
由于App Mesh可以充当VM和容器的服务网格，因此Amazon基于虚拟服务，虚拟节点，虚拟路由器和虚拟路由创建了一个抽象层。
虚拟服务代表部署在VM或容器中的实际服务。虚拟服务的每个版本都映射到一个虚拟节点。虚拟服务和虚拟节点之间存在一对多关系。部署新版本的微服务后，只需将其配置为虚拟节点即可。类似于网络路由器，虚拟路由器充当虚拟节点的端点。虚拟路由器具有一条或多条遵循流量策略和重试策略的虚拟路由。网格对象充当所有相关实体和服务的逻辑边界。
代理与参与网格的每个服务相关联，该代理处理网格内流动的所有流量。
假设我们在AWS中运行两项服务：servicea.apps.local和serviceb.apps.local。
我们可以轻松地启用这些服务的网格，而无需修改代码。
我们注意到，serviceb.apps.local具有虚拟服务，一个虚拟节点，一个具有两个虚拟路由的虚拟路由器，这些虚拟路由决定了发送到微服务的v1和v2的流量的百分比。
与大多数服务网格平台一样，AWS App Mesh也依赖于开源Envoy代理数据平面。 App Mesh控制平面在构建时考虑了AWS计算服务。亚马逊还定制了Envoy代理以支持此控制平面。
将AWS App Mesh与Amazon EKS结合使用时，您将获得自动sidecar注入的好处以及在YAML中定义App Mesh实体的能力。亚马逊为EKS构建了CRD，以简化带有标准Kubernetes对象的App Mesh的配置。
AWS App Mesh生成的遥测可以与Amazon CloudWatch集成。指标可以导出到第三方服务（例如Splunk，Prometheus和Grafana）以及开放式跟踪解决方案（例如Zipkin和LightStep）。
对于使用AWS计算服务的客户，AWS App Mesh是免费的。 AWS App Mesh不收取任何额外费用。
Consul Connect
HashiCorp的Consul作为具有内置键/值数据库的服务发现平台而启动。它充当在同一主机或分布式环境中运行的服务的高效，轻量级负载均衡器。Consul公开用于发现注册服务的DNS查询接口。它还对所有注册的服务执行健康检查。
在容器和Kubernetes成为主流之前就已经创建了Consul。但是微服务和服务网格的兴起促使HashiCorp将Consul扩展为功能完善的服务网格平台。服务网格扩展Consul Connect使用相互传输层安全性（TLS）提供服务到服务的连接授权和加密。
有关实施Consul的详细说明和分步指南，请参阅我的Consul Service Discovery和Consult Connect教程。
由于sidecar模式是服务网格的首选方法，因此Consul Connect带有自己的代理来处理入站和出站服务连接。基于插件体系结构，Envoy可以用作Consul Connect的替代代理。
Consul Connect向Consul添加了两个基本功能-安全性和可观察性。
默认情况下，Consul将TLS证书添加到服务端点以实现相互TLS（mTLS）。这样可以确保始终对服务之间的通信进行加密。安全策略是通过intentions实现的，这些intentions定义了服务的访问控制并用于控制哪些服务可以建立连接。intentions可以拒绝或允许来自特定服务的流量。例如，数据库服务可以拒绝直接来自Web服务的入站流量，但允许通过业务逻辑服务发出的请求。
当Envoy用作Consul Connect的代理时，它将利用L7的可观察性功能。可以将与Consul Connect集成的Envoy配置为将遥测发送到各种来源，包括statsd，dogstatsd和Prometheus。
根据上下文，Consul可以充当客户端（代理）或服务器，当与Nomad和Kubernetes等编排器集成时，它支持Sidecar注入。有一张Helm chart可以在Kubernetes中部署Consul Connect。 Consul Connect配置和元数据作为注释添加到提交给Kubernetes的pod规范中。它可以与Ambassador集成，后者是Datawire的入口控制器，用于处理南北向流量。
Consul缺乏用于实施蓝/绿部署或Canary版本的高级流量路由和拆分功能。与其他服务网格选择相比，它的安全流量策略不是很灵活。通过Envoy的集成，可以配置一些高级路由策略。但是，Consul Connect没有为此提供接口。
总体而言，Consul和Consul Connect是健壮的服务发现和网格平台，易于管理。
Istio
Istio是由Google，IBM和Red Hat支持的最受欢迎的开源服务网格平台之一。
Istio还是最早使用Envoy作为代理的服务网格技术之一。它遵循与微服务关联的集中式控制平面和分布式数据平面的标准方法。
尽管Istio可以与虚拟机一起使用，但是它主要与Kubernetes集成。可以将部署在特定名称空间中的Pod配置为具有自动sidecar注入功能，其中Istio会将数据平面组件附加到Pod。
Istio为微服务开发人员和运营商提供了四种主要功能：
- 流量管理：Istio简化了诸如断路器，超时和重试之类的服务级别属性的配置，并使其易于实现基于百分比的流量拆分的配置，如A/B测试，canary部署和分段式部署。它还提供了开箱即用的故障恢复功能，有助于使您的应用程序更强大，以防止相关服务或网络的故障。 Istio带有自己的Ingress，可处理南北向流量。
- 扩展性：WebAssembly 是一种沙盒技术，可以用于扩展 Istio 代理（Envoy）的能力。Proxy-Wasm 沙盒 API 取代了 Mixer 作为 Istio 主要的扩展机制。在 Istio 1.6 中将会为 Proxy-Wasm 插件提供一种统一的配置 API。
- 安全：Istio为服务内通信提供了开箱即用的安全功能。它提供了基础安全通信通道，并大规模管理服务通信的身份验证，授权和加密。借助Istio，默认情况下就可以保护服务通信，从而使开发人员和操作员可以在各种协议和运行时之间一致地执行策略，而无需更改代码或配置。
- 可观察性：由于Istio的数据平面拦截了入站和出站流量，因此可以了解当前的部署状态。 Istio提供了强大的跟踪，监视和日志记录功能，可深入了解服务网格部署。 Istio带有集成的和预先配置的Prometheus和Grafana仪表板，以提高可观察性。
Google和IBM将托管的Istio作为其托管Kubernetes平台的一部分提供。 Google将Knative构建为基于Istio的无服务器计算环境。对于Anthos和Cloud Run等Google服务，Istio已成为其核心基础。与其他产品相比，Istio被认为是一个复杂而繁重的服务网格平台。但是可扩展性和丰富的功能使其成为企业的首选平台。
Kuma
Kuma于2019年9月启动，是服务网格生态系统的最新参与者之一。它是由API网关公司Kong，Inc开发和维护的，该公司以相同的名称Kong来构建开源和商业产品。
Kuma是对Kong API网关的逻辑扩展。前者处理南北流量，而后者处理东西向流量。
像大多数服务网格平台一样，Kuma带有单独的数据平面和控制平面组件。控制平面是服务网格的核心支持者，它支持所有服务配置的基本原理，并且可以无限扩展以管理整个组织中的成千上万的服务。 Kuma将快速数据平面与高级控制平面相结合，允许用户通过Kubernetes或REST API中的自定义资源定义（CRD）轻松设置权限，公开指标并设置路由策略。
Kuma的数据平面与Envoy代理紧密集成，使数据平面可以在Kubernetes中部署的虚拟机或容器中运行。 Kuma有两种部署模式：
1）通用
2）Kubernetes。
在Kubernetes中运行时，Kuma利用API服务器和etcd数据库存储配置。在通用模式下，它需要外部PostgreSQL作为数据存储。
控制平面组件Kuma-cp管理一个或多个数据平面组件kuma-dp。在网格上注册的每个微服务都运行kuma-dp的唯一副本。在Kubernetes中，kuma-cp在kuma系统名称空间内作为CRD运行。为kuma注释的名称空间可以将数据平面注入每个pod中。
Kuma附带了一个GUI，可提供部署概述，包括向控制平面注册的每个数据平面的状态。可以使用相同的界面查看来自附加到微服务的代理的运行状况检查，流量策略，路由和跟踪。
Kuma服务网格具有内置的CA，用于基于mTLS加密流量。可以基于与微服务关联的标签来配置流量许可。跟踪可以与Zipkin集成，而指标可以重定向到Prometheus。
Kuma缺少一些先进的弹性功能，例如断路，重试，故障注入和延迟注入。
Kuma是精心设计的干净的服务网格实现。它与Kong Gateway的集成可能会推动其在现有用户和客户中的采用。
Linkerd 2.x
Linkerd 2.x是Buoyant专为Kubernetes构建的开源服务网格。它获得了Apache V2的许可，并且是一个Cloud Native Computing Foundation孵化项目。
Linkerd是一个超轻便，易于安装的服务网格平台。它具有三个组件– 1）CLI和UI，2）控制平面和3）数据平面。
一旦将CLI安装在可以与Kubernetes群集通信的计算机上，就可以使用单个命令安装控制平面。控制平面的所有组件都作为Kubernetes部署安装在linkerd名称空间中。 Web和CLI工具使用控制器的API服务器。目标组件将路由信息告知运行数据平面的代理。注入器是Kubernetes准入控制器，每次创建Pod时都会接收Webhook请求。该服务用于将代理作为sidecar注入到命名空间中启动的每个pod。身份组件负责管理对实现代理之间的mTLS连接至关重要的证书。点击组件从CLI和Web UI接收请求，以实时监视请求和响应。
Linkerd随附了预配置的Prometheus和Grafana组件，提供了现成的仪表板。
数据平面具有轻量级代理，可将其作为辅助工具附加到服务。有一个Kubernetes初始化容器来配置iptables来定义流量，并将代理连接到控制平面。
Linkerd符合服务网格的所有属性-流量路由/拆分，安全性和可观察性。
有趣的是，Linkerd并未使用Envoy作为代理。相反，它依赖于用Rust编程语言编写的专用轻量级代理。 Linkerd的堆栈中没有内置入口，但可以与入口控制器配合使用。
在Istio之后，Linkerd是流行的服务网格平台之一。考虑到轻量级且易于使用的服务网格，它吸引了开发人员和运营商的注意力。
Maesh
Maesh来自于Containous，该公司建立了流行的 ingress Traefik。与Kong，Inc类似，Containous建立了Maesh以补充Traefik。当Maesh处理微服务中的东西向流量时，Traefik则驱动着南北向流量。与Kuma一样，Maesh也可以与其他入口控制器一起使用。
与其他服务网格平台相比，Maesh采用了不同的方法。它不使用边车模式来操纵流量。相反，它为每个Kubernetes节点部署了一个Pod，以提供定义良好的服务端点。即使部署了Maesh，微服务也可以继续工作。但是，当他们使用Maesh公开的替代终结点时，他们可以利用服务网格功能。
Maesh的目标是提供一种非侵入性和非侵入性的基础架构，为开发人员提供选择功能。但这也意味着该平台缺少某些关键功能，例如透明TLS加密。
Maesh支持服务网格的基本功能，包括路由和可观察性（安全性除外）。它支持Service Mesh Interface（SMI）项目定义的最新规范。
在我在Kubernetes中部署的所有服务网格技术中，我发现Maesh是最简单，最快的平台。