都在说云原生，它的技术图谱你真的了解吗？

来源 | K8sMeetup社区

作者 | Catherine Paganini

翻译 | Sarah（K8sMeetup）

校对 | 木子（才云）

如果你研究过云原生应用程序和相关技术，大概率你遇到过 CNCF 的云原生全景图。这张全景图技术之多规模之大无疑会让人感到震惊，该如何去理解这张图呢？

如果把它拆开来一次只分析一小块内容，你会发现整个全景图没有那么复杂。事实上，该全景图按照功能有序地组织在一起，一旦你了解了每个类别代表的内容，你就可以轻松游走于全景图中。

本文是这一系列的第一篇文章，我们将把整个全景图拆解开来，并对整个全景图进行综述。在后续文章中，我们将聚焦在每一层（or 每一列），对每个类别解决的问题和原理进行更为详细的解读。

云原生全景图的 4 层

首先，我们剥离掉所有单个的技术，仅查看类别（如下图）。图中有不同的“行”，像建筑的不同层，每层都有自己的子类别。最底层提供了构建云原生基础设施的工具。往上，你可以开始添加运行和管理应用程序所需的工具，比如运行时和调度层。在最上层，有定义和开发应用程序的工具，比如数据库、镜像构建和 CI/CD 工具（我们将在后文讨论）。

好了，现在你应该记住了云原生全景图始于基础设施，往上的每一层都更接近实际的应用程序。这就是每层代表的意思（后面我们会讨论上图右边的两“列”）。下面我们就从最底层开始，逐层进行解析。

供应层（Provisioning）

供应指的是为云原生应用准备标准基础环境所涉及的工具。它包含了基础设施的创建、管理、配置流程的自动化，以及容器镜像的扫描、签名和存储等。供应层通过提供设置和实施策略，在应用程序和平台中构建身份验证和授权，以及处理密钥分发等等的工具，也拓展到了安全领域。

供应层包括：

自动化和部署工具：帮助工程师在无需人工干预情况下即可构建计算环境；
容器注册表：存储应用程序的可执行文件；
不同安全领域的安全和合规框架；
密钥管理解决方案：通过加密确保只有授权的用户才能访问特定的应用程序。

这些工具使工程师可以编写基础设施参数，使系统可以按需搭建新环境，确保了一致性和安全性。

运行时层（Runtime）

接下来是运行时层。这个词可能会让你感到迷惑。像很多 IT 术语一样，运行时没有严格的定义，且可以根据语境有不同的用法。狭义上讲，运行时是特定机器上准备运行应用程序的沙盒——也就是保障应用程序正常运行所需的最低配置。广义上讲，运行时是运行一个应用程序所需的所有工具。

在 CNCF 云原生全景图中，运行时保障了容器化应用程序组件的运行和通信，包括：

云原生存储：为容器化应用提供虚拟磁盘或持久化存储；
容器运行时：为容器提供隔离、资源和安全；
云网络：分布式系统的节点（机器或进程）通过其连接和通信。

编排和管理层（Orchestration and Management）

一旦按照安全和合规性标准（供应层）自动化基础设施供应，并安装了应用程序运行所需的工具（运行时层），工程师就需要弄清楚如何编排和管理应用程序。编排和管理层将所有容器化服务（应用程序组件）作为一个群组管理。这些容器化服务需要相互识别和通信，并需要进行协调。这一层可为云原生应用提供自动化和弹性能力，使云原生应用天然具有可扩展性。

这一层包含：

编排和调度：部署和管理容器集群，确保它们具有弹性伸缩能力，相互之间低耦合，并且可扩展。事实上，编排工具（绝大多数情况下就是 Kubernetes）通过管理容器和操作环境构成了集群；
协调和服务发现：使得服务（应用程序组件）之间可以相互定位和通信；
远程进程调用（RPC）：使跨节点服务间通信的技术；
服务代理：服务间通信的中介。服务代理的唯一目的就是对服务之间的通信进行更多控制，而不会对通信本身添加任何内容。服务代理对下面将提到的服务网格（service mesh）至关重要。
API 网关：一个抽象层，外部应用可通过 API 网关进行通信；
Service Mesh：某种程度上类似于 API 网关，它是应用程序进行通信的专用基础架构层，提供基于策略的内部服务间通信。此外，它还可能包含流量加密、服务发现、应用程序监控等内容。

