哪种Service Mesh最契合企业的组织需求？

哪种Service Mesh最契合企业的组织需求？近年来，Kubernetes Service Mesh数量迅速增长，也让这方面选择变得愈发困难。本文将与大家深入探讨九大流行开源Service Mesh，了解它们如何支持微服务开发工作，并针对不同选项提出用例建议。

在进入主题之前，我们先要明确两个问题：Service Mesh是什么？这波热潮又为何发生在当下？

首先，微服务是一种便捷的开发方法。但随着分布式微服务架构的持续扩张，部署与可扩展性往往给开发者带来新的难题。

Kubernetes等容器与容器编排工具能够将各项服务与相应运行时共同打包，执行打包容器并将其映射至设备以解决上述难题。但其中负责管理服务间通信的操作逻辑仍然不可能完美契合。

Service mesh正是为此而生——它以独立于应用程序代码之外的方式，为整体堆栈带来统一的网络功能。Service Mesh扩展了Kubernetes等集群管理器的功能范畴，提供丰富的可观察指标、服务发现、负载均衡、IT运营监控以及微服务/容器故障恢复等功能选项。

Service mesh现状

如今，关于Service Mesh存在着诸多炒作甚至误解。Linkerd缔造者William Morgan强调，“Service Mesh其实就是一大堆与服务本体紧密相邻的用户空间代理。”虽然实质非常简单，但“在排除掉种种噪声与误解之后，Service Mesh确实带来了切实、具体且重要的价值。”

如今，Envoy已经成为大部分Service Mesh的核心。Envoy是一种通用开源代理，以辅助方式实现流量拦截。当然，也有一些Service Mesh会使用其他代理选项。

在Service Mesh的实际应用方面，Istio与Linkerd已经占据主流。除此之外，Consul Connect、Kuma、AWS App Mesh以及OpenShift等也都拥有自己的受众。下面来看九大service mesh产品的功能特性。

Istio

Istio是一种基于Envoy的可扩展开源Service Mesh，允许团队连接、保护、控制并观察各项服务。作为IBM与谷歌的持续合作产物，Istio于2017年正式开源，连同Lyft一道被捐赠给云原生计算基金会。

在此之后，Istio不断完善并改进自身功能集。目前Istio的核心功能包括负载均衡、流量路由、策略创建、指标跟踪以及服务到服务身份验证等。

Istio分为两个组成部分：数据平面与控制平面。Istio的数据平面使用Envoy边车代理在各服务之间实现流量与调用路由，借此实现流量管理。Istio的控制平面则可供开发人员用于配置路由并查看各项指标。

Istio提供的各项指标均提供细粒度属性，其中包含与服务行为相关的特定数据值。

与其他Service Mesh相比，Istio的平台成熟度更高，主要偏重行为洞见与操作控制，同时提供监控仪表板。但由于包含大量先进功能与密集的配置流程，Istio在易用性及开发者友好度方面往往不及其他更为简单的Service Mesh。

Linkerd

根据官方网站的说明，Linkerd是一套“面向Kubernetes的超轻量级、安全优先型Service Mesh。”它是开发者们的最爱，设置过程非常简单，据称只需要60秒左右即可安装至Kubernetes集群。不同于采用Envoy的Istio，Linkerd采用名为linkerd2-proxy的调整精简Rust代理，从名称就能看出其为Linkerd量身打造之意。

Linkerd属于社区驱动型项目，采用100% Apche许可开源代码，同时也是云原生计算基金会（CNCF）旗下的孵化项目。诞生于2016年的Linkerd一直不断发展，诸多原有问题已经在维护人员手中得到解决。

使用Linkerd Service Mesh，应用程序能够为其Kubernetes部署带来更强大的可靠性、可观察性与安全性。例如，更好的可观察性使工程师们能够高效解决不同服务之间的通信延迟问题。Linkerd无需对代码做出过多更改，也不需要耗费时间编写YAML配置文件。优秀的功能与积极的开发者社区响应态度，让Linkerd在受众当中积累起良好的口碑。

Consul Connect

