大家好，关于9 种开源的服务网格比较-服务网格架构很多朋友都还不太明白，今天小编就来为大家分享关于的知识，希望对各位有所帮助！
下面将介绍9种比较流行的服务网格框架来支持微服务开发，并且每种解决方案都给出了其适用场景。
什么是服务网格
服务网格近年来已经成为一个非常热门的话题。其背后的原因是什么？
微服务已经成为一种灵活、快速的开发方法。然而，随着微服务数量呈指数级增长，开发团队开始遇到部署和可扩展性问题。
容器和容器编排系统（例如Kubernetes）将运行时和服务打包成镜像，将容器调度到适当的节点并运行容器。这个方案可以解决开发团队遇到的很多问题。然而，这个操作流程仍然存在一个不足：如何管理服务之间的通信。
[[347598]]
在使用Service Mesh的场景中，以与应用程序代码解耦的方式增强应用程序之间的统一网络通信能力。服务网格扩展了集群的管理能力，增强了可观察性、服务发现、负载均衡、IT运维监控、应用故障恢复等功能。
服务网格概览
服务网格一直很受欢迎。正如Linkerd 作者William Morgan 所提到的：“服务网格本质上只不过是与应用程序捆绑在一起的用户空间代理。”这非常简洁，他补充道，“如果你能看透噪音，服务网格就能为你带来真正且重要的价值。”
Envoy 是许多服务网格框架的核心组件。它是一个通用的开源代理，通常用作Pod 中的sidecar 来拦截流量。还有一些服务网格使用替代代理解决方案。
当谈到特定服务网格解决方案的受欢迎程度时，Istio 和Linkerd 获得了更多认可。还有其他选项，包括Consul Connect、Kuma、AWS App Mesh 和OpenShift。下面描述了九个服务网格提供的关键功能。
IstioIstio 是一个基于Envoy 构建的可扩展开源服务网格。它允许开发团队连接、加密、控制和观察应用程序服务。 Istio 于2017 年开源，目前由IBM、Google 和Lyft 维护和升级。 Lyft 于2017 年向CNCF 捐赠了Envoy。
Istio 花费了大量时间来改进和增强其功能。 Istio 的主要功能包括负载均衡、流量路由、策略创建、可扩展性和服务间身份验证。
Istio 由两部分组成：数据平面和控制平面。数据平面负责处理流量管理，通过Envoy 的sidecar 代理实现流量路由和服务间调用。控制平面主要供开发者配置路由规则和观察指标。
Istio 可观察量是细粒度的属性，包含与服务行为相关的特定数据值。这是一个例子：
request.path: xyz/abc request.size: 234 request.time: 12:34:56.789 04/17/2017 source.ip: [192 168 0 1] destination.service.name: 示例
与其他服务网格相比，Istio 凭借其平台成熟度和Dashbaord 表现出色
注重突出服务行为观察和业务管理功能。然而，由于这些高级功能和复杂的配置过程，Istio 可能不像其他一些替代方案那么易于使用。
Linkerd据官网介绍，Linkerd是一个轻量级、安全第一的Kubernetes服务网格。它的创建过程非常快（据说在Kubernetes 中安装只需60 秒），这是大多数开发人员喜欢听到的。 Linkerd 不使用基于Envoy 的构建解决方案。相反，使用基于Rust 的高性能代理linkerd2-proxy，它是专门为Linkerd 服务网格编写的。
Linkerd 是社区驱动的，是一个100% Apache 许可的开源项目。也是CNCF的孵化项目。 Linkerd 于2016 年启动，其维护者花费了大量时间来修复其缺陷。
使用Linkerd 服务网格，应用程序服务可以增强其在Kubernetes 上部署的可靠性、可观察性和安全性。例如，增强的可观察性可以帮助用户解决服务之间的延迟问题。使用Linkerd 不需要用户进行许多代码调整或花费大量时间编写YAML 配置文件。可靠的产品功能和积极的开发人员反馈使Linkerd 成为服务网格中的强大竞争对手。
Consul ConnectConsul Connect 是HashiCorp 的一个服务网格，专注于路由和分段，通过应用程序级sidecar 代理提供服务间网络功能。 Consult Connect 专注于应用程序安全性，在应用程序之间提供双向TLS 连接以进行授权和加密。
Consult Connect 的独特之处在于它提供两种代理模式。一是它内置的代理，而且还支持Envoy 解决方案。 Connect强调可观察性，并集成了Prometheus等工具来监控来自sidecar代理的数据。 Consul Connect可以灵活满足开发者的需求。例如，它提供了多种注册服务的方式：从编排系统、通过配置文件、通过API调用或通过命令行工具。
KumaKuma 来自Kong，声称是一个非常有用的服务网格替代方案。 Kuma 是一个基于Envoy 的平台无关的控制平面。 Kuma 提供安全、观察和路由等网络功能，同时增强服务之间的连接性。 Kuma 同时支持Kubernetes 和虚拟机。
Kuma 的有趣之处在于，其企业版可以通过统一的控制面板来操作和管理多个隔离的服务网格。该能力可以满足安全性要求较高的使用场景。既满足隔离的要求，又实现集中控制。
Kuma 也是一个相对容易安装的解决方案。因为它有很多预先构建的策略。这些策略涵盖了路由、双向TLS、故障注入、流量控制、加密和其他场景等常见需求。
Kuma 与Kong 原生兼容，使其成为已经采用Kong API 管理的企业组织的自然候选者。
MaeshMaesh 是Containous 的一个容器原生服务网格，它自称是比市场上其他服务网格更轻、更易于使用的解决方案。与许多基于Envoy 构建的服务网格不同，Maesh 使用Traefik，一种开源反向代理和负载均衡器。
Maesh不使用sidecar代理，而是在每个节点上部署一个代理终端。这样做的好处是不需要编辑Kubernetes 对象，并且允许用户有选择地修改流量。 Maesh 比其他服务网格的侵入性更小。 Maesh支持的配置方式：在用户服务对象上添加注解或者在服务网格对象上添加注解来实现配置。
事实上，SMI是一种新的服务网格规范格式，对SMI的支持是Maesh独有的一大亮点。随着SMI在业界逐渐采用，它可以提高可扩展性并减轻供应商锁定的担忧。
Maesh 需要Kubernetes 1.11 或以上版本，并且集群中安装了CoreDNS/KubeDNS。本安装指南演示了如何通过Helm v3 快速安装Maesh。
helmrepoaddmaeshhttps://containous.github.io/maesh/chartshelmrepoupdatehelminstallmaeshmaesh/maeshServiceComb-mesherApache 软件基金会将其ServiceComb-mesher 描述为“用Go 语言实现的高性能服务网格”。 Mesher是基于Go Chassis这个非常流行的Go语言微服务开发框架来设计和实现的。因此，它继承了Go Chassis的一些特性，如服务发现、负载均衡、容错、路由管理、分布式追踪等。
Mesher 使用sidecar 方法；每个服务都有一个Mesher sidecar 代理。开发人员通过管理API 与Mesher 交互以查看运行时信息。 Mesher同时支持HTTP和gRPC，可以快速移植到不同的基础设施环境，包括Docker、Kubernetes、虚拟机和裸机环境。
Network Service Mesh(NSM)网络服务网格（NSM）是专门为电信公司和ISP设计的服务网格。它提供了一个层来增强Kubernetes 中服务的低级网络功能。 NSM目前是CNCF的一个沙箱项目。
根据NSM 的文档，“经常使用L2/L3 层的网络运营商抱怨说，很少有容器网络解决方案适合他们的下一代架构。”
因此，NSM在设计时考虑了一些不同的使用场景，特别是具有不同网络协议和混合网络配置的场景。这使得NSM 对于某些特殊场景非常有吸引力，例如边缘计算、5G 网络和物联网设备。 NSM使用简单直接的API接口来实现容器与外部端点之间的通信。
与其他服务网格相比，NSM 工作在不同的网络层。 VMware 将NSM 描述为“专注于连接”。 GitHub 的文档演示了NSM 如何与Envoy 配合使用。
AWS App MeshAWS APP Mesh 为开发者提供了“不同服务的应用层的联网”。它接管服务的所有网络流量，并使用开源Envoy 代理来控制进出容器的流量。 AWS App Mesh 支持HTTP/2 gRPC。
对于将容器平台与AWS 深度集成的公司来说，AWS App Mesh 将是一个非常好的服务网格解决方案。 AWS 平台包括AWS Fargate、Amazon Elastic Container Service、Amazon Elastic Kubernetes Service (EKS)、Amazon Elastic Compute Cloud (EC2)、EC2 上的Kubernetes，包括AWS App Mesh，无需额外付费。
AWS App Mesh 与AWS 生态系统内的监控工具无缝兼容。这些工具包括CloudWatch 和AWS X-Ray，以及来自第三方供应商的一些工具。由于AWS 计算服务支持AWS Outposts，因此AWS App Mesh 可以很好地与混合云和已部署的应用程序配合使用。
AWS App Mesh 的缺点可能是它让开发人员深深束缚于单一供应商解决方案，该解决方案相对闭源且缺乏可扩展性。
OpenShift Service Mesh by Red HatOpenShift 是红帽的容器管理平台，可帮助用户“连接、管理和观察微服务应用程序”。 OpenShift预装了许多增强企业能力的组件，也被描述为企业级混合云Kubernetes平台。
OpenShift Service Mesh 基于开源Istio 构建，具有Isito 的控制平面和数据平面功能。 OpenShift 利用两个开源工具来增强Isito 的跟踪功能和可观察性。 OpenShift 使用Jaeger 实现分布式跟踪，以更好地跟踪服务之间请求的处理方式。
OpenShift则使用Kiali来增强微服务配置、流量监控、跟踪分析等方面的可观察性。
如何选择
正如文章中提到的，有很多服务网格解决方案可供选择，并且新的解决方案不断涌现。当然，每种解决方案的技术实现都略有不同。选择合适的服务网格时，要考虑的主要因素包括您可以接受它的侵入性、安全性以及平台的成熟度。
以下几点可以帮助DevOps团队选择适合其场景的服务网格：
是否依赖Envoy。Envoy 拥有活跃的社区生态系统。开源和许多服务网格的基础。 Envoy 丰富的功能使其成为难以绕过的因素。具体使用场景。服务网格为微服务而生。如果您的应用程序是一个庞大的庞然大物，那么您对服务网格的投资可能无法实现预期的收益。如果并非所有应用程序都部署在Kubernetes 上，则应优先考虑与平台无关的解决方案。现有容器管理平台。一些企业已经使用特定供应商的生态系统来解决容器编排问题，例如AWS的EKS、红帽的OpenShift、Consul。遵循原生态，才能继承和拓展原有的特色。开源解决方案可能无法提供这些。所在行业。许多服务网格并不是为特定行业设计的。 Kuma 统一管理多个隔离服务网格的能力可能更适用于监管严格的金融行业。底层网络电信公司和ISP 应考虑网络服务网格。对可视化的要求。可观测性是服务网格的核心能力之一。考虑进一步定制和更深层次功能的团队应优先考虑Istio 或Consul。是否遵循开发标准。遵循开发标准使您的平台更具前瞻性和可扩展性。这使得公司倾向于采用支持SMI、Maesh 或Linkerd 等其他基金会孵化项目的解决方案。是否重视用户体验。考虑运维人员的易用性是评判新工具的关键指标。 Linkerd 在开发者中似乎享有良好的声誉。团队准备。评估自己团队的资源和技术储备，在技术选择时决定自己是否适合使用基于Envoy的Istio或者供应商的抽象封装方案，例如OpenShift。这些注意事项并未涵盖所有场景。这只是一个介绍，供读者思考。希望在阅读上面列出的服务网格清单和相关决策因素后，您的团队将找到改进微服务应用程序网络特性的新方法。
好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/7319.html
用户评论
这篇文章挺棒的！我一直想了解一下服务网格，这篇文章给了我很多参考。
有6位网友表示赞同！
终于有人对这些开源的服务网格做了比较，太实用了！
有8位网友表示赞同！
之前没接触过服务网格，看完这篇比较觉得它很强大啊，能让我更灵活地管理微服务
有15位网友表示赞同！
好多我没听说过的服务网格，真是开眼界！现在去研究一下哪个适合我吧。
有15位网友表示赞同！
这篇文章讲得很清楚，对每个服务网格都做了详细的介绍。
有18位网友表示赞同！
看了标题就感觉很实用，可以让我快速了解不同服务的优缺点
有18位网友表示赞同！
在选用服务网格的时候，最注重安全性，这篇比较是不是也考虑了这个方面？
有12位网友表示赞同！
我正在学习微服务架构，这篇文章正好能帮助我理解如何使用服务网格。
有20位网友表示赞同！
希望这篇文章也能介绍一下部署和维护这些服务网格的复杂度。
有19位网友表示赞同！
这个文章里提到的开源服务网格都是免费的吗？
有14位网友表示赞同！
我最关心的还是性能，哪个服务网格对延迟要求最低呢？
有18位网友表示赞同！
这种比较方便我做评估，省去自己一个个去研究的时间。
有20位网友表示赞同！
文章有没有提到这些开源服务网格的社区活跃情况？
有12位网友表示赞同！
选用哪种服务网格，要考虑很多因素啊，这篇文章能帮我明确一些方向。
有14位网友表示赞同！
学习东西最好的方式就是对比，这篇比较让我更直观地了解不同服务网格之间的差异。
有6位网友表示赞同！
我的项目需要频繁更新，哪个服务网格更加灵活呢？
有13位网友表示赞同！
我平时习惯使用Linux系统，这篇文章有没有介绍哪些开源服务网格和Linux兼容性好？
有15位网友表示赞同！
希望文章能提供一些案例，让读者更加了解这些服务网格的应用场景。
有19位网友表示赞同！
期待后续更新的文章，可以深入一些具体的技术细节。
有6位网友表示赞同！