云原生景观：编排和管理层解决了什么问题？如何解决的？

编排和管理层是Cloud Native Computing Foundation的Cloud Native景观的第三层。

在之前的文章《叮，你收到一份来自CNCF的云原生景观简介》中，我们对CNCF云原生生态系统做了概述。在《云原生景观：供应层(Provisioning)解决了什么问题？如何解决的？》中，我们探讨了供应层，该层主要致力于构建Cloud Native平台和应用程序的基础。

在《云原生景观：运行时层解决了什么问题？如何解决的？》里，我们着重介绍了运行时层，涵盖了容器在云原生环境中运行所需的所有内容，包括容器运行时，容器存储工具，容器网络。

一旦按照安全性标准自动搭建了基础结构(供应层)，并设置了应用程序需要运行的工具（运行时层），工程师就需要知道如何编排和管理其应用程序。

因此现在，我们必须弄清楚如何将所有应用程序组件作为一个整体来组织和管理。组件还要能够彼此标识才能进行沟通和协调，以实现一个共同的目标。

查看云原生景观图时，你会注意到一些区别：

• 大盒子中的项目是CNCF托管的开源项目。有些仍处于孵化阶段（浅蓝色/紫色框），而另一些则是已毕业的项目（深蓝色框）。
• 白色小盒子中的项目是开源项目。
• 灰色的盒子是专有产品。

请注意，即使在撰写本文时，我们也看到有新项目成为CNCF的一部分，因此始终参考实际情况-事情发展很快！

编排和调度( Orchestration & scheduling )

是什么

编排和调度是指在集群中运行和管理容器，这是一种新颖的打包和推送应用程序的方式。

容器编排器在某种程度上类似于笔记本电脑上的操作系统（OS），它可以管理所有应用程序（例如Microsoft 360，Slack，Zoom等）。操作系统执行你要使用的应用程序，并计划哪个应用程序何时使用电脑的CPU和其他硬件资源。

虽然在一台机器上运行所有功能都很棒，但是当今大多数现代应用程序都是分布式的，并且需要能够管理在几十个甚至几百个计算机上运行的所有组件。简而言之，你需要一个“集群操作系统”。这就是编排工具的用武之地。

在大多数情况下，Kubernetes也是容器协调器。容器和Kubernetes都是云原生架构的核心，这就是为什么我们如此了解它们的原因。

解决了什么问题

在云原生架构中，应用程序被分解为多个小组件或服务，每个组件或服务都放置在一个容器中。你可能听说过它们被称为微服务。现在，你不再拥有一个大型应用程序，而是拥有多个小型服务，每个服务都需要资源，监视和问题修复。虽然为单个服务手动执行这些操作是可行的，但是当你拥有数百个容器时，你将需要自动化的流程。

它如何解决

容器协调器使容器管理自动化。Kubernetes是事实上的容器编排器。

Kubernetes做一些所谓的理想状态和解。工程师在文件中指定所需状态，并与实际状态进行连续比较。如果期望状态和实际状态不匹配，Kubernetes会通过创建或销毁对象来协调它们。

相应的解决工具

Kubernetes与其他容器协调器（例如Docker Swarm和Mesos）一起位于编排和调度部分。它的基本目的是允许你将多个不同的计算机作为一个资源池进行管理。最重要的是，它允许你以声明性的方式管理它们，即，不是告诉Kubernetes如何做某事，而是提供了你要完成的工作的定义。这使你可以在一个或多个YAML文件中维护所需的状态，并将其应用于任何Kubernetes集群。然后，协调器本身会创建缺失的内容或删除不应该存在的任何内容。

协调和服务发现 (Coordination &Service Discovery )

是什么

如我们所见，现代应用程序由多个单独的服务组成，这些服务需要进行协作才能为最终用户提供价值。为了进行协作，他们需要通过网络进行通信。为了进行通信，他们必须首先相互定位。服务发现是弄清楚该如何做的过程。

解决了什么问题

云原生体系结构是动态的，可变的，这意味着它们在不断变化。当一个容器在一个节点上崩溃时，一个新的容器会在另一个节点上替换它。或者，当应用扩展时，副本将散布在整个网络中。没有一个地方可以提供特定服务。一切的位置在不断变化。服务发现工具跟踪网络中的服务，以便服务可以在需要时找到彼此。

它如何解决

服务发现工具通过提供注册和发现中心来查找和标识单个服务来解决此问题。该类别中基本上有两种工具：

（1）服务发现引擎是类似于数据库的工具，用于存储存在哪些服务以及如何定位它们的信息。

（2）名称解析工具（例如， Core DNS ）接收服务位置请求并返回网络地址信息。

备注：

在Kubernetes中，为了使Pod可达，引入了一个被称为“ service”的工作负载 。service为动态更改的Pod组提供了一个稳定的地址。

相应的解决工具

随着分布式系统变得越来越普遍，传统的DNS流程和负载均衡器通常无法跟上不断变化的端点信息。为了弥补这些缺点，创建了服务发现工具来处理各个应用程序实例信息，以快速地对其自身进行注册和注销。

CoreDNS和etcd是CNCF项目，内置在Kubernetes中。

远程过程调用(RPC)

是什么

远程过程调用（RPC）是一种使应用程序能够相互通信的技术。

解决了什么问题

现代应用程序由众多单独的服务组成，这些服务必须进行通信才能进行协作。RPC是处理应用程序之间通信的一种选择。

RPC要解决的两个问题：

解决分布式系统中，服务之间的调用问题。

远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。

它如何解决

RPC提供了解决服务之间通信的紧密耦合方式。它的通信高效，并且许多语言支持RPC接口实现。

相应的解决工具

gRPC是一种特别流行的RPC实施，已被CNCF采用。