HashiCorp开发的Consul Connect Service Mesh专注于路由与分段功能，可通过应用层级的边车代理提供服务到服务网络功能。Consult Connect特别强调应用程序安全性，其代理能够为应用程序提供双向传输层安全（TLS）连接以实现授权与加密。

Consul Connect的独特之处，在于提供两种代理选项。首先是Connect的内置层代理，主要用于测试场景；此外，Connect还支持Envoy。在可观察性方面，Connect提供良好的工具集成能力，可监控Prometheus等边车代理的相关数据。Consul Connect也能够灵活满足开发人员的实际需求，提供的注册服务选项包括：通过编排器注册、使用配置文件注册、通过API注册或通过命令行界面（CLI）注册。

Kuma

由Kong打造的Kuma同样是一套强大的Service Mesh解决方案。Kuma属于基于Envoy构建的平台中立型控制平面。Kuma提供多种网络功能，用以保护、观察、路由并增强服务之间的连接性。除虚拟机之外，Kuma还支持Kubernetes。

Kuma的一大特性，在于允许企业用户通过统一的控制平面操作并控制多个隔离网格。对于需要分段并进行集中控制的高安全性用例，这项功能无疑至关重要。

Kuma也相对易于使用，其中预装有捆绑策略，全面涵盖多种通行需求，例如路由、双向TLS、故障注入、流量控制、安全保护等等。Kuma原生与Kong相兼容，因此成为已经使用Kong API的组织的首选Service Mesh方案。

Maesh

Maesh是Containous打造的原生容器Service Mesh，以轻量化设计著称，而且比市面上的其他Service Mesh更易于使用。不同于以Envoy为基础的主流选择，Maesh采用了开源反向代理与负载均衡方案Traefik。

Maesh并没有采用边车容器格式，而是为每个节点提供代理端点。这种方式使Maesh的侵入性较其他Service Mesh更低——除非明确指定，否则其不会编辑任何Kubernetes对象或者修改流量内容。Maesh支持两种配置选项：用户服务对象以及Service Mesh Interface (SMI)对象。

事实上，对SMI（一种新型标准服务网格规范格式）的支持已经成为Maesh的独特特征。如果后续SMI在行业中的采用率有所提高，Maesh将进一步增强自身可扩展性优势，并有望借此缓解供应商锁定问题。

根据Apache软件基金会的介绍，ServiceComb-mesher 是一套“以Go语言编写的高性能Service Mesh实现方案。”Mesher基于Go Chassis（一种流行的Go语言微服务开发框架），因此继承了Go Chassis提供的服务发现、负载均衡、高容错、路由管理以及分布式跟踪等功能。

Mesher采用边车设计方法；每项服务都对应专门的Mesher Sidecar代理。开发者能够与Mesher进行交互，并通过Admin API查看运行时信息。Mesher支持HTTP与gRPC，能够移植到多种不同的基础设施类型，包括Docker、Kubernetes、虚拟机以及裸机环境。

Network Service Mesh (NSM)

Network Service Mesh (NSM)属于专为电信公司及互联网服务供应商（ISP）构建的Service Mesh，可提供向Kubernetes添加底层网络功能的层。NSM目前为云原生计算基金会的沙箱孵化项目。

根据NSM说明文档的介绍，“目前，需要运营高级L2/L3用例的多层网络运营商，往往很难找到适合其下一代架构的容器网络解决方案。”

为此，NSM在构建过程中会充分考虑到不同的假设性条件，包括强调“跨域”协议与异构网络配置。凭借这种能力，NSM成为边缘计算、5G网络以及物联网设备等特定用例中的首选方案。NSM使用简单的API套件实现容器与外部端点之间的通信。

NSM与本份榜单中的其他service mesh动作在不同的层上。VMware将NSM描述为“连接中心”；从GitHub软件包来看，NSM以Envoy为代理基础。

AWS App Mesh

Amazon Web Services推出的 App Mesh 能够为所有服务提供“应用级网络”支持。App Mesh能够管理服务间的所有网络流量，并使用开源Envoy代理控制流入与流出服务容器的流量。AWS App Mesh支持HTTP/2 gRPC服务。

