哪种服务网格最适合您的企业？近年来，Kubernetes服务网格框架的数量增长迅速，这使这个问题变得棘手。下面将介绍9个流行的服务网格框架来支持微服务的开发，每个方案都给出了适用场景。什么是服务网格？ServiceMesh成为近年来的热门话题。其背后的原因是什么？微服务已经成为一种灵活快速的开发方式。然而，随着微服务数量呈指数级增长，开发团队开始遇到部署和可扩展性问题。Kubernetes等容器和容器编排系统将运行时和服务打包成镜像，将容器调度到合适的节点上运行容器。该方案可以解决开发团队遇到的很多问题。但是，在这个运行过程中还有一个缺点：如何管理服务之间的通信。在使用服务网格的场景下，以与应用代码解耦的方式增强了应用之间的统一网络通信能力。服务网格扩展了集群的管理能力，增强了可观察性、服务发现、负载均衡、IT运维监控、应用故障恢复等功能。服务网格概述服务网格一直很受欢迎。正如Linkerd的作者WilliamMorgan所说：“服务网格本质上只不过是与应用程序捆绑在一起的用户空间代理。”这句话相当简洁，他补充说，“如果你能看穿噪音，服务网格就能给你带来真正的重要价值。”Envoy是许多服务网格框架的核心组件，是一种通用的开源代理，通常用作Pod中的sidecar来拦截流量。还有使用替代代理方案的服务网格。在具体服务网格解决方案的流行度方面，Istio和Linkerd获得了更多的认可。还有其他选项，包括ConsulConnect、Kuma、AWSAppMesh和OpenShift。以下部分描述了九个服务网格提供的主要功能。IstioIstio是一个基于Envoy构建的可扩展的开源服务网格。它允许开发团队连接、加密、管理和观察应用程序服务。Istio于2017年开源，IBM、Google和Lyft仍在维护和升级。Lyft于2017年向CNCF捐赠了Envoy。Istio花费了大量时间改进和增强其功能。Istio的主要功能包括负载均衡、流量路由、策略创建、可扩展性和服务间身份验证。Istio由两部分组成：数据平面和控制平面。数据平面处理流量管理，通过Envoy的sidecar代理进行流量路由和服务间调用。控制面主要供开发者配置路由规则和观察指标。Istio观察是细粒度的属性，其中包含与服务行为相关的特定数据值。这是一个例子：request.path:xyz/abcrequest.size:234request.time:12:34:56.78904/17/2017source.ip:[19216801]destination.service.name:exampleandothers与服务网格相比，Istio更胜一筹的是平台成熟度，通过Dashbaord突出了服务行为观察和业务管理功能。然而，由于这些高级功能和复杂的配置过程，Istio可能不像其他一些替代方案那样容易上手。Linkerd官网介绍，Linkerd是一个轻量级、安全至上的Kubernetes服务网格。它的创建过程快得令人难以置信（据报道在Kubernetes上安装只需60秒），这是大多数开发人员都会喜欢的。Linkerd不建立在Envoy之上。相反，linkerd2-proxy是专门为Linkerd服务网格编写的基于Rust的高性能代理。Linkerd是社区驱动的，是一个100%Apache许可的开源项目。也是CNCF的孵化项目。Linkerd始于2016年，维护者花了很多时间修复其中的缺陷。使用Linkerd服务网格，应用程序服务可以在部署在Kubernetes上时增强其可靠性、可观察性和安全性。例如，可观察性增强可以帮助用户解决服务之间的延迟问题。使用Linkerd不需要用户进行大量代码调整或花费大量时间编写YAML配置文件。可靠的产品特性和积极的开发人员反馈使Linkerd成为服务网格的有力竞争者。ConsulConnectConsulConnect是HashiCorp的一个服务网格，专注于路由和分段，并通过应用程序级sidecar代理提供服务之间的网络功能。ConsultConnect专注于应用程序安全，提供应用程序之间的相互TLS连接以进行授权和加密。ConsultConnect的独特之处在于提供两种代理模式。一是它内置的代理，它也支持Envoy方案。Connect强调可观察性，集成Prometheus等工具来监控来自sidecar代理的数据。ConsulConnect可以灵活满足开发者的需求。例如，它提供了多种注册服务的方式：从编排系统、通过配置文件、通过API调用或命令行工具。KumaKuma来自Kong，并声称是一种非常有用的服务网格替代方案。Kuma是一个基于Envoy的与平台无关的控制平面。Kuma提供安全、观察和路由等网络特性，同时增强服务之间的连接性。Kuma同时支持Kubernetes和虚拟机。Kuma的一个有趣之处在于，它的企业版可以通过统一的控制面板来操作和管理多个隔离、独立的服务网格。该能力可以满足对安全性要求较高的使用场景。既满足隔离要求，又实现了集中控制。Kuma也是一个相对容易安装的解决方案。因为它内置了很多策略，这些策略涵盖了常见的需求，比如路由、双向TLS、故障注入、流控、加密等场景。Kuma与Kong原生兼容，使其成为已经采用KongAPI管理的企业组织的自然选择。MaeshMaesh是来自Containous的容器原生服务网格，它标榜自己是比市场上其他服务网格更轻量级且更易于使用的解决方案。与许多构建在Envoy之上的服务网格不同，Maesh使用Traefik，一种开源反向代理和负载均衡器。Maesh不使用sidecar进行代理，而是在每个节点上部署一个代理终端。这样做的好处是不需要编辑Kubernetes对象，同时允许用户有选择地修改流量。Maesh比其他服务网格的侵入性更小。Maesh支持的配置方式：为用户服务对象添加注解或者为服务网格对象添加注解来实现配置。事实上，SMI是一种新的服务网格规范格式，对SMI的支持是Maesh独有的一大亮点。随着SMI逐渐被业界采用，可以提高可扩展性，缓解供应商锁定问题。Maesh需要Kubernetes1.11或更高版本，集群中安装了CoreDNS/KubeDNS。本安装指南演示了如何通过Helmv3快速安装Maesh。helmrepoaddmaeshhttps://containous.github.io/maesh/chartshelmrepoupdatehelminstallmaeshmaesh/maeshServiceComb-mesherApache软件基金会将其ServiceComb-mesher描述为“用Go语言实现的高性能服务网格”。Mesher是基于非常流行的Go语言微服务开发框架GoChassis设计实现的。因此，它继承了GoChassis的一些服务发现、负载均衡、容错、路由管理和分布式追踪等特性。Mesher采用边车方法；每个服务都有一个Meshersidecar代理。开发者通过AdminAPI与Mesher交互，查看运行时信息。Mesher同时支持HTTP和gRPC，可以快速移植到不同的基础设施环境，包括Docker、Kubernetes、虚拟机和裸机环境。网络服务网格(NSM)网络服务网格(NSM)是专门为电信公司和ISP设计的服务网格。它提供了一个层来增强Kubernetes中服务的低级网络功能。NSM目前是一个CNCF沙盒项目。根据NSM的文档，“经常接触L2/L3层的网络运营商抱怨说，适合他们下一代架构的容器网络解决方案很少”。因此，NSM在设计时考虑了一些不同的使用场景，尤其是具有不同网络协议和混合网络配置的场景。这使得NSM对于一些特殊场景非常有吸引力，比如边缘计算、5G网络和物联网设备。NSM使用简单直接的API接口来实现容器与外部端点之间的通信。NSM与其他服务网格工作在不同的网络层。VMware将NSM描述为“以连接为中心”。GitHub文档演示了NSM如何与Envoy协同工作。AWSAppMeshAWSAppMesh为开发者提供了一个“针对不同服务的应用层网络”。它接管了服务的所有网络流量，并使用开源的Envoy代理来控制进出容器的流量。AWSAppMesh支持HTTP/2gRPC。对于将容器平台与AWS深度绑定的公司来说，AWSAppMesh将是一个非常好的服务网格解决方案。AWS平台包括AWSFargate、AmazonElasticContainerService、AmazonElasticKubernetesService(EKS)、AmazonElasticComputeCloud(EC2)、EC2上的Kubernetes，包括AWSAppMesh，无需额外费用。AWSAppMesh与AWS生态系统中的监控工具无缝兼容。这些工具包括CloudWatch和AWSX-Ray，以及一些来自第三方供应商的工具。由于AWS计算服务支持AWSOutposts，AWSAppMesh可以很好地兼容混合云和已部署的应用程序。AWSAppMesh的劣势可能是开发者深度绑定单一供应商解决方案，相对闭源，缺乏可扩展性。RedHat的OpenShiftServiceMeshOpenShift是RedHat的容器管理平台，可帮助用户“连接、管理和观察微服务应用程序”。OpenShift预装了很多增强企业能力的组件，也被描述为企业级混合云Kubernetes平台。OpenShiftServiceMesh构建于开源Istio之上，具有Isito的控制平面和数据平面特性。OpenShift利用两个开源工具来增强Isito的可追溯性和可观察性。OpenShift使用Jaeger进行分布式跟踪，以更好地跟踪请求在服务之间的处理方式。另一方面，OpenShift使用Kiali来增强微服务配置、流量监控、跟踪分析等方面的可观察性。如何选择文中提到，有很多ServiceMesh方案可供选择，并且不断有新的方案涌现。当然，每个解决方案在技术实现上都略有不同。在选择合适的服务网格时，主要考虑的因素包括你能接受多大的入侵，它的安全性如何，以及平台的成熟度。以下几点可以帮助DevOps团队选择适合自己场景的服务网格：是否依赖Envoy。Envoy拥有活跃的社区生态系统。开源和许多服务网格的基础。Envoy功能的丰富性使其成为一个难以绕过的因素。具体使用场景。服务网格是为微服务而生的。如果你的应用是一个单体庞然大物，你在服务网格上的投资可能达不到预期的收益。如果不是所有的应用程序都部署在Kubernetes上，应该优先考虑平台无关的解决方案。现有容器管理平台。一些企业已经使用特定的供应商生态系统来解决容器编排问题，例如AWS的EKS、RedHat的OpenShift和Consul。遵循原生态，才能继承和扩展原有的特色。而这些可能不是开源解决方案提供的。行业。许多服务网格并非专为特定行业而构建。Kuma统一管理多个孤立的服务网格的能力可能更适用于高度监管的金融行业。底层网络电信公司和ISP应该更多地考虑NetworkServiceMesh。可视化要求。可观察性是服务网格的核心能力之一。考虑进一步定制和更深入功能的团队应优先考虑Istio或Consul。是否遵循开发标准。遵循开发标准使您的平台更具前瞻性和可扩展性。这使得企业倾向于采用支持SMI、Maesh或其他基金会孵化项目（如Linkerd）的解决方案。是否注重用户体验。考虑运维人员的易用性是判断新工具的一个关键指标。Linkerd似乎在开发人员中享有良好的声誉。团队准备好了。评估你的团队的资源和技术储备，在选择技术时决定你是适合基于Envoy的Istio还是提供商的抽象包，比如OpenShift。这些注意事项并未涵盖所有情况。这里只是抛砖引玉，引发读者思考。希望在阅读上面的服务网格清单和相关决策因素后，您的团队可以找到新的方法来改善微服务应用程序的网络特性。
