大约翻译：本文的作者（Luc Perkins）是CNCF的开发者，是Linkerd，SMI（服务网格接口）和Kuma等开源项目的所在地（顺便说一句，您是否还想知道为什么Istio不在此列表中？）。 ）。为了更好地理解DevOps社区对时髦的炒作“服务网格”的另一种尝试，他列举了此类解决方案提供的16种特性。服务网格是
当今软件工程中最热门的主题之一（理所当然的！）。我发现这项技术非常有前途，我的梦想是见证它的广泛采用（当然，在有意义的时候）。但是，对于大多数人来说，它仍然笼罩着神秘的光环。而且，即使那些熟悉它，通常很难阐明它的优点以及它的确切含义（包括谦卑的仆人）。在本文中，我将尝试列出使用“服务网格” *的各种方案来纠正这种情况。
*约 transl。：在本文中以及本文的更深处，这是翻译（“服务网格”）将用于新的术语“服务网格”。
但是首先，我想发表一些评论：
- , . , service mesh Twitter 2015 ( « ») Linkerd, - .
- — . , , .
- 同时，并非每个现有的服务网格实现都支持所有这些用例。因此，我的“服务网格可以...”这样的表达应理解为“单独的，并且可能所有流行的服务网格实现都可以...”。
- 示例的顺序无关紧要。
入围名单：
- 服务发现；
- 加密;
- 认证和授权；
- 负载均衡;
- 断路;
- 自动缩放
- 金丝雀部署；
- 蓝绿色部署；
- 健康检查;
- 减载;
- 流量镜像；
- 绝缘;
- 限速，重试和超时；
- 遥测;
- 审计;
- 可视化。
1.服务发现
TL； DR：使用简单名称连接到网络上的其他服务。
服务应该能够通过适当的名称（例如
service.api.production，pets/staging或）自动彼此“发现” cassandra。云环境具有弹性，一个名称可以隐藏服务的多个实例。显然，在这种情况下，实际上不可能对所有IP地址进行硬编码。
另外，当一个服务找到另一个服务时，它应该能够向该服务发送请求，而不必担心它们会在其空闲实例的入口处终止。换句话说，服务网格必须监视所有服务实例的运行状况，并使主机列表保持最新。
每个服务网格都以不同的方式实现服务发现机制。目前，最常见的方法是委派给外部进程，例如DNS Kubernetes。过去，在Twitter上，我们为此使用Finagle命名系统。另外，服务网格技术使自定义命名机制的出现成为可能（尽管我还没有遇到任何具有此功能的SM实现）。
2.加密
TL； DR：摆脱服务之间的未加密流量，并使流程自动化和可扩展。
很高兴知道攻击者无法渗透您的内部网络。防火墙在这方面做得很好。但是，如果黑客进入内部会发生什么？他可以对服务内流量做他想做的事吗？希望它不会发生。为防止出现这种情况，您应该实现一个零信任网络，其中服务之间的所有流量都经过加密。大多数现代服务网格都是通过相互TLS来实现的。（相互TLS，mTLS）。在某些情况下，mTLS可在整个云和群集中工作（我认为有一天将以相似的方式安排行星际通信）。
当然，对于mTLS，服务网格是可选的。每个服务都可以使用自己的TLS，但这意味着必须找到一种方法来生成证书，在服务主机之间分发证书，在应用程序中包含从文件中加载这些证书的代码。是的，还请记住要定期更新这些证书。服务网格与像系统自动化MTLS SPIFFE，这又自动发出和旋转证书的进程。
3.认证和授权
TL； DR：确定谁发起了请求并确定在请求到达服务之前允许他们执行的操作。
服务常常想知道谁是作出请求（认证），并利用这些信息，决定什么样的主题是允许这样做（授权）。在这种情况下，代词“谁”可以隐藏：
- 其他服务。这称为“对等身份验证”。例如，服务
web要访问服务db。服务网格通常使用mTLS解决这些问题：在这种情况下，证书充当必需的标识符。 - -. « ». ,
haxor69. , , JSON Web Tokens.
. ,users, ,permissions.. service mesh , .
确定请求的来源之后，我们需要确定允许该主题执行的操作。某些服务网格允许您将基线策略（谁可以做什么）定义为YAML文件或在命令行上，而其他服务网格则提供与Open Policy Agent之类的框架的集成。最终目标是确保您的服务接受任何请求，并假设它们来自可靠的来源并且可以采取措施，因此可以安全地接受它们。
4.负载均衡
TL； DR：根据特定模式在服务实例之间分配负载。
服务分支中的“服务”通常由许多相同的实例组成。例如，今天的服务
cache包括5个副本，明天的数量可能增加到11个。定向到的请求cache应根据特定目的进行分发。例如，最小化等待时间或最大化进入正常实例的可能性。最常用的轮询算法（Round-robin），但还有许多其他算法-例如，加权（加权）请求（可以选择首选目标），环形（环）请求的方法散列（对上游主机使用一致的散列）或最少请求方法（首选请求最少的实例）。
传统的负载均衡器还具有其他功能，例如HTTP缓存和DDoS保护，但它们与东西向流量（即，数据中心内的流量-大约为Transl。）的关系不大（通常使用服务网格）。当然，不必使用服务网格来进行负载平衡，但是它允许您从集中式管理层为每个服务定义和控制平衡策略，从而无需启动和配置网络堆栈中的各个平衡器。
5.断路
TL； DR：在最坏的情况下，停止向有问题的服务的流量并控制损坏。
如果由于某种原因服务无法处理流量，则服务网格提供了几种解决此问题的选项（其他将在相应部分中讨论）。断路是断开服务与流量的最严重方法。但是，它本身没有任何意义-您需要备份计划。可以提供反压（背压）的服务查询（只是不要忘记设置您的服务网为！），或者，例如，在红色和重定向用户页面的状态染色页面的另一个版本的“落鲸»（«微博已关闭”）。
服务网格不仅仅可以确定何时以及将发生什么。在这种情况下，“何时”可以包括指定参数的任意组合：特定时间段内的请求总数，并行连接数，挂起的请求数，活动的重试次数等。
您可能不想滥用电路断路器，但是很高兴知道有应急计划。
6.自动缩放
TL； DR：根据指定的标准增加或减少服务实例的数量。
服务网格是不是调度，这样他们就不会扩展出来自己。但是，他们可以根据计划者的决策来提供信息。由于服务网格可以访问服务之间的所有流量，因此它们拥有大量有关正在发生的事情的信息：哪些服务遇到问题，哪些服务负载很弱（分配的容量被浪费了）等等。
例如，Kubernetes根据Pod的CPU和内存使用量扩展服务（请参阅我们的演讲“ Kubernetes中的自动扩展和资源管理”-大约翻译）。，但是如果您决定根据任何其他指标（在我们的示例中，与流量相关）进行扩展，则需要一个特殊的指标。一个教程这样的展示了如何用做特使，Istio，和普罗米修斯，但这个过程本身是很复杂的。我们希望服务网格通过简单地允许诸如“
auth如果待处理请求的数量超过阈值一分钟，增加服务实例的数量”之类的条件来简化它。
7.金丝雀部署
TL； DR：在部分用户上试用新功能或服务版本。
假设您正在开发SaaS产品，并打算推出一个很酷的新版本。您在分阶段进行了测试，效果很好。但是，仍然有人担心她在真实情况下的行为。换句话说，需要在真实任务上测试新版本，而不会冒用户信心的风险。 Canary部署对此非常有用。它们使您可以向一部分用户演示新功能。该子集可能是最忠实的用户，或者是使用该产品的免费版本的用户，或者是那些渴望成为豚鼠的用户。
服务网格通过允许您指定确定谁看到您的应用程序版本的条件并相应地路由流量来实现此目的。同时，服务本身没有任何变化。该服务的1.0版认为所有请求都来自应该看到它的用户，而1.1版对其用户则假定相同。同时，您可以更改旧版本与新版本之间的流量百分比，将稳定增长的用户重定向到新版本，前提是该版本稳定运行并且您的“实验”版本可以通过。
8.蓝绿色部署
TL; DR：推出炫酷的新功能，但准备立即将所有内容放回原处。
点蓝绿色的部署是平行于旧的绿色的运行它推出一个新的蓝色服务。如果一切顺利，并且新服务证明得很好，则可以逐渐关闭旧服务。 （可惜，有一天，这项新的“蓝色”服务将重复“绿色”服务的命运并消失……）蓝绿色部署与金丝雀部署不同，因为新功能一次覆盖了所有用户（而不仅仅是一部分）；关键是要准备一个“备用港”，以防万一出问题。
服务网格提供了一种非常方便的方法来测试蓝色服务，并在出现问题时立即切换为可运行的绿色。更不用说他们沿途提供了大量有关“蓝色”工作的信息（请参阅下面的“遥测”项），这有助于了解他是否准备进行全面的剥削。
大约 翻译 ：了解更多关于在Kubernetes不同的部署策略（包括上述金丝雀，蓝/绿等）在这篇文章。
9.健康检查
TL； DR：跟踪哪些服务实例已启动，并对不再需要的实例做出反应。
一个健康检查帮助您决定服务实例是否已经准备好接收和处理流量。例如，在使用HTTP服务的情况下，运行状况检查可能看起来像是对端点的GET请求
/health。答案200 OK将意味着该实例是健康的，或者其他情况良好-它尚未准备好接收流量。服务网格允许您指定检查运行状况的方式以及执行此检查的频率。然后，此信息可用于其他目的，例如负载平衡和电路中断。
因此，运行状况检查不是独立的用例，而是通常用于实现其他目标。另外，根据运行状况检查的结果，可能需要外部（相对于服务网格的其他目标）操作：例如，刷新状态页面，在GitHub上创建问题或填写JIRA票证。服务网格提供了方便的机制来自动化所有这些。
10.减载
TL； DR：重定向流量以响应使用量的临时高峰。
如果某项服务的流量过载，则可以暂时将某些流量重定向到另一个位置（即“转储”，“丢弃”在那里）。例如，备份服务或数据中心，或永久性Pulsar主题。结果，该服务将继续处理部分请求，而不会崩溃并完全停止处理所有内容。抛弃负载比断开电路更好，但是仍然不希望过度使用它。它有助于防止导致下游服务崩溃的级联故障。
11.流量并行化/镜像
TL； DR：一次将一个请求发送到多个位置。
有时有必要一次向多个服务发送一个请求（或一些请求样本）。一个典型的示例是将部分生产流量发送到登台服务。主生产Web服务器
products.production仅向下游服务发送请求。服务网格会智能地复制此请求，并将其发送到products.stagingWeb服务器甚至不知道的。
可以在流量并行化之上实现的另一个相关服务网格用例是回归测试... 它涉及将相同的请求发送到服务的不同版本，并检查所有版本的行为是否相同。我还没有遇到带有像Diffy这样的集成回归测试系统的服务网格实现，但是这个想法似乎很有希望。
12.绝缘层
TL； DR：将您的服务网格划分为微型网格。隔离
又称为分段，是一种将服务网格划分为逻辑上互不相关的分段的技术。隔离有点像创建虚拟专用网络。根本的区别是您仍可以充分利用服务网格（例如服务发现），但具有更高的安全性。例如，如果攻击者设法渗透了其中一个子网上的服务，则他将无法查看哪些服务正在其他子网上运行或拦截其流量。
另外，好处可以是组织性的。您可能希望根据组织的结构对服务进行子网划分，从而减轻开发人员的负担，使他们牢记整个服务网格。
13.速率限制，重试和超时
TL; DR：不再需要在代码库中包含管理请求的紧迫任务。
所有这些东西都可以看作是单独的用例，但由于一个共同点，我决定将它们组合在一起：它们接管了通常由应用程序库处理的请求生命周期的管理任务。如果您正在开发Ruby on Rails Web服务器（未与服务网格集成），该服务器通过gRPC向后端服务发出请求，应用程序将必须决定如果N个请求失败，该怎么办。您还必须找出这些服务可以使用特殊的库处理和硬编码这些参数的流量。另外，应用程序将必须决定何时放弃并让请求变坏（通过超时）。为了更改以上任何参数，必须停止，重新配置和重新启动Web服务器。
将这些任务转移到服务网格不仅意味着服务开发人员无需考虑这些任务，而且可以以更全球化的方式查看它们。如果使用复杂的服务链，例如A-> B-> C-> D-> E，则必须考虑请求的整个生命周期。如果任务是延长服务C中的超时，则逻辑上一次而不是部分地执行所有操作是合乎逻辑的：通过更新服务代码并等待请求请求被接受，CI系统将部署更新的服务。
14.遥测
TL; DR：从服务中收集所有必要的（不是完全）信息。
遥测是一个通用术语，包括度量，分布式跟踪和日志记录。服务网格提供了用于收集和处理所有三种类型的数据的机制。因为有太多可用的选项，所以事情变得有些模糊。要收集指标，可以使用Prometheus和其他工具，可以使用fluentd，Loki，Vector等收集日志（例如，带有我们用于K8s的日志库的ClickHouse-大约翻译）。对于分布式跟踪，可以使用Jaeger等等 每个服务网格可能支持某些工具，而不支持其他工具。奇怪的是，“开放遥测”项目是否可以提供某种融合。
在这种情况下，服务网格技术的优势在于，从理论上来说，边车集装箱可以从其服务中收集所有上述数据。换句话说，您可以使用统一的遥测收集系统，并且服务网格可以以各种方式处理所有这些信息。例如：
- CLI中某个服务的tail日志；
- 跟踪来自服务网格仪表板的请求量；
- 收集分布式跟踪并将其重定向到Jaeger之类的系统。
注意，主观判断：一般来说，遥测是不希望服务网格强烈干扰的区域。收集基本信息并实时跟踪某些“黄金指标”（如成功率和延迟）很好，但是我们希望我们看不到科学怪人堆栈的出现，这些堆栈试图替换专用系统，其中一些已经证明自己非常出色。并经过充分研究。
15.审核
TL; DR：那些忘记历史教训的人注定要重蹈覆辙。
审计是观察系统中重要事件的艺术。在服务网格的情况下，这可能意味着跟踪谁向某些服务的特定端点发出请求，或者跟踪上个月发生了多少次安全事件。
显然，审计与遥测密切相关。区别在于遥测通常与性能和技术正确性相关，而审计可能与法律和其他超出严格技术范围的问题（例如，符合GDPR要求-通用欧盟法规）相关用于数据保护）。
16.可视化
TL; DR：React.js万岁-精美界面的不竭来源。
也许有一个更好的词，但我不知道。我只是指服务网格或其某些组件的图形表示。这些可视化可以包括指标，例如平均等待时间，边车配置信息，运行状况检查结果和警报。
在面向服务的环境中工作要比“独石His下”承担更高的认知负担。因此，应不惜一切代价降低认知压力。具有单击按钮并获得所需结果的能力的服务网格的简单图形界面对于该技术的普及至关重要。
不包含在清单中
我最初打算在列表中包括更多用例，但后来决定不这样做。这些以及我做出决定的原因：
- 多数据中心。在我看来，这不仅仅是用例，而是服务网格应用程序的狭窄而特定的领域或服务发现等功能集。
- 进出。这是一个相关领域，但是我（可能是人为地）将自己限制在东西向交通场景中。入口和出口值得单独发表。
结论
目前为止就这样了！同样，此列表是临时的，很可能是不完整的。如果您认为我缺少某些东西或对某些东西有误，请通过Twitter（@lucperkins）与我联系。请遵守礼节规则。
译者的PS
作为文章标题插图的基础，文章“什么是服务网格（以及何时使用一个服务网格）？“（由格雷戈里·麦金农（Gregory MacKinnon）提供。它显示了应用程序中的某些功能（绿色）如何移至服务网格，该服务网格在它们之间提供了互连（蓝色）。
另请参阅我们的博客：