应用定义和开发层（Application Definition and Developement)

现在，我们来到了最顶层。应用定义和开发层，顾名思义，聚集了让工程师构建和运行应用程序的工具。上述所有内容都是关于构建可靠、安全的环境，以及提供全部所需的应用程序依赖。

这一层包括：

数据库：使应用程序能以有序的方式收集数据；
流和消息传递：使应用程序能发送和接收消息（事件和流）。它不是网络层，而是让消息成为队列并处理消息的工具；
应用程序定义和镜像构建：用于配置、维护和运行容器镜像（应用程序的可执行文件）的服务；
持续集成和持续交付（CI/CD）：使开发者可自动测试代码是否与代码库（应用程序的其余部分）兼容。如果团队足够成熟，甚至可以自动部署代码到生产环境。

贯穿所有层的工具

接下来我们将进入到云原生全景图右侧贯穿所有层的两列。可观察性和分析（Observability&analysis）是监控各层的工具，平台则将各层中不同的技术捆绑为一个解决方案。

可观察性和分析（Observability and Analysis）

为了限制服务中断并降低解决问题的平均时间（MRRT），你需要监控和分析应用层序的方方面面，以便在出现异常时可立即发现并纠正。复杂环境中容易出现故障，这些工具可快速识别并解决故障，从而降低故障带来的影响。由于这一类别贯穿并监控各层，因此它在侧面，而不是嵌入到某一层中。

这这一类别你将发现：

日志工具：收集事件日志（有关进程的信息）；
监控方案：收集指标（以数字表示的系统参数，例如 RAM 可用性）；
追踪工具：追踪比监控更进了一步，它们监控用户请求的传播，与服务网格相关。
混沌工程（Chaos Engineering）：在生产环境中测试软件的工具，可识别缺陷并进行修复，减少其对服务交付的影响。

平台类（Platform）

可以看到，图中每一个模块解决一个特定的问题。但我们知道，仅有存储并不能提供应用程序所需的全部功能。你还需要编排工具，容器运行时，服务发现，网络，API 网关等等。平台覆盖多层，将不同的工具组合在一起，以解决更大的问题。

配置和微调不同的模块使其安全可靠，并确保它利用的技术都能及时更新、所有漏洞都打了补丁，这并不是一件容易的事情。使用平台时，用户不用额外担心这些细节问题。

你可能会注意到，所有的类别都围绕着 Kubernetes 展开。这是因为 Kubernetes 虽然只是云原生景观图这张拼图中的一块，但它却是云原生技术栈的核心。顺便说一下，CNCF 刚创建时，Kubernetes 就是其中的第一个种子项目，后来才有了其他项目。

平台可分为四类：

Kubernetes 发行版：采用未经修改的开放源代码（尽管有人对其进行了修改），并根据市场需要增加了其他功能；
托管的 Kubernetes：类似于 Kubernetes 发行版，但是由提供商托管；
Kubernetes 安装程序：自动执行 Kubernetes 的安装和配置过程；
PaaS/容器服务：类似于托管的 Kubernetes，但是包含了一套更广泛的应用部署工具（通常是来自云原生景观图）。
总结

在每个类别中，针对相同或相似的问题，都有不同的工具可选择。有一些是适用于新现实的预云原生技术，还有一些则是全新的。区别在于它们的实现和设计方法。没有完美的技术符合你的所有需求。大多数情况下，技术受设计和架构选择的限制——始终需要权衡取舍。

在选择技术栈时，工程师必须仔细考虑每种能力和需要权衡取舍的地方，以确定最合适的选项。虽然这样会让情况变得更复杂，但在选择应用程序所需的最适合的数据存储、基础设施管理、消息系统等方案时，这样做是最可行的办法。现在，构建一个系统比云原生之前的时代容易多了。如果构建恰当，云原生技术将提供更强大的灵活性。在现如今快速变化的技术生态中，这可能是最重要的能力之一。

更多阅读推荐