笔记。 翻译。本文作者 Luc Perkins 是 CNCF 的开发者布道师，CNCF 旗下拥有 Linkerd、SMI（服务网格接口）和 Kuma 等开源项目（顺便问一句，你有没有想过为什么 Istio 没有出现在这份名单上？）。为了让 DevOps 社区更好地理解热门的“服务网格”概念，他列出了此类解决方案提供的 16 项关键功能。
今天 ——是软件工程领域最热门的话题之一（而且理所当然！）。我认为这项技术前景广阔，并梦想着看到它被广泛应用（当然，前提是时机成熟）。然而，对大多数人来说，它仍然笼罩着一层神秘的面纱。即使是那些 我非常了解你。 使用它时，人们常常发现很难阐明它的优势以及它究竟是什么（包括我自己）。在本文中，我将尝试通过列举各种……来纠正这种状况。 用例 “服务网格”*。
* 译者注：从本文的此处开始，该译文（“服务网格”）将用于指代服务网格这一尚属较新的术语。
但首先我想提几点：
- 我从未接触过服务网格，也从未在自学项目之外使用过它。另一方面，我在 2015 年为 Twitter 的内部服务网格编写了大量文档（当时它甚至还不叫“服务网格”），并且为该网站和文档做出了贡献。 所以它肯定是有意义的。
- 我的清单只是初步的，并不完整。肯定还有一些应用场景我没有遇到，而且随着技术的进步和普及，新的应用场景也可能会不断涌现。
- 同时，并非所有现有的服务网格实现都支持上述所有用例。因此，诸如“服务网格可以……”之类的表述应该理解为“某些，甚至可能是所有流行的服务网格实现可以……”。
- 例子的顺序并不重要。
短名单：
- 服务发现；
- 加密;
- 身份验证和授权；
- 负载均衡；
- 电路断开；
- 自动缩放；
- 金丝雀部署；
- 蓝绿部署；
- 健康检查；
- 限电；
- 流量镜像；
- 绝缘;
- 请求速率限制、重试和超时；
- 遥测;
- 审计;
- 可视化。
1. 服务发现
简而言之：使用简单名称连接到网络上的其他服务。
服务应该能够使用适当的名称（例如）自动“找到”彼此。 service.api.production, pets/staging или cassandra云环境的特点是弹性，一个名称可以隐藏多个服务实例。显然，在这种情况下，将所有 IP 地址硬编码到系统中是不现实的。
此外，当一个服务发现另一个服务时，它应该能够向该服务发送请求，而不必担心请求会落入已宕机的实例手中。换句话说，服务网格必须监控所有服务实例的运行状况，并尽可能保持主机列表的最新状态。
每个服务网格实现服务发现的方式都不同。目前最常见的方法是委托给外部进程，例如 Kubernetes 的 DNS。过去，在 Twitter，我们使用名称系统来实现这一目的。 此外，服务网格技术可以创建自定义命名机制（尽管我还没有遇到任何具有此功能的服务网格实现）。
2. 加密
简而言之：消除服务之间的未加密流量，并使该过程自动化且可扩展。
令人欣慰的是，攻击者无法渗透您的内部网络。防火墙在这方面发挥了重要作用。但如果黑客真的入侵了呢？他们是否能够随意操控您的内部服务流量？我们希望这种情况不会发生。为了防止这种情况的发生，您应该部署零信任网络，其中所有服务之间的流量都经过加密。大多数现代服务网格通过双向认证来实现这一点。 （相互TLS，mTLS）。在某些情况下，mTLS 可以跨越整个云和集群工作（我认为星际通信将来也会采用类似的结构）。
当然，对于 mTLS 服务网格而言，情况也是如此。 选修的每个服务都可以处理自己的 TLS，但这需要找到生成证书的方法，将证书分发到服务的各个主机，并在应用程序中包含从文件中加载这些证书的代码。哦，别忘了定期续订这些证书。服务网格使用诸如 TLS 之类的系统来自动执行 mTLS。 进而，实现证书的颁发和轮换过程的自动化。
3. 身份验证和授权
TL;DR：在请求到达服务之前，确定是谁发起了请求，并确定他们被允许做什么。
服务部门经常想知道： 谁 发出请求（身份验证），并使用此信息做出决定， 该 此主体被授权执行某项操作（授权）。在这种情况下，代词“谁”可能指：
- 其他服务。这称为“身份验证”。 皮尔例如，服务
web想要访问该服务db服务网格通常使用 mTLS 来解决这类问题，其中证书充当必要的标识符。 - 部分用户为真人。这称为“身份验证”。 要求例如，用户
haxor69想买一盏新灯。服务网提供各种机制，例如： .我们很多人都在应用程序代码中这样做过。收到请求后，我们会查找相应的表格。
users我们找到用户并比对密码，然后检查该列。permissions等等。在服务网格的情况下，这种情况甚至在请求到达服务之前就会发生。
一旦确定了请求的来源，我们就需要确定该主体被允许执行哪些操作。一些服务网格允许您以 YAML 文件或命令行形式定义基本策略（关于谁可以执行哪些操作），而另一些则提供与框架的集成，例如 最终目标是确保您的服务能够自信地接受任何来自可信来源的请求。 и 此操作是允许的。
4. 负载均衡
简而言之：按照特定模式将负载分配到各个服务实例。
服务部分中的“服务”通常包含多个相同的实例。例如，今天的服务 cache 目前共有5份，明天可能会增加到11份。请求已发送至 cache必须根据特定目标进行分配。例如，最小化延迟或最大化到达健康实例的概率。轮询算法是最常用的算法，但还有许多其他算法，例如加权排序方法。 （加权） 查询（您可以选择首选目标），铃声 （戒指） 哈希（对上游主机使用一致性哈希）或最少请求方法（优先选择请求最少的实例）。
传统的负载均衡器还提供其他功能，例如 HTTP 缓存和 DDoS 防护，但这些功能对于东西向流量（即数据中心内部的流量——译者注）来说并不特别重要（服务网格的典型应用场景）。虽然负载均衡并非必须使用服务网格，但它允许您从集中式控制平面定义和控制每个服务的负载均衡策略，从而无需在网络堆栈中部署和配置单独的负载均衡器。
5. 电路中断
TL;DR：停止对问题服务的流量，并在最坏的情况下控制损失。
如果某个服务由于任何原因无法处理流量，服务网格提供了多种解决方案（其他方案将在相关章节中讨论）。熔断是断开服务与流量连接的最严厉措施。然而，单独使用熔断机制是不够的——必须配合备用方案。可以考虑使用反压机制。 () 向满足请求的服务发送消息（只需记住为此配置您的服务网格！），或者，例如，将状态页面变为红色，并将用户重定向到另一个带有“坠落的鲸鱼”的页面版本（“Twitter 宕机了”）。
服务网格不仅可以用于确定， 何时 接下来将出现停工。 该 接下来会详细说明。在这种情况下，“何时”可以包含指定参数的任意组合：例如特定时间段内的请求总数、并发连接数、待处理请求数、活动重试次数等。
你可能不想过度使用断路器，但知道在紧急情况下有备用方案总是好的。
6. 自动扩缩容
简而言之：根据指定标准增加或减少服务实例的数量。
服务网格不是调度器，所以它们不会 完成 服务网格可以独立扩展。然而，它们可以提供调度器用于决策的信息。由于服务网格可以访问服务之间的所有流量，因此它们掌握了大量关于服务运行状况的信息：哪些服务出现问题，哪些服务利用率不足（分配的容量被浪费），等等。
例如，Kubernetes 会根据 Pod 的 CPU 和内存使用情况来扩展服务。 （参见我们的报告）“ - 大约。 译）但是，如果您决定根据任何其他指标（在我们的例子中是流量相关指标）进行扩展，则您需要一个专门的指标。 展示了如何使用 , и 但这个过程本身相当复杂。我们希望服务网格能够简化它，使我们能够简单地设置诸如“增加服务实例数量”之类的条件。 auth如果一分钟内等待执行的请求数量超过阈值。
7. 金丝雀部署
TL;DR：在部分用户中测试服务的新功能或版本。
假设你正在开发一款 SaaS 产品，即将发布一个很棒的新版本。你已经在测试环境中进行了测试，一切运行完美。但你仍然担心它在实际使用环境中的表现。换句话说，你需要测试新版本在真实场景下的性能，同时又不损害用户信任。金丝雀部署正是为此而设计的。它允许你向一部分用户展示新功能。这部分用户可以是你的忠实用户、使用免费版本的用户，或者愿意充当“小白鼠”的用户。
服务网格通过允许您指定决定哪些用户可以看到哪个版本应用的标准来实现这一点，然后据此路由流量。但是，服务本身不会发生任何变化。服务的 1.0 版本假定所有请求都来自应该看到该版本的用户，而 1.1 版本也假定其用户同样如此。同时，您可以调整新旧版本之间的流量比例，如果新版本稳定且您的“测试用户”认可，则可以将越来越多的用户重定向到新版本。
8. 蓝绿部署
简而言之：推出一项很酷的新功能，但要做好立即撤销的准备。
意 其理念是推出一项新的“蓝色”服务，使其与原有的“绿色”服务并行运行。如果一切顺利，新服务运行良好，旧服务就可以逐步关闭。（遗憾的是，这项新的“蓝色”服务终有一天也会像“绿色”服务一样走向终结……）蓝绿部署与金丝雀部署的区别在于，新功能覆盖了…… 一下子 用户（不是一部分人）；这里的重点是准备一个“备用方案”，以防万一出现问题。
服务网格提供了一种非常便捷的方式来测试“蓝图”服务，并在出现问题时立即切换到正常运行的“绿图”服务。更重要的是，它们还能提供大量关于“蓝图”服务性能的信息（参见下文“遥测”部分），帮助判断该服务是否已准备好全面投入生产环境。
笔记。 翻译。您可以阅读更多关于 Kubernetes 中不同部署策略（包括前面提到的金丝雀部署、蓝绿部署等）的信息。 .
9. 健康检查
简而言之：监控哪些服务实例运行状况良好，并对出现故障的服务实例做出响应。
健康检查 （健康检查） 有助于判断服务实例是否已准备好接收和处理流量。例如，对于 HTTP 服务，健康检查可能表现为向端点发送 GET 请求。 /health。 回答 200 OK 这将表示实例运行状况良好，而任何其他结果都表示实例尚未准备好接收流量。服务网格允许您指定运行状况检查的方法和执行频率。此信息随后可用于其他用途，例如负载均衡和熔断。
因此，健康检查并非独立用例，通常用于实现其他目标。此外，根据健康检查结果，可能需要执行一些与服务网格其他目标无关的操作，例如更新状态页面、创建 GitHub 问题或提交 JIRA 工单。而服务网格提供了一种便捷的机制来自动化所有这些操作。
10. 限电
简而言之：根据临时使用量激增情况重定向流量。
如果某个服务流量过载，您可以暂时将部分流量重定向到另一个位置（即“丢弃”或“转移”流量）。 （棚） 例如，备份到备份服务或数据中心，或永久存储位置。 因此，服务将继续处理部分请求，而不是崩溃并停止处理所有请求。负载均衡优于链式中断，但过度使用负载均衡仍然是不可取的。它有助于防止级联故障，避免下游服务崩溃。
11. 流量并行化/镜像
简而言之：一次向多个地方发送一个请求。
有时需要同时向多个服务发送请求（或多个请求）。一个典型的例子是将一部分生产流量发送到测试服务。主生产 Web 服务器再将请求发送到下游服务。 products.production 仅发送给他。服务网格会智能地复制此请求并将其发送给他。 products.staging而网络服务器对此却毫不知情。
服务网格的另一个相关用例是，它可以在流量并行化的基础上实现。 它涉及向服务的不同版本发送相同的请求，并检查所有版本的行为是否完全相同。我还没有见过像这样集成回归测试系统的服务网格实现。 但这个想法本身似乎很有前景。
12. 绝缘
简而言之：将你的服务网格拆分成微型网络。
也称为 分割隔离是将服务网格划分为逻辑上相互独立的网段，使它们彼此互不感知。隔离与创建虚拟专用网络 (VPN) 有些类似。关键区别在于，隔离不仅能让您享受到服务网格的所有优势（例如服务发现），还能增强安全性。例如，即使攻击者成功渗透到一个子网中的某个服务，他们也无法看到其他子网中正在运行哪些服务，也无法拦截这些服务的流量。
这样做也可能带来组织上的好处。您可以根据公司结构将服务拆分成子网，从而减轻开发人员跟踪整个服务网格的认知负担。
13. 请求速率限制、重试和超时
TL;DR：无需再在代码库中包含耗时的请求管理任务。
所有这些都可以被视为独立的用例，但我决定将它们合并在一起，因为它们有一个共同的特点：它们可以卸载通常由应用程序库处理的请求生命周期管理任务。如果您正在开发一个 Ruby on Rails Web 服务器（未与服务网格集成），该服务器通过以下方式向后端服务发出请求： 如果 N 个请求失败，应用程序需要自行决定如何处理。它还需要确定这些服务能够处理的流量，并使用一个特殊的库将这些参数硬编码到程序中。此外，应用程序还需要决定何时放弃请求并使其过期（使用超时机制）。要更改上述任何参数，都需要停止、重新配置并重新启动 Web 服务器。
将这些任务委托给服务网格，不仅可以免去服务开发人员考虑这些任务的麻烦，还能让他们更全面地考虑这些任务。如果涉及复杂的服务链，例如 A → B → C → D → E，则必须考虑整个请求生命周期。如果任务是延长服务 C 的超时时间，那么一次性完成所有操作显然比零散地进行要好得多：先更新服务代码，然后等待拉取请求被接受，最后等待持续集成系统部署更新后的服务。
14. 遥测
TL;DR：从服务中收集所有必要（以及并非完全必要）的信息。
遥测是一个涵盖指标、分布式追踪和日志记录的总称。服务网格提供了收集和处理这三种类型数据的机制。正是在这里，事情变得有些模糊，因为可能的选项实在太多了。就指标收集而言，有…… 以及其他可用于收集日志的工具 , , 等等 （例如，ClickHouse 与我们合作） （针对 K8s——译者注）对于分布式追踪，存在 等等。每个服务网格可能支持某些工具，而不支持其他工具。看看这个项目能否做到这一点，将会很有意思。 提供一些收敛性。
在这种情况下，服务网格技术的优势在于，原则上边车容器可以从其服务中收集上述所有数据。换句话说，您拥有一个统一的遥测数据收集系统，服务网格可以以多种方式处理所有这些信息。例如：
- 在 CLI 中查看某个服务的日志；
- 从服务网格控制面板监控请求量；
- 收集分布式跟踪信息并将其转发到 Jaeger 等系统。
注意，主观判断： 一般来说，遥测领域不宜进行大量的服务网格干预。收集基本信息并实时跟踪一些“黄金指标”（例如成功率和延迟）是可以的，但我们希望不要看到试图取代一些已经过验证和充分研究的专用系统的“弗兰肯斯坦式”堆栈出现。
15.审核
简而言之：忘记历史教训的人注定要重蹈覆辙。
审计是一门监控系统中重要事件的艺术。在服务网格中，这可能意味着跟踪谁向特定服务的特定端点发出了请求，或者在过去一个月中某个安全相关事件发生了多少次。
很明显，审计与遥测密切相关。区别在于，遥测通常与性能和技术完整性等相关，而审计则可能涉及法律和其他超出严格技术范畴的问题（例如，遵守欧盟的《通用数据保护条例》(GDPR)）。
16. 可视化
TL;DR：React.js 万岁，它是奇思妙想界面的源泉。
或许有更合适的术语，但我不知道。我指的是服务网格或其某些组件的图形化表示。这些可视化可以包含平均延迟、边车容器配置信息、健康检查结果和警报等指标。
在服务型环境中工作比在“巨石阵”中工作需要更高的认知负荷。因此，必须尽一切可能降低认知压力。一个简洁的服务网格图形界面，使用户只需点击按钮即可获得所需结果，对于这项技术的发展至关重要。
未被列入名单
我原本打算在列表中添加更多用例，但后来决定放弃。以下是列出的用例以及我做出此决定的原因：
- 多数据中心在我看来，这与其说是一个用例，不如说是服务网格或服务发现等特定功能的一个狭窄而具体的应用领域。
- 出入口这虽然是一个相关领域，但我（或许是人为地）将讨论范围限定在“东西向交通”场景下。车辆进出需要另写一篇文章。
结论
暂时就这些！再次强调，这份清单非常笼统，可能并不完整。如果您认为我遗漏了什么或犯了错误，请在 Twitter 上联系我（请遵守礼仪规范。
译者PS
文章的主要插图取材于文章中的一张图片。（作者：Gregory MacKinnon）。图中展示了应用程序（绿色部分）中的一些功能如何迁移到提供它们之间连接的服务网格（蓝色部分）。
另请阅读我们的博客：
- «“;
- «“;
- «“。
来源： habr.com
