基础设施架构： 容器创造第四平面

在传统的网络基础设施中，通常有三个与网络基础设施相关的架构平面：数据、控制和管理。

这些的确切定义可能因基础设施的类型和具体实施而有所不同，但原型对于大多数网络基础设施来说基本上是准确的。

• 数据平面
  
  • 数据路径，是数据包（数据）传递的路径。 数据平面负责接受数据包并将其转发到正确的目的地。
• 控制平面
  
  • 一般来说，控制平面决定数据被转发到哪里。 路由协议是控制平面功能的很好例子，如今可能更加动态的高阶决策也是如此。 具体实现各不相同，但可以是数据平面将数据传递到控制平面进行决策，也可以是控制平面透明地观察数据并根据特定触发器采取行动。 控制平面通常还负责监控设备的健康状况并收集统计数据。
• 管理平面
  
  • 管理平面是三个平面中最明显的，因为它是我们与控制平面交互的地方。 传统管理平面使用 CLI（命令行界面），而现代管理平面则更喜欢 API（应用编程接口）。 无论使用何种方法，管理平面都允许操作员设置由控制平面强制执行的策略。 这包括基于 IP 地址和设备类型等特征的负载均衡算法和允许/拒绝策略等配置选项。

但还有另一种编排在幕后进行，操作员基本上看不到。 它与管理无关，只是从人类操作员手中夺取了一些责任。

这里的区别是，操作是由执行期间环境的变化自动触发的，而不是作为部署事件。 但有关发生了什么变化的信息至关重要，这意味着必须从某个地方获取它。

在传统的运营模式中，信息通常来自变更单或请求。 对于现代运营模型（尤其是容器）而言，这些信息是通过发现机制从服务注册表中获取的。

服务注册和发现

容器环境的本质包括这样的假设：IP 地址对于应用环境来说实际上并不重要。 但它们对基础设施确实很重要，因为数据仍然必须在设备之间路由和转发，才能穿越客户端和应用之间的路径。 在现代环境中，这些 IP 地址通常存在的时间很短（容器/服务的生命周期）。

考虑一下DataDog的以下发现（重点补充）：

编排器的快速采用（见事实 4 ）似乎正在推动容器的寿命进一步缩短，因为容器的自动启动和停止会导致更高的客户流失率。 在运行编排器的组织中，容器的典型寿命约为 12 小时。 在没有编排的组织中，容器的平均寿命为六天。

_{来自 < https://www.datadoghq.com/docker-adoption >} 

想象一下，如果您作为操作员，必须每六天更新一次路由表或负载均衡池，更不用说每十二小时更新一次了。 你不会做其他事。 配置错误的可能性会很大，而且您被迫以手动模式操作来管理容器集群中的更改的时间越长，配置错误的可能性就越大。

服务注册表（如Consul ）成为容器部署的关键组件。 服务注册表跟踪实例和服务及其关联的 IP 地址。 从这个方面来看，它们可以被比作“容器和服务的 DNS”。 

因此服务注册表会跟踪集群中容器的当前特征。 发现是连接到服务注册表（通过 API 或订阅消息队列）以将实例与 IP 地址匹配的过程。

这意味着对于需要将流量路由到容器集群内的特定服务或实例的基础设施，它必须能够检索 IP 地址。 因为尽管容器对应用隐藏了网络，但它们仍然依赖网络将数据从一个地方传输到另一个地方。

第四层面： 编排

这样做的目的是在与容器编排环境交互的基础设施中引入一个新架构层。 这一层——即编排层——与容器环境集成，并利用服务发现等功能来自动发现服务和实例。 这意味着负载均衡器可以自动发现池的成员并根据环境的变化不断更新它。 这减轻了手动更新负载均衡池的操作负担 - 而且当容器平均存活时间少于一周时，这项任务变得越来越繁琐。

该平面不适用于与操作员交互。 配置、监控和操作仍然通过管理平面完成。 服务注册表的位置将通过管理平面进行配置，但由编排平面用来连接和传达控制平面的变化。

我们可以如下定义编排平面。

• 编排平面是基础设施架构中最不显眼的平面之一。 与它的交互是通过管理平面完成的，管理平面主要负责将编排平面指向适当的服务注册表。 它的职责是更新控制平面中的动态组件，以确保容器化资源的正确转发和可用性。

仍然存在的问题：该平面是否应该与控制平面和数据平面一起集成到设备中，或者它是否仅仅是管理平面上的一层饰面（这会稍微改变我们的图表，但不会影响平面和组件之间的交互）。 许多传统设备已经通过提供与容器环境集成并通过管理平面进行更改的扩展来支持这一新兴平面。 这是重构传统架构以将功能扩展到现代环境的一个很好的例子。 但最终它可能不是理想的解决方案。 

这为什么重要？

乍一看，引入第四个基础设施层面似乎并不重要。 毕竟，它的功能是减轻操作员的一些繁琐任务的责任。 那不会很糟糕。

这并不是坏事，但重要的是要理解从静态到动态配置的转变会对控制平面的一些最重要的功能产生影响。 服务发现的重要性日益凸显，其可用性和安全性也变得至关重要。 实际上，它成为整个应用基础设施所依赖的单点故障。

服务注册表建立在大多数现代应用相同的前提上——它们是为了处理故障而构建的。 您可能会遇到这样的情况：在您将流量转发到其实例之前，您刚刚发现的 IP 地址就消失了。 大多数基础设施都能够在此时重新传输，但该过程需要时间。 微秒在数字经济中至关重要，因此超时和发现间隔等传统选项将对依赖发现的现代架构产生影响。 监控也变得更加重要，因为尽快确定健康和可用性的能力可以决定用户是满意还是不满意。 两者都是业务层面的问题，现代组织中的每个人都应该意识到这一点，并将其纳入自己的指标和期望中。

基础设施中编排平面的实现以及服务注册表的选择成为您在决策过程中使用什么技术的重要因素。 仔细考虑您的选择，因为它们会影响通过基于容器的架构交付的应用的可用性和性能。