哈Ha！ 我向您介绍了Matt Klein的文章“服务网格数据平面与控制平面”的翻译。



这次，我想要并翻译了服务网格，数据平面和控制平面这两个组件的描述。 在我看来，这种描述是最可理解和有趣的，而且最重要的是它导致了对“是否有必要？”的理解。

随着“服务网格”的想法在过去两年中（2017年10月10日的原始文章）变得越来越流行，并且太空参与者的数量在增加，我看到整个技术社区在如何比较方面的困惑也相应增加并对比不同的解决方案。

我在7月撰写的以下一系列推文中最好地描述了这种情况：

与服务网格（服务网格）的混淆1：Linkerd〜= Nginx〜= Haproxy〜=特使。 他们都不等于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显示了服务网格的“扩展”控制平面。 它由以下部分组成：

• 人类 ：仍然有一个人（希望减少生气）对整个系统做出高层决策。
• 控制平面UI ：一个人与某种类型的用户界面进行交互以控制系统。 它可以是Web门户，命令行应用程序（CLI）或其他界面。 使用用户界面，操作员可以访问以下全局系统配置参数：
  
  • 部署管理，蓝色/绿色和/或逐步的流量转移
  • 身份验证和授权设置
  • 路由表规范，例如，当应用程序A请求有关“ / foo”的信息时，会发生什么情况
  • 负载平衡器设置，例如超时，重试，断路参数等。
• Workload Scheduler ：通过某种类型的计划/编排系统（例如Kubernetes或Nomad）在基础架构中启动服务。 调度程序负责将服务及其本地代理服务器一起加载。
• 服务发现 调度程序启动和停止服务实例时，会将运行状况报告给服务发现系统。
• Sidecar代理配置API ：本地代理根据“最终一致”模型从系统的各个组件动态提取状态，而无需操作员干预。 整个系统由当前正在运行的所有服务实例和本地代理服务器组成，最终融合为一个生态系统。 Envoy数据平面API是在实践中如何工作的一个示例。

本质上，控制平面的目标是建立最终将被数据平面采用的策略。 如果它们能正常工作，那么更高级的控制平面将使操作员从某些系统上卸下更多的部件，并且需要较少的手动控制！

数据平面和控制平面。 数据平面与控制平面摘要

• 服务网格数据平面 ：影响系统中的每个数据包/请求。 负责应用程序/服务发现，运行状况检查，路由，负载平衡，身份验证/授权和可观察性。
• 服务网格控制平面 ：为服务网络内的所有工作数据平面提供策略和配置。 请勿触摸系统中的任何数据包/请求。 控制平面将所有数据平面转换为分布式系统。

当前项目前景

弄清楚上面的解释后，我们来看一下“服务网格”项目的当前状态。

• 数据平面 ：Linkerd，NGINX，HAProxy，Envoy，Traefik
• 控制平面 ：Istio，Nelson，SmartStack

我将不对上述每个解决方案进行深入分析，而是简要介绍一些我认为目前会造成生态系统混乱的问题。

在2016年初，Linkerd是用于服务网格的数据平面的首批代理服务器之一，并且在提高意识和增加对服务网格设计模型的关注方面做得非常出色。 此后约6个月，Envoy加入了Linkerd（尽管他自2015年底以来一直在Lyft工作）。 Linkerd和Envoy是讨论服务网络时最常提及的两个项目。

Istio于2017年5月宣布。 Istio项目的目标与图3中所示的扩展控制平面非常相似。 Envoy for Istio是默认的代理服务器。 因此，Istio是控制平面，Envoy是数据平面。 在很短的时间内，Istio引起了很多动荡，其他数据平面开始集成以替代Envoy（Linkerd和NGINX都展示了与Istio的集成）。 您可以在同一控制平面中使用不同的数据平面这一事实意味着，控制平面和数据平面不一定紧密相关。 诸如Envoy通用数据平面API之类的API可以在系统的两个部分之间形成桥梁。

Nelson和SmartStack帮助进一步说明控制平面和数据平面的分离。 纳尔逊使用Envoy作为其代理，并基于HashiCorp堆栈（即E. 游牧民族等 SmartStack也许是新一波服务网络浪潮中的第一个。 SmartStack在HAProxy或NGINX周围形成一个控制平面，展示了将控制平面与服务网格和数据平面分离的能力。

具有服务网格的微服务架构吸引了更多关注（对！），并且越来越多的项目和供应商开始朝这个方向努力。 在接下来的几年中，我们将在数据平面和控制平面上看到许多创新，以及各种组件的进一步融合。 最终，微服务架构对于操作员来说应该变得更加透明和神奇（？）。
希望越来越烦。

重点（要点）

• 服务网格（服务网格）由两个不同的部分组成：数据平面和控制平面。 这两个组件都是必需的，没有它们，系统将无法运行。
• 每个人都熟悉控制平面，现在您可以成为控制平面！
• 所有数据平面在功能，性能，可配置性和可扩展性上相互竞争。
• 所有控制平面在功能，可配置性，可扩展性和可用性方面都存在竞争。
• 单个控制平面可以包含正确的抽象和API，以便可以使用多个数据平面。