嘿哈布尔！ 我向您展示这篇文章的翻译 作者 马特·克莱恩.
这次，我“想要并翻译”了服务网格组件、数据平面和控制平面的描述。 在我看来，这个描述是最容易理解和最有趣的，最重要的是，它让我理解了“有必要吗？”
随着“服务网格”的想法在过去两年中变得越来越流行（原始文章于 10 年 2017 月 XNUMX 日），并且该领域的参与者数量不断增加，我发现整个行业的混乱程度也相应增加。技术社区关于如何比较和对比不同的解决方案。
我在 XNUMX 月份写的以下一系列推文最好地概括了这种情况：
服务网格混乱#1：Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy。 它们都无法与 Istio 匹敌。 Istio 是完全不同的东西。 1 /
第一个只是数据平面。 他们自己什么也不做。 他们一定有心情做更多事情。 2/
Istio 是将各个部分连接在一起的控制平面的示例。 这是另一层。 /结尾
之前的推文提到了几个不同的项目（Linkerd、NGINX、HAProxy、Envoy 和 Istio），但更重要的是介绍了数据平面、服务网格和控制平面的一般概念。 在这篇文章中，我将退后一步，在非常高的层面上讨论“数据平面”和“控制平面”这两个术语的含义，然后讨论这些术语如何应用于推文中提到的项目。
服务网格到底是什么？
图 1：服务网格概述
图1 说明了服务网格最基本的概念。 有四个服务集群（AD）。 每个服务实例都与本地代理服务器关联。 来自单个应用程序实例的所有网络流量（HTTP、REST、gRPC、Redis 等）都通过本地代理传递到相应的外部服务集群。 这样，应用程序实例不知道整个网络，只知道其本地代理。 实际上，分布式系统网络已从服务中删除。
数据平面
在服务网格中，位于应用程序本地的代理服务器执行以下任务：
- 服务发现。 您的应用程序可以使用哪些服务/应用程序？
- 健康检查。 服务发现返回的服务实例是否健康并准备好接受网络流量？ 这可以包括主动（例如响应/健康检查）和被动（例如使用3个连续的5xx错误作为不健康服务状态的指示）健康检查。
- 路由。 当从 REST 服务接收到对“/foo”的请求时，该请求应该发送到哪个服务集群？
- 负载均衡。 一旦在路由过程中选择了服务集群，请求应该发送到哪个服务实例？ 超时时间是多少？ 用什么断路设置？ 如果请求失败，是否应该重试？
- 认证与授权。 对于传入请求，可以使用 mTLS 或其他机制对调用服务进行加密识别/授权吗？ 如果它被识别/授权，是否允许在服务上调用请求的操作（端点），或者是否应该返回未经身份验证的响应？
- 可观测性。 应为每个请求生成详细的统计数据、日志/日志和分布式跟踪数据，以便操作员能够了解分布式流量并在出现问题时进行调试。
数据平面负责服务网格中的所有先前点。 事实上，服务本地的代理（sidecar）就是数据平面。 换句话说，数据平面负责有条件地广播、转发和监视发送到服务或从服务发送的每个网络数据包。
控制平面
本地代理在数据平面中提供的网络抽象是神奇的（？）。 然而，代理实际上如何知道到服务 B 的“/foo”路由呢？ 如何使用代理请求填充的服务发现数据？ 负载均衡、超时、断路等参数如何配置？ 如何使用蓝/绿方法或优雅的流量转换方法来部署应用程序？ 谁配置系统范围的身份验证和授权设置？
上述所有项目都在服务网格的控制平面的控制之下。 控制平面采用一组隔离的无状态代理并将它们转变为分布式系统.
我认为许多技术人员发现数据平面和控制平面的独立概念令人困惑的原因是，对于大多数人来说，数据平面是熟悉的，而控制平面是陌生的/不理解的。 我们长期以来一直致力于物理网络路由器和交换机的研究。 我们知道数据包/请求需要从 A 点发送到 B 点，并且我们可以使用硬件和软件来完成此操作。 新一代软件代理只是我们长期以来使用的工具的奇特版本。
图 2：人类控制平面
然而，我们已经使用控制平面很长时间了，尽管大多数网络运营商可能不会将系统的这一部分与任何技术组件相关联。 原因很简单：
当今使用的大多数控制平面是......我们.
上 图2 显示了我所说的“人类控制平面”。 在这种类型的部署中（仍然很常见），可能是脾气暴躁的操作员创建静态配置（可能通过脚本），并通过一些特殊过程将它们部署到所有代理。 然后，代理开始使用此配置并开始使用更新的设置处理数据平面。
图 3：高级服务网格控制平面
上 图3 显示服务网格的“扩展”控制平面。 它由以下部分组成：
- 人类：仍然有一个人（希望不那么生气）对整个系统做出高层决策。
- 控制平面用户界面：人与某种类型的用户界面交互来控制系统。 这可以是 Web 门户、命令行应用程序 (CLI) 或其他一些界面。 使用用户界面，操作员可以访问全局系统配置参数，例如：
- 部署控制、蓝/绿和/或渐进式流量过渡
- 身份验证和授权选项
- 路由表规范，例如当应用程序 A 请求有关“/foo”的信息时会发生什么
- 负载均衡器设置，例如超时、重试、熔断设置等。
- 工作负载调度程序：服务通过某种类型的调度/编排系统（例如 Kubernetes 或 Nomad）在基础设施上运行。 调度程序负责加载服务及其本地代理。
- 服务发现。 当调度程序启动和停止服务实例时，它会向服务发现系统报告健康状态。
- Sidecar代理配置API ：本地代理使用最终一致的模型从各种系统组件动态提取状态，无需操作员干预。 整个系统由所有当前运行的服务实例和本地代理服务器组成，最终汇聚成一个生态系统。 Envoy 的通用数据平面 API 是其在实践中如何运作的一个示例。
本质上，控制平面的目的是设置最终被数据平面接受的策略。 更先进的控制平面将从操作员手中移除一些系统的更多部件，并且需要更少的手动操作，只要它们正常工作！...
数据平面和控制平面。 数据平面与控制平面总结
- 服务网格数据平面：影响系统中的每个数据包/请求。 负责应用程序/服务发现、健康检查、路由、负载平衡、身份验证/授权和可观察性。
- 服务网格控制平面：为业务网络内所有运行的数据平面提供策略和配置。 不触及系统上的任何包/请求。 控制平面将所有数据平面变成一个分布式系统。
目前的项目景观
了解了上面的解释后，我们来看看 Service Mesh 项目的当前状态。
- 数据平面：Linkerd、NGINX、HAProxy、Envoy、Traefik
- 控制平面：Istio、Nelson、SmartStack
我不会深入分析上述每个解决方案，而是会简要讨论一些我认为目前在生态系统中引起混乱的问题。
Linkerd 是 2016 年初首批用于服务网格的数据平面代理服务器之一，在提高人们对服务网格设计模型的认识和关注方面做得非常出色。 大约 6 个月后，Envoy 加入 Linkerd（尽管他自 2015 年底以来一直在 Lyft）。 Linkerd 和 Envoy 是讨论服务网格时最常提到的两个项目。
Istio 于 2017 年 XNUMX 月发布。 Istio 项目的目标与中所示的扩展控制平面非常相似 图3。 Istio 的 Envoy 是默认代理。 因此，Istio 是控制平面，Envoy 是数据平面。 在很短的时间内，Istio 引起了极大的关注，其他数据平面开始集成以替代 Envoy（Linkerd 和 NGINX 都展示了与 Istio 的集成）。 事实上，不同的数据平面可以在同一控制平面内使用，这意味着控制平面和数据平面不一定是紧密耦合的。 Envoy 的通用数据平面 API 等 API 可以在系统的两个部分之间形成桥梁。
Nelson 和 SmartStack 有助于进一步说明控制平面和数据平面的分离。 Nelson 使用 Envoy 作为代理，并基于 HashiCorp 堆栈为服务网格构建可靠的控制平面，即游牧者等SmartStack 或许是新一波服务网格中的第一个。 SmartStack 围绕 HAProxy 或 NGINX 构建控制平面，展示了将控制平面与服务网格和数据平面解耦的能力。
具有服务网格的微服务架构正在获得越来越多的关注（这是正确的！），越来越多的项目和供应商开始朝这个方向努力。 在接下来的几年中，我们将看到数据平面和控制平面方面的大量创新，以及不同组件的进一步混合。 最终，微服务架构对于运营商来说应该变得更加透明和神奇（？）。
希望越来越少生气。
要点
- 服务网格由两个不同的部分组成：数据平面和控制平面。 这两个组件都是必需的，没有它们系统将无法工作。
- 控制平面大家都很熟悉了，此时，控制平面可能就是你了！
- 所有数据平面都在功能、性能、可配置性和可扩展性方面相互竞争。
- 所有控制平面在功能、可配置性、可扩展性和易用性方面都相互竞争。
- 一个控制平面可以包含正确的抽象和 API，以便可以使用多个数据平面。
来源： habr.com