服务网格（Service mesh）已经不是一个新鲜概念，但它实现了连接运行在Kubernetes作为容器化平台之上的微服务，这使得服务网格的想法更加流行。如果没有服务网格，每个微服务都需要配置以接收（或发送）连接到其他需要与之通信的微服务，但服务网格完全改变了这一状况。

与此前需要手动配置以及投入大量的时间精力来维护微服务之间的连接所不同的是，开发人员现在可以创建一个网格，使得微服务彼此通信可靠、可控以及安全。Kubernetes和服务网格是相互作用的，主要是因为使用服务网格可以在不增加工作量的情况下，实现更复杂的容器化架构。

因此，有很多方式可以在Kubernetes顶层建立一个服务网格。在本文中，我们将比较一些你可以用于建立服务网格的工具，你可以分别了解到它们的优劣势进而选出最适合自己的服务网格工具。

与AWS环境完美适配：AWS App Mesh

官网：https://aws.amazon.com/app-mesh/

由于现在许多基于Kubernetes的应用程序和微服务都运行在Amazon Web Services环境中，所以很难不谈到AWS App Mesh。顾名思义，AWS App Mesh是亚马逊自己的服务网格，用于为Amazon services创建服务网格层。

作为亚马逊的产品，AWS App Mesh利用结合了Envoy的专有技术作为其服务代理。AWS App Mesh通过创建虚拟服务在相同的命名空间中连接服务。 在你的AWS环境中每个微服务都可以找到虚拟服务并使用它来与其他微服务通信。

AWS App Mesh与其他服务（例如EKS、Fargate和EC2）的无缝集成是其最强的优势，但在使用App Mesh的过程中存在一些限制。首先，你不能将App Mesh迁移到外部或者在多云设置中使用这一服务。

App Mesh还借助CloudWatch和AWS X-Ray来管理服务网格，这意味着你可以在不离开主仪表板的情况下完全控制该层。诸如支持mTLS和高级负载均衡的特性在App Mesh中也有，但是它不支持身份验证规则。

最流行的服务网格工具：Istio

官网：https://istio.io/latest/zh/

Istio可能是最流行的Kubernetes服务网格工具，它最初由Lyft开发，但后来变成Lyft、Google和IBM联合开发。考虑到Kubernetes背后的公司是谷歌，那么Istio被广泛用于许多部署类型也并不奇怪了。

与App Mesh类似，Istio也将Envoy用作其服务代理，但它并没有限制你把Envoy作为唯一的ingress controller。Istio的独特之处在于它提供了巨大的灵活性。你可以将Istio用于其他的容器化平台，但其与Kubernetes的无缝衔接使其发挥的作用更大。

例如，Istio支持mesh扩展和多云网格，这两个特性在App Mesh和其他服务网格工具里都是没有的。Istio还可以处理流量访问控制以及负载均衡，就像它是为了执行这些任务而构建的一样。它甚至支持故障注入和延迟注入。

使用Istio的唯一缺点是你可能会对它提供的功能感到不知所措。如果你有足够的资源使用Istio处理服务网格层，这个工具有可能通过其功能简化最复杂的微服务架构。

独立的服务网格工具：Linkerd

官网：https://linkerd.io/

当Linkerd发布2.x版本时，它已经是一个十分流行的服务网格工具了。新版本受到了Kubernetes社区的欢迎，截止到2020年4月中旬，其2.7.1稳定版已经出炉。它完全是作为一个独立的服务网格工具来构建的，所以它并不依赖Envoy等第三方工具来管理，它甚至还包含了linkerd-proxy作为服务代理。

最近的升级还包括dashboard的改进和针对金丝雀部署的流量拆分功能的可视化。这使其成为实时监控和编排金丝雀和蓝绿部署的绝佳工具。

在保持独立的同时，Linkerd还与Ingress controller保持高度兼容性。实际上，Linkerd能够与你使用的任意Ingress controller一起工作，使它在这方面最为灵活。一个简单的linkerd inject命令就可以让服务网格与你的应用程序集成。

Linkerd2 也是高度优化的，安装仅需60秒。如果你正在寻找可以带来最佳性能的服务网格工具，那么Linkerd是你可以考虑尝试的。作为一个非侵入式的服务网格工具，Linkerd在部署之后并不需要进行大量的优化。开箱即用的配置足以支持复杂的微服务架构，并且能够防止重大工具。Linkerd通过mutual TLS(mTLS)加密来增强应用程序的安全性。

Linkerd也是一个专门为Kubernetes开发的工具。它可能不支持多云和多集群网格创建，但这丝毫不会减弱其作为Kubernetes实例的服务网格层的能力。除此之外，它也可以与OpenCensus配合使用，从而使跟踪和管理变得非常容易。

最年轻的服务网格工具：Kuma

官网：https://kuma.io/

Kuma将Envoy作为服务代理并且支持任意ingress controller。这与Consul Connect十分类似（该工具我们稍后会介绍），但Kuma也有自己令人耳目一新的功能。而且这些新意可能是因为Kuma是这个列表中最新的工具。

不要被Kuma年轻的年龄所欺骗了，它不仅仅已经生产就绪，而且还具备了你所期望的服务网格工具的功能。它支持所有与OpenTracing兼容的所有后端并且允许你在需要时使用外部CA证书。不过，这一工具也存在不完善的地方——有一些功能是缺失的。

目前，在Kuma中没有办法进行基于路径或基于请求头的流量分割。它也不支持诸如流量访问控制和指标等功能。这些功能也许会在后续版本中引入，但现在你必须得手动制作代理模板来弥补这些功能的缺失。

但是，Kuma作为一个服务网格工具还是很有前途的，尽管目前它只是0.4.0版本，但其开发者十分关注社区的意见并且十分乐意满足用户的要求，从这个维度上看，这个工具无疑是极具竞争力的。

最适用于Consul环境的服务网格：Consul Connect

官网：https://www.consul.io/

由HashiCorp推出的Consul Connect可以与Envoy及其他各种服务代理一起工作，它还可以与任何ingress controller一起工作，这使其成为最容易集成到现有Kubernetes集群中的工具之一。

在任意Consul环境中Consul Connect都可以无缝衔接，但是它也只能在Consul环境中工作。虽然该服务网格工具提供了许多方便的功能，但它是为了能与其他HashiCorp产品使用而设计的。不过，这些工具的应用十分广泛。

从TCP到gRPC的一切都支持，此外这一工具还能与Kubernetes、VM甚至Nomads一起工具。网格扩展也是完全支持的，所以你可以拥有一个跨多个云服务和集群的环境，并且仍然具有一个支持微服务的功能强大的服务网格层。

Consul Connect需要改进的一个方面是监控。然而，你也可以整合其他监控工具，以便获得日志和每个路由的指标。你甚至可以集成诸如Prometheus和Grafana等工具来可视化你的监控数据。然后你只需要从你的服务代理中提取数据即可。

Envoy Proxy

这些服务网状工具基本设计为Envoy作为服务代理。与其他边缘代理工具相比，Envoy确实具有一些优势，其中高级负载均衡是最突出的优势。

自动重试、区域本地负载均衡、request shadowing等功能可以让你配置流量负载均衡以获得最大性能。另一方面，高可观察性使得Envoy成为维护支持能力强大架构的网络的完美解决方案。

当然，这些工具有一个主要目标：创建一个云架构，在这个架构中，微服务可以以可靠和安全的方式彼此通信。好消息是，无论你使用哪种工具，你都能实现这个目标。

本文来自Rancher Labs