服务代理 ( Service proxy)

是什么

代理的唯一目的是对服务通信施加更多控制，它不会对通信本身添加任何内容。

服务代理是一种工具，用于拦截进出给定服务的流量，对其应用一些逻辑，然后将该流量转发到另一个服务。它本质上充当“中间人”，收集有关网络流量的信息/或对其应用规则。

解决了什么问题

应用程序应以受控方式发送和接收网络流量。为了跟踪流量并可能对其进行转换或重定向，我们需要收集数据。传统上，启用数据收集和网络流量管理的代码嵌入在每个应用程序中。

服务代理使我们能够“外部化”此功能。它不再需要存在于应用程序中。而是将其嵌入平台层（你的应用程序在其中运行）。这是非常强大的功能，因为它使开发人员可以完全专注于编写应用程序逻辑，而处理流量的通用任务由平台团队管理。通过单个公共位置集中管理和分发全局所需的服务功能（例如，路由或TLS终止），服务之间的通信更加可靠，安全和高效。

它如何解决

代理充当用户和服务之间的”看门人”。通过这种独特的定位，代理可以洞悉正在发生的通信类型，他们可以确定将特定请求发送到哪里，甚至完全拒绝该请求。

代理收集关键数据，管理路由（在服务之间平均分配流量或在某些服务发生故障时重新路由），加密连接信息和缓存数据（减少资源消耗）。

相应的解决工具

服务代理的工作原理是拦截服务之间的流量，对它们执行一些逻辑，然后潜在地允许流量继续前进。通过将一组集中控制的功能放入此代理，他们可以收集有关服务间通信的详细指标，防止服务过载，并将其他通用标准应用于服务。

服务代理是服务网格等其他工具的基础，因为它们提供了对所有网络流量实施更高级别策略的方法。

请注意，CNCF将负载均衡器和 ingress 提供程序包括在此类别中。Envoy，Contour和BFE都是CNCF项目。

API网关

是什么

人们通常通过诸如网页或应用程序之类的GUI（图形用户界面）与计算机程序进行交互，而计算机则通过API（应用程序接口）进行交互。但是，不应将API与API网关混淆。

API网关允许组织将关键功能（例如授权或限制应用程序之间的请求数量）放置到集中管理的位置。它还用作API使用者的通用接口。

通过API网关，组织可以集中控制（限制或启用）应用程序之间的交互并跟踪它们，从而实现诸如退款，身份验证之类的功能，并防止服务被过度使用（也称为速率限制）。

解决了什么问题

尽管大多数容器和核心应用程序都具有API，但API网关不仅仅是API。API网关简化了组织如何管理规则并将规则应用于所有交互。

API网关允许开发人员编写和维护较少的自定义代码。他们还使团队能够查看和控制用户与应用程序本身之间的交互。

它如何解决

API网关位于用户和应用程序之间。它充当中介，将来自用户的消息（请求）转发给适当的服务。但是在交出请求之前，它会评估是否允许用户执行他们正在尝试做的事情，并记录有关发出请求的用户信息以及发出的请求数量的详细信息。

简而言之，API网关为用户提供了应用程序的单入口点。它还使你可以将原本在应用程序中实现的任务移交给网关，从而节省了开发人员的时间和金钱。

相应的解决工具

API网关的工作原理是拦截对后端服务的调用，执行某种“增值活动“，例如验证授权，收集指标或转换请求，然后执行其认为适当的任何操作。

API网关是一组下游应用程序的通用入口点，同时提供了一个团队可以在其中注入业务逻辑以处理授权，速率限制和退款的地方。

服务网格

是什么

“继Kubernetes之后，服务网格技术已成为云原生堆栈中最关键的组件。”

服务网格管理服务之间的流量（即通信）。它们使平台团队能够在集群内运行的所有服务之间统一添加可靠性，可观察性和安全性功能，而无需更改任何代码。

解决了什么问题

在云原生世界中， 随着服务数量的增加，我们必须处理它们之间的交互。除了服务之间的通信外，我们还必须处理整个系统运行状况的监视，容错，日志记录和遥测功能，处理多点故障等等。

在服务网格之前，必须将该功能编码到每个单独的应用程序中。

有了Service Mesh，我们不必使用任何第三方库/组件，就可以在每个微服务中提供与网络相关的通用功能，例如配置，路由，遥测，记录，断路等。

它如何解决

服务网格在平台层上的所有服务之间均匀地增加了可靠性，可观察性和安全性功能，而无需触及应用程序代码。它们与任何编程语言兼容，使开发团队可以专注于编写业务逻辑。

相应的解决工具

服务网格通过服务代理将集群上运行的所有服务绑定在一起，从而形成服务网格。这些通过服务网格控制平面进行管理和控制。服务网格允许平台所有者在不要求开发人员编写自定义逻辑的情况下执行常见操作或在应用程序上收集数据。

服务网格可以定义为处理微服务架构中服务间通信的专用基础结构层 ，它的功能在于无需修改应用程序即可提供关键系统功能的能力。

服务网格提供了许多有用的功能，包括显示详细指标，加密所有流量，限制由什么服务授权的操作，提供插件的功能等等。有关更多详细信息，请查看服务网格接口规范。

结论

如我们所见，该层中的工具将一个个独立的容器化服务作为一个组进行管理。编排和调度工具类似某种集群操作系统，用于管理整个集群中的容器化应用程序。协调和服务发现，服务代理和服务网格可确保服务可以彼此找到并进行有效通信，以便作为一个内聚的应用程序进行协作。API网关是一个附加层，可提供对服务通信的更多控制，尤其是在外部应用程序之间。

译文链接:https://thenewstack.io/the-cloud-native-landscape-the-orchestration-and-management-layer/