在过去的几年里，服务网格（Service Mesh）技术取得了长足的进步。服务网格在不同组织采用云本地的过程中扮演着重要的角色。通过提供连接性、可靠性、可观察性和安全性这四种主要类型的功能，服务网格已经成为 IT 组织的技术和基础设施现代化工作的核心组件。服务网格使开发和运维团队能够在基础设施级别实现这些功能，因此在涉及到非功能需求切面时，应用程序团队不需要付出重复性劳动。
自本文第一版于 2020 年 2 月发表以来，服务网格技术经历了重大创新，并出现了一些新的架构趋势、技术能力，在不断发展的服务网格领域也不断涌现出新的服务网格项目。
在过去的一年里，服务网格产品的发展已经远远超过了 Kubernetes-only 解决方案，之前那些不在 Kubernetes 平台上托管的应用无法利用服务网格。并不是所有的组织都将他们的业务和 IT 应用程序转移到 Kubernetes 云平台。因此，自服务网格诞生以来，这种技术就需要能够应用于不同的 IT 基础设施环境中。
随着微服务架构的日益普及，应用系统在云提供商、基础设施(Kubernetes、虚拟机、裸机服务器)、地理位置，甚至在服务网格集成环境中管理的工作负载类型等方面都已变得松耦合和分布式。
让我们先来回顾一下服务网格是如何诞生的。
2016 年前后，“服务网格”一词出现在微服务、云计算和 DevOps 领域。2016 年，Buoyant 团队用这个词来解释他们的产品 Linkerd。与计算机的许多概念一样，相关的模式和技术实际上有很长的历史。
服务网格的到来很大程度上是由于 IT 领域的一场完美风暴。开发人员开始使用多语言方法构建分布式系统，并需要动态的服务发现。运营开始使用临时基础设施，并希望可以优雅地处理那些不可避免的通信故障，以及实施网络策略。平台团队开始采用 Kubernetes 之类的容器编排系统，并希望使用现代 API 驱动的网络代理(如 Envoy)动态地将流量路由到系统内部或周围。
本文旨在回答针对软件架构师和技术领导者的相关问题，例如：什么是服务网格？我需要服务网吗？我如何评估不同的服务网供应？
您可以使用页面底部的导航目录来快速浏览本指南。
服务网格模式
服务网格模式专注于管理分布式软件系统中服务到服务的所有通信。
上下文
该模式的上下文有两个方面：第一，工程师已经采用了微服务体系结构模式，并且正在通过组合多个(理想情况下是单一用途和独立部署的)服务来构建他们的应用程序。第二，组织已经接受了云原生平台技术，如容器(如 Docker)、协调器(如 Kubernetes)和网关。
意图
服务网格模式试图解决的问题包括：
无需将特定于语言的通信库编译为单个服务来处理服务发现、路由和应用程序级(第 7 层)非功能性通信需求。
外化服务通信配置，包括外部服务的网络位置、安全凭据和服务质量目标。
提供其他服务的被动和主动监视。
在分布式系统中分散政策的执行。
提供可观察性默认值并标准化相关数据的收集。
启用请求日志记录
配置分布式跟踪
收集度量指标
结构
服务网格模式主要关注处理传统上称为“东-西”的基于远程过程调用(RPC)的流量：即起源于数据中心内部，并在服务到服务之间传播的请求/响应类型的通信。这与 API 网关或边缘代理相反，API 网关或边缘代理的设计目的是处理“南-北”流量：即从外部发出并进入数据中心内端点或服务的通信。
服务网格的特性
一个服务网格实现通常会提供以下一个或多个特性：
规范命名并添加逻辑路由(例如，将代码级名称“user-service”映射到特定于平平台的位置“AWS-us-east-1a/prod/users/v4”)
提供通讯成形和通讯变换
维持负载平衡，通常使用可配置的算法
提供服务释放控制(例如，金丝雀发布和流量分割)
提供请求级路由(例如，流量跟踪、故障注入和调试重路由)
添加基线可靠性，如运行状况检查、超时/截止日期、电路断开和重试(预算)
通过透明的双向传输层安全(TLS)和访问控制列表(ACL)等策略提高安全性
提供额外的可观察性和监视性，例如顶级指标(请求量、成功率和延迟)、对分布式跟踪的支持，以及“tap”和检查实时服务到服务通信的能力
允许平台团队配置“稳健的默认值”，以保护系统不会受到不良通信的影响
服务网格功能可以分为以下四个方面：
连通性
可靠性
安全性
可观察性
让我们看看服务网格技术在这些领域中可以提供哪些特性。
连通性：
流量控制(路由、分割)
网关(入口、出口)
服务发现
A / B 测试，金丝雀
服务超时，重试
可靠性：
断路器
故障注入/混沌测试
安全性：
服务到服务的身份验证(MTL)
证书管理
用户身份验证(JWT)
用户授权(RBAC)
加密
可观测性：
监控
遥测、仪表、度量
分布式跟踪
服务图
服务网格架构：引擎盖下的秘密
服务网格由两个高层次组件组成：数据面板和控制面板。Envoy Proxy的创建者马特·克莱因(Matt Klein)对“服务网格数据面板与控制面板”的主题进行了非常深入的研究。
广义地说，数据面板“完成工作”，并负责“有条件地转换、转发和观察进出(网络端点)的每个网络数据包”。在现代系统中，数据面板通常被实现为代理(如 Envoy、HAProxy 或 MOSN)，它与每个服务一起作为“边车”在进程外运行。Linkerd 使用了一种针对服务网格边车用例进行优化的微代理方法。
控制面板“监督工作”，并获取数据面板的所有独立实例(一组孤立的无状态边车代理)，并将它们转换为分布式系统。控制面板不接触系统中的任何数据包/请求，但它允许运维人员为网格中所有运行的数据面板提供策略和配置。控制面板还可以收集和集中数据面板遥测数据，供运维人员使用。
控制面板和数据面板的结合提供了两方面的优势，因为可以集中定义和管理策略，同时可以在 Kubernetes 集群的每个 pod 中以分布式方式执行相同的策略。策略可以关联到安全、路由、断路器或监控。
下面的图表摘自 Istio 体系结构文档，尽管提到的技术是特定于 Istio 的，但组件对于所有服务网格实现都是通用的。
Istio 架构，演示了控制面板和代理数据面板如何交互(由Istio官方文档提供)
用例
服务网格可以启用或支持各种用例。
动态服务发现和路由
服务网格提供动态服务发现和流量管理，包括用于测试的流量镜像（traffic shadowing），以及用于金丝雀发布和 A/B 类型试验的流量切分。
在服务网格中使用的代理通常是“应用层”感知的(在 OSI 网络堆栈的第 7 层操作)。这意味着流量路由决策和指标的标记可以利用 HTTP 头或其他应用层协议元数据中的数据。
服务到服务的通信可靠性
服务网格支持横切如请求重试、超时、速率限制和断路等可靠性需求的实现和实施。服务网格通常用于针对分布式计算的八种谬误进行补偿(或封装)处理。需要注意的是，服务网格只能提供连接级的可靠性支持(比如重试 HTTP 请求)，最终应该由服务负责所有业务相关的影响，比如避免多个(非幂等的)HTTP POST 请求。
流量的可观测性
由于服务网格位于系统正在处理的每个请求的关键路径上，因此它还可以提供额外的“可观察性”，例如对请求的分布式跟踪、HTTP 错误码的频率以及全局和服务到服务的延迟。尽管这是一个在企业中被过度使用的词，但服务网格经常被提议作为一种捕获所有必要数据的方法，以实现整个系统内流量的“单窗格”视图。
通信安全
服务网格还支持横切安全需求的实现和实施，例如提供服务身份(通过 x509 证书)，支持应用程序级服务/网络分段(例如，“服务 A”可以与“服务 B”通信，而不是“服务 C”)，确保所有通信都是加密的(通过 TLS)，并确保持有有效的用户级身份令牌或“护照”。
反模式
反模式应用的出现，通常是技术成熟的标志。服务网格也不例外。
太多的流量管理层级(一路龟行)
如果开发人员没有与平台或运维团队协调流通，直接在代码中复制现有的通信处理逻辑(现在正在通过服务网格实现)，就会出现此反模式。例如，除了服务网格配置提供的线路级重试策略外，应用程序还在代码中实现重试策略。此反模式可能会导致重复事务等问题。
将服务网格视作银弹
在 IT 领域没有所谓的“银弹”，但供应商有时会忍不住给新技术贴上这个标签。服务网格不能解决微服务、Kubernetes 之类的容器协调器或云网络的所有通信问题。服务网格的目的只是促进服务到服务(东-西)的通信，部署和运行服务网格有明确的运维成本。
企业服务总线(ESB) 2.0
在前微服务面向服务体系结构(SOA)时代，企业服务总线(ESB)实现了软件组件之间的通信系统。有些人担心，在使用服务网格时，ESB 时代的许多错误会重复出现。
很显然，通过 ESB 提供的通信集中控制是有价值的。然而，这些技术的开发是由供应商驱动的，这导致了许多问题，例如：ESB 之间缺乏互操作性、行业标准的定制扩展(例如，将特定于供应商的配置添加到兼容 WS-*的模式中)和高成本。ESB 供应商未做什么去防止业务逻辑与通信总线的集成和紧密耦合。
大爆炸式部署
IT 界普遍存在一种诱惑，认为大规模部署方法是最容易管理的方法，但根据Accelerate和DevOps State报告的研究，情况并非如此。由于服务网格的全面推出意味着该技术处于处理所有终端用户请求的关键路径上，因此大爆炸部署风险很高。
死星架构
当组织采用微服务体系结构，开发团队开始创建新的微服务或在其应用程序中利用现有服务时，服务到服务的通信就成为体系结构的关键部分。如果没有良好的治理模型，这可能导致不同服务之间的紧密耦合。当整个系统在生产中出现问题时，这也很难确定哪个服务出现了问题。
缺乏服务通信策略和治理模型，该体系结构就变成了所谓的“死星架构”。
有关此体系结构反模式的更多信息，请参阅关于采用云本地体系结构的第1、2和3部分文章。
特定领域的服务网格
局部实现和过度优化服务网格有时会导致服务网格部署的范围过窄。开发人员可能更喜欢特定于他们自己业务领域的服务网格实例，但这种方法弊大于利。我们不想实现一个过于细粒度的服务网格范围，就像为组织中的每个业务或功能领域(例如，财务、人力资源、会计等)实现一个专用的服务网格。这与为企业级服务发现或跨域服务路由等功能使用公共服务编制解决方案(如服务网格)的目的不符。
服务网格的实现和产品
以下是当前服务网格实现的非详尽列表：
Linkerd(CNCF 毕业项目)
Kuma (CNCF 沙盒项目)
Traefik Mesh (formerly Maesh)
Open 服务网格 (CNCF 沙箱项目)
另外，DataDog等其他产品也开始提供与 Linkerd、Istio、Consul Connect 和 AWS App mesh 等服务网格技术的集成。
服务网格比较：选择哪款服务网格?
服务网格领域的发展速度非常快，因此尝试做出的任何比较可能很快都会过时。但尽管如此，还是有人做了一些比较。要注意比较之间存在的偏差(如果有的话)和比较时的日期。
https：//kubedex.com/istio-vs-linkerd-vs-linkerd2-vs-consul/ (截至 2021 年 8 月)
https：//platform9.com/blog/kubernetes-service-mesh-a-comparison-of-istio-linkerd-and-consul/(截至 2019 年 10 月)
https：//servicemesh.es/ (最近的发布是 2021 年 8 月)
服务网格采用者自己对每个产品进行审慎的调查和试验是 InfoQ 一直不变的建议。
服务网格教程
对于想要尝试多种服务网格的工程师或架构师来说，可以考虑以下教程、实训场和工具：
Layer 5 Meshery—一款多服务网格管理面板
Solo’s Gloo Mesh—一个服务网格编排平台
服务网格的历史
自 2013 年末 Airbnb 发布SmartStack以来，InfoQ 一直在跟进我们现在称之为服务网格的话题，SmartStack 为新兴的“微服务”风格架构提供了一种进程外服务发现机制(使用HAProxy)。在此之前，许多先前被称为“独角兽”的组织都在从事类似的技术。从 21 世纪初开始，谷歌就在开发它的Stubby RPC 框架，并发展成为gRPC，以及Google Frontend (GFE)和 Global Software Load Balancer (GSLB)，在Istio中可以看到这些特点。在 2010 年代早期，Twitter 开始开发基于 Scala 的Finagle， Linkerd服务网络由此诞生。
2014 年底，Netflix 发布了一整套基于JVM的实用程序，其中包括Prana，这是一个“边车”进程，允许用任何语言编写的应用程序服务通过 HTTP 与库的独立实例通信。2016 年，NGINX 团队开始讨论“Fabric模型”，它非常类似于服务网格，但需要使用他们的商业 NGINX Plus 产品来实现。此外，Linkerd v0.2 是在 2016 年 2 月发布的，尽管团队后来才开始称其为服务网格。
服务网格历史上的其他亮点包括 2017 年 5 月发布的Istio， 2018 年 7 月发布的Linkerd 2.0， 2018 年 11 月发布的Consul Connect和Gloo mesh， 2019 年 5 月发布的服务网格接口(SMI)，以及 2019 年 9 月发布的 Maesh(现在称为 Traefik mesh)和 Kuma。
即使是在独角兽之外出现的服务网格，如 HashiCorp 的Consul，也从上述技术中获得的灵感，通常旨在实现 CoreOS 创造的“GIFEE”概念；针对其他所有人的谷歌基础设施。
为了深入了解现代服务网格概念的发展历史，Phil Calçado写了一篇全面的文章“模式：服务网格”。
服务网格的标准
尽管服务网格技术在过去几年里经历了年复一年的重大变革，但服务网格的标准并没有跟上创新的步伐。
使用服务网格解决方案的主要标准是服务网格接口(SMI)。服务网格接口是 Kubernetes 上运行的服务网格的规范。它本身并没有实现服务网格，而是定义了一个可以由各种服务网格提供者实现的公共标准。
SMI API 的目标是提供一组公共的、可移植的服务网格 API， Kubernetes 用户可以以不可知的方式使用这些 API。通过这种方式，人们可以定义使用服务网格技术的应用程序，而无需与任何特定的实现紧密绑定。
SMI 基本上是 Kubernetes 自定义资源定义(CRD)和扩展 API 服务器的集合。这些 API 可以安装到任何 Kubernetes 集群上，并使用标准工具进行运维。要激活这些 API，需要在 Kubernetes 集群中运行 SMI provider 。
SMI 规范既允许终端用户的标准化，也允许服务网格技术提供商的创新。SMI 支持灵活性和互操作性，并涵盖了最常见的服务网格功能。当前的规范组件主要关注服务网格功能的连接性方面。API 规范包括以下内容：
流量访问控制
流量指标
流量规格
流量分割
当前的 SMI生态系统广泛包括 Istio， Linkerd， Consul Connect， Gloo mesh 等服务网格。
SMI 规范接受Apache License Version 2.0的许可。
如果您想了解更多关于 SMI 规范及其 API 的细节，请查看以下链接。
服务网格基准
服务网格性能是一个用于捕获基础设施容量、服务 Mesh 配置和工作负载元数据细节的标准。SMP 规范用于捕获以下细节：
环境和基础设施细节
节点的数量和大小，协调器
服务网格及其配置
工作负载/应用程序细节
描述性能的统计分析
来自 Linkerd 团队的 William Morgan写了一篇关于对 Linkerd 和 Istio 性能进行基准测试的文章。还有一篇 2019 年的文章是关于 Istio 对服务网格性能进行基准测试的最佳实践。
重点是要记住，就像任何其他性能基准一样，您不应该把太多的精力放在任何外部发布的文章上，特别是产品供应商发布的。您应该在服务器环境中设计并执行自己的性能测试，以验证哪些特定产品适合你的应用程序的业务和非功能性需求。
探索服务网格(可能)的未来
Kasun Indrasiri探讨了“使用服务网格进行事件驱动消息传递的潜力”，其中他讨论了在服务网格中实现消息传递支持的两种主要体系结构模式：协议代理边车和 HTTP 桥接边车。在服务网格社区中，这是一个活跃的开发领域，Envoy致力于支持Apache Kafka的努力吸引了相当多的关注。
Christian Posta 之前曾在“统一标准的服务网格API”中写过关于服务网格使用标准化的尝试。本文还讨论了 2019 年由微软和 KubeCon EU 合作伙伴宣布的服务网格接口(SMI)。SMI 定义了一组通用和可移植的 API，旨在为开发人员提供跨不同服务网格技术(包括 Istio、Linkerd 和 Consul Connect)的互操作性。
将服务网格与平台结构集成的主题可以进一步分为两个子主题。
第一个，正在进行的工作是减少由服务网格数据面板引入的网络开销。这包括数据面板开发工具包(DPDK)，它是一个用户空间应用程序，“绕过 Linux 内核网络堆栈的厚重层次，直接与网络硬件对话。”Cilium团队也有一个基于 Linux 的 BPF 解决方案，它在 Linux 内核中利用了扩展的伯克利包过滤(eBPF)功能，以实现“非常高效的网络、策略执行和负载平衡功能”。另一个团队正在用网络服务网格将服务网格的概念映射到 L2/L3 有效负载，试图“以云本地的方式重新想象网络功能虚拟化(NFV)”。
第二个，将服务网格与公共云平台更紧密地集成的多个举措，如AWS App Mesh、GCP Traffic Director和Azure service Fabric Mesh的引入。
Buoyant 团队正在为服务网格技术开发有效的以人为中心的控制面板。他们最近发布了 Buoyant Cloud，这是一款基于 saas 的“团队控制平台”，面向运维 Kubernetes 的平台团队。下面一节将对此产品进行更详细的讨论。
自去年以来，在服务网格领域也出现了一些创新。让我们来看看这些创新。
多云、多集群、多租户服务网格
近年来，不同组织对云的采用已经从单一的云解决方案(私有或公有)转变为基于多个不同供应商(AWS、谷歌、Microsoft Azure 等)支持的多云(私有、公有和混合)的新基础设施。此外，支持不同工作负载(事务性、批处理和流)的需求对于实现统一的云架构至关重要。
这些业务和非功能需求反过来又导致需要在异构基础设施(裸机、虚拟机和 Kubernetes)中部署服务网格解决方案。服务网格体系结构需要进行相应的转换，以支持这些不同的工作负载和基础设施。
[Kuma](http:// Buoyant Cloud)等技术支持多网格控制面板，使业务应用程序能够在多集群和多云服务网格环境中工作。这些解决方案抽象了跨多个区域的服务网格策略的同步以及跨这些区域的服务连接(和服务发现)。
多集群服务网格技术的另一个新兴趋势是需要从边缘计算层(物联网设备)到网格层的应用/服务连接。
媒体服务网格
由思科系统公司开发的媒体流网格或媒体服务网格，在 Kubernetes 云平台上使用服务网格技术，用于编排实时应用程序，如多人游戏、多方视频会议或 CCTV 流媒体。这些应用程序正越来越多地从单片应用程序转向微服务体系结构。服务网格可以通过提供负载平衡、加密和可观察性等功能来帮助应用程序。
混沌网格
混沌网格是一个由CNCF托管的项目，是一个用于 Kubernetes 托管应用程序的开源云原生混沌工程平台。虽然混沌网格不是一个直接的服务网格实现，但它通过将错误注入行为编排到应用程序中来实现混沌工程实验。故障注入是服务网格技术的关键功能之一。
混沌网格隐藏了底层的实现细节，因此应用程序开发人员可以专注于实际的混沌实验。混沌网格可以与服务网格一起使用。检出这个用例，看看团队是如何使用 Linkerd 和混沌来为他们的项目进行混沌实验的。
服务网格即服务
一些服务网格供应商，如 Buoyant，正在提供托管服务网格或“服务网格即服务”解决方案。今年早些时候，Buoyant发布了一个名为Buoyant Cloud的 SaaS 应用的公开测试版，该应用允许客户组织利用托管服务网格和 Linkerd 服务网格的随需支持特性。
Buoyant Cloud 解决方案提供的一些功能包括：
Linkerd 数据面板和控制面板健康的自动跟踪
管理 Kubernetes 平台上跨 pod、代理和集群的服务网格生命周期和版本
以 SRE 为重点的工具，包括服务水平目标(SLO)、工作负载黄金度量跟踪和变更跟踪
网络服务网格(NSM)，
网络服务网格(NSM)，另一个云本地计算基础沙箱项目，提供了一个混合的、多云的 IP 服务网格。NSM 支持诸如网络服务连接性、安全性和可观察性等功能，这些都是服务网格的核心特性。NSM 与现有的容器网络接口(CNI)实现一起工作。
服务网格扩展
服务网格扩展是另一个有很多创新的领域。近期服务网格扩展的发展包括：
增强的身份管理，以保护微服务连接，包括自定义证书颁发插件
自适应路由特性，以提高服务的可用性和可伸缩性
加强边车代理
服务网格运维
采用服务网格的另一个重要领域是服务网格生命周期的运维端。运维方面——比如配置多集群功能和将 Kubernetes 工作负载连接到虚拟机基础架构上的服务器，以及用于管理多集群服务网格安装中的所有特性和 API 的开发者门户，将在服务网格解决方案的总体部署和生产支持中发挥重要作用。
常见问题解答
什么是服务网格?
服务网格是一种管理分布式(潜在的基于微服务的)软件系统中所有服务到服务(东-西)流量的技术。它既提供以业务为中心的功能性操作(如路由)，也提供非功能性支持(如执行安全策略、服务质量和速率限制)。它通常(尽管不是唯一的)使用边车代理实现，所有服务都通过边车代理进行通信。
服务网格与 API 网关有何不同?
服务网格的有关定义，请参见上文。
另一方面，API 网关管理进入集群的所有入口(南-北)流量，并为跨功能通信需求提供额外支持。它充当进入系统的单一入口点，并允许多个 API 或服务内聚，向用户提供一致的体验。
如果我正在部署微服务，我是否需要服务网格?
不一定。服务网格增加了技术栈的运维复杂性，因此通常只在组织在扩展服务到服务通信方面遇到困难，或者有特定的用例需要解决时才部署。
我是否需要服务网格来实现微服务的服务发现?
不用。服务网格提供的是一种实现服务发现的方法。还有包括特定于语言的库(如 Ribbon 和 Eureka 或 Finagle)的其他解决方案。
服务网格是否增加了服务到服务通信的开销/延迟?
是的，当服务与另一个服务通信时，服务网格至少会增加两个额外的网络跳数(第一个是来自处理源出站连接的代理，第二个是来自处理目的地入站连接的代理)。但是，这种额外的网络跳通常发生在本地主机或环回网络接口上，并且只增加少量延迟(量级为毫秒)。对服务网格进行分析和评估时，应试验和理解这对于目标用例来说是否构成问题。
服务网格不应该是 Kubernetes 或部署应用程序的“云本地平台”的一部分吧?
很可能。对于在云本地平台组件中保持关注点分离(例如，Kubernetes 负责提供容器编排，而服务网格负责服务到服务的通信)存在争议。然而，将服务网状功能推进到现代的平台即服务(PaaS)产品中的工作正在进行中。
如何实现、部署或推出服务网格?
最好的方法是分析各种服务网格产品(见上文)，并遵循特定于所选网格的实现指南。一般来说，最好是与所有涉众一起协作，并将所有新技术逐步部署到生产中。
我可以建立自己的服务网格吗?
当然，但更重要的问题是，你应该这样做吗?建立服务网是您组织的核心竞争力吗?你能否以更有效的方式为客户提供价值?您是否也致力于维护自己的网格，为安全问题打补丁，并不断更新它以利用新技术?随着开放源码和商业服务网格产品的出现，使用现有的解决方案可能会更有效。
在软件交付组织中，哪个团队拥有服务网格?
通常情况下，平台或运营团队拥有服务网格，以及 Kubernetes 和连续交付管道基础设施。然而，将由开发人员配置服务网格参数，因此两个团队应该紧密合作。许多组织都在效仿云计算先锋，如 Netflix、Spotify 和谷歌，并创建内部平台团队，为全周期产品开发团队提供工具和服务。
Envoy 是服务网格吗?
不。Envoy 是一个云原生代理，最初是由 Lyft 团队设计和构建的。Envoy 通常被用作使用服务网格的数据面板。然而，为了被认为是服务网格，Envoy 必须与一个控制面板结合使用，以使这一系列技术成为服务网格。控制面板可以像集中式配置文件存储库和度量收集器那样简单，也可以像 Istio 那样全面/复杂。
“Istio”和“服务网格”可以互换使用吗?
不行。Istio 是一种服务网格。由于 Istio 的流行，当服务网格类别出现时，一些地方会把 Istio 和服务网格相提并论。这种问题并不是服务网格所独有的，Docker 和容器技术也面临同样的挑战。
我应该使用哪种服务网格?
这个问题没有唯一解。工程师必须了解他们当前的需求，以及他们的实现团队可用的技能、资源和时间。你可以先看看上面所列的服务网格比较链接，它们是你开启探索的一个良好的起点，但我们强烈建议组织至少试验两个网格，以便了解哪些产品、技术和工作流最适合他们。
我可以使用 Kubernetes 之外的服务网格吗?
当然。许多服务网格允许在各种基础设施上安装和管理数据面板代理和相关的控制面板。最著名的例子是HashiCorp的Consul，Istio 也被用于 Cloud Foundry。
额外的资源
术语表
API 网关：管理进入集群的所有入口(南-北)流量，并为跨功能通信需求提供额外支持。它充当进入系统的单一入口点，并允许多个 API 或服务内聚并向用户提供统一的体验。
Consul： HashiCorp 的基于 Go 的服务网格。
容器化：容器是一个标准的软件单元，它将代码及其所有依赖项打包，以便在一个计算环境运行的应用程序快速可靠地到另一个环境中运行。
控制面板：获取数据面板(代理)的所有单独实例，并将它们转换为一个可由运维人员可视化和控制的分布式系统。
断路器：处理连接到远程服务时的故障或超时。有助于提高应用程序的稳定性和弹性。
数据面板：一个代理，有条件地转换、转发和观察每个来自服务网络端点的网络数据包。
Docker： Docker 容器映像是一个轻量级的、独立的、可执行的软件包，包含了运行应用程序所需的所有东西：代码、运行环境、系统工具、系统库和设置。
东-西流量：数据中心、网络或 Kubernetes 集群内的网络流量。传统的网络图是由服务到服务(数据中心间)流量从左到右(东到西)绘制的。
Envoy Proxy：开源边缘和服务代理，专为云本地应用设计。Envoy 通常用作服务网格实现中的数据面板。
入口流量：来自数据中心、网络或 Kubernetes 集群外部的网络流量。
Istio：基于 c++(数据面板)和 Go(控制面板)的服务网格，最初由谷歌和 IBM 与 Lyft 的 Envoy 团队合作创建。
Kubernetes：起源于谷歌的由 cncf 托管的容器编排和调度框架。
Kuma：一款来自于 Kong 的基于 Go 的服务网格。
Linkerd：一个由 Rust(数据面板)和 Go(控制面板)驱动的服务网格，源自 Twitter 早期基于 jvm 的通信框架。
Maesh： A Go-based 服务网格 from Containous， the maintainers of the Traefik API gateway.
Maesh：来自 Containous 的基于 go 的服务网格，它是 Traefik API 网关的维护者。
MOSN：蚂蚁金服团队的基于 Go 的代理，实现了(Envoy) xDS API。
南-北流量：进入数据中心、网络或 Kubernetes 集群的网络流量。传统的网络图是这样绘制的：入口流量由页面的顶部进入数据中心，然后向下(从北到南)进入网络。
代理：在端点组件之间充当中介的软件系统。
分段：将一个网络或集群划分为多个子网络。
服务网格：管理分布式(潜在的基于微服务的)软件系统中所有服务到服务(东-西)的流量。它既提供功能性操作(如路由)，也提供非功能性支持(如执行安全策略、服务质量和速率限制)。
服务网格接口(SMI)：部署到 Kubernetes 上的服务网格的标准接口。
服务网格策略：一个关于一组服务/端点如何相互之间以及如何与其他网络端点通信的规范。
边车： 一种部署模式，在这种模式中，附加的流程、服务或容器与现有的服务一起部署(想象一下摩托车的跨斗)。
Single pane of glass：一个 UI 或管理控制台，在一个统一的视图中显示来自于多个来源的数据。
流量整形：修改网络中的流量，如限速、减载等。
流量迁移：将流量从一个位置迁移到另一个位置。
流量分割：允许用户在各种服务之间增量地分配流量百分比。由客户端(如入口控制器或服务网格边车)使用，将出站流量分割到不同的目的地。
现代软件架构师的角色在不断变化。订阅 InfoQ 的《软件架构师通讯》吧，保持在时代的前沿。
作者简介：
Srini Penchikala 是德克萨斯州奥斯汀市的一位高级 IT 架构师。他在软件架构、设计和开发方面有超过 25 年的经验，目前专注于云本地架构、微服务和服务网格、云数据管道和持续交付。Penchikala 编写了《使用 Apache Spark 进行大数据处理》，并参与编写了 Manning 的《Spring Roo in Action》。他经常在大会上发表演讲，是一名大数据培训师，并在各种技术网站上发表过一些文章。
原文链接：
Service Mesh Ultimate Guide - Second Edition: Next Generation Microservices Development
译者简介： 冬雨，小小技术宅一枚，从事研发过程改进及质量改进方面的工作，关注编程、软件工程、敏捷、DevOps、云计算等领域，非常乐意将国外新鲜的 IT 资讯和深度技术文章翻译分享给大家，已翻译出版《深入敏捷测试》、《持续交付实战》。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论 2 条评论