对于已经在容器平台内使用AWS基础设施的用户来说，AWS App Mesh应该是个理想的Service Mesh选项。目前，包括AWS Fargate、Amazon Elastic Container Service、Amazon Elastic Kubernetes Service (EKS)、Amazon Elastic Compute Cloud (EC2)以及Kubernetes on EC2在内的各类AWS平台都提供AWS App Mesh，且无需额外付费。

AWS App Mesh还与AWS生态系统内的各类监控工具相兼容，包括Amazon工具（例如CloudWatch与AWS X-Ray）以及多种第三方服务商的工具。由于AWS计算服务支持AWS Outposts，因此AWS App Mesh可以与混合云及本地部署协同运行。

AWS App Mesh的缺点主要体现在开源或可扩展工具选项较少，可能导致用户遭遇严重的供应商锁定。

Red Hat的OpenShift Service Mesh

OpenShift是Red Hat打造的容器管理平台，可帮助“连接、管理并观察基于微服务架构的应用程序。”作为一套企业级混合云Kubernetes平台，OpenShift已经预装有多项功能，也已经在企业受众中得到广泛采用。

OpenShift Service Mesh以开源Istio为基础，因此能够提供多种Istio控件与数据平面功能。OpenShift同时引入两款开源工具，在跟踪能力与可见性方面对Istio予以增强。OpenShift使用Jaeger进行分布式跟踪，借此更好地跟踪不同服务之间的请求处理方式。
OpenShift还使用Kiali在微服务配置、流量监控以及分析跟踪中加入更强的可观察能力。

选择service mesh时的注意事项

本份榜单列出了多种Service Mesh选项，而且各个项目的发展态势也在不断变化。当然，每种Service Mesh的实现方式互不相同，也在具体功能上有所体现。在实际选择中，大家需要考虑到Service Mesh的侵入度、默认安全水平、平台成熟度以及其他问题。

DevOps团队也应参考以下因素，判断哪种service mesh最适合当前需求：

• 能否脱离Envoy？Envoy拥有充满活力的社区生态系统，属于开源项目而且作为多种Service Mesh的实现基础。其丰富的功能几乎找不到真正全面的替代方案。

• 用例提出哪些现实需求？Service mesh面向微服务架构。如果需要构建单体式应用，大家显然无需使用Service Mesh。另外，如果您的某些应用程序并不使用Kubernetes，最好选择具有良好平台中立性的方案。

• 您的现有容器管理工具中存在哪些依赖关系？已经在容器编排体系中引入某些供应商生态要素（例如AWS EKS、Red Hat OpenShift以及Consul）的用户不妨直接选择原生工具，借此将功能扩展至开源软件包之外。

• 您身处哪个行业？大多数Service Mesh并非针对特定行业进行设计与构建。但是，Kuma拥有强大的网格分区能力，因此特别适合需要遵循严格监管的金融平台。而底层网络电信企业与互联网服务供应商则更适合选择Network Service Mesh。

• 您需要怎样的可观察性？可观察性是Service Mesh中的一项核心指标。需要这类深层定制化功能的用户，可以优先考虑Istio与Consul。

• 您是否关心开放标准？使用开放标准，可以保证您的技术随时跟进时代发展，并通过其他工具完成持续扩展。如果您有这类诉求，不妨选择支持SMI的工具（例如Maesh）或者由基金会支持的项目（例如Linkerd）。

• 您是否关心开发者体验？在选择新工具时，很多企业都会关注运维工程师的实际体验。Linkerd在开发者群体中享有良好声誉，可能符合您的需求。

• 您的团队是否为Service Mesh做好了准备？评估组织内是否具有资源及技能，用以实施Service Mesh技术。这个问题的答案将直接决定您选择基于Envoy的Istio，或者使用OpenShift等经由供应商层进行抽象化的解决方案。

当然，以上事项并不完全，只是为大家提供一点讨论思路。希望您在审视以上列出的各项要点之后能够得到一点启发，探索出微服务网络开发的更多实现途径。