如果你一直在跟踪和研究云原生应用程序和技术，一定会知道云原生计算基金会（CNCF）的云原生技术图谱（Landscape）。乍一眼看去，你一定会被庞大的云原生规模所震撼，为什么会有如此众多的类别和技术，想要了解完整的技术图谱不是容易的事情。
清晰技术图谱可在CNCF网站查看
但如果对其剥丝抽茧，分解类别，以及搞清楚每一类代表了哪些技术，以及每个类别所要解决的问题，那么理解上就会轻松很多。大体上云原生技术图谱可以分为四层配置层（Provisioning Layer）、运行时层（Runtime Layer）、编排和管理层（Orchestration and Management Layer）、应用定义和开发层（Application Definition and Development Layer）。架构的每一层都有自己的子类别。
配置层（Provisioning Layer）
配置层是构建云原生应用程序基础所涉及的工具。它包含了从自动化基础结构的创建，管理和配置到扫描，签名和存储容器镜像等所有内容。提供设置和实施策略，在应用程序和平台中构建身份验证和授权，以及处理机密分发的工具，资源调配，甚至扩展到了安全领域。它包含了一些重要的子类别：
- 自动化和配置工具——帮助工程师在无需人工干预下构建计算环境。
- 容器注册表——存储应用程序的可执行文件。
- 安全和合规框架——涉及不同的安全领域。
- 密钥管理解决方案——加密来确保只有授权的用户才能访问应用程序。
这些工具使工程师可以整理所有基础架构的细节，便于系统可以根据需要来调整环境，确保它们的一致性和安全性。
运行时层（Runtime Layer）
运行时是可能引起混淆的术语之一。与IT中的许多术语一样，没有严格的定义，可以根据上下文使用不同的定义。从狭义上讲，运行时是准备运行应用程序的特定计算机上的沙箱，即应用程序所需的最低限度。从广义上讲，运行时是应用程序需要运行的任何工具。
在CNCF的云原生环境中，运行时在两者之间的某个位置定义，重点放在对容器化应用特别重要的组件上：它们需要运行，记忆和互动的内容。它们包括：
- 云原生存储为容器化的应用程序提供了虚拟化磁盘或持久性。
- 容器运行时为容器提供了约束，资源和安全性方面的考虑，并使用编程后的应用程序执行了文件。
- 云原生网络，分布式系统的节点（机器或过程）通过其进行连接和通信的网络。
编排和管理层（Orchestration and Management Layer）
一旦按照安全性和合规性标准自动执行基础结构设置，并设置了应用程序需要运行的工具，工程师就必须弄清楚如何编排和管理其应用程序。编排和管理层处理所有容器化服务（应用程序组件）如何作为一个组进行管理。他们需要确定其他服务，相互通信并进行协调。云原生应用程序具有固有的可扩展性，它依赖于此层启用的自动化和弹性。
在这一层中包括：
- 编排和调度——部署和管理容器集群，以确保它们具有弹性，松散耦合和可伸缩性。实际上，在大多数情况下，编排工具Kubernetes就是通过管理容器和操作环境构成集群的
- 协调和服务发现——因此服务（应用程序组件）可以相互定位和通信。
- 远程过程调用（RPC）——一种使一个节点上的服务与通过网络连接的不同节点上的服务进行通信的技术。
- 服务代理——是放置在服务之间的中介，通过它们进行通信。代理的唯一目的是对服务通信施加更多控制，它不会对通信本身添加任何内容。这些代理对于下面提到的服务网格至关重要。
- API网关——一个抽象层，外部应用程序可以通过它进行通信。
- 服务网格——在某种程度上类似于API网关，它是应用程序通过其进行通信的专用基础结构层，但是它提供了策略驱动的内部服务到服务的通信。此外，它可能包括从流量加密到服务发现到应用程序可观察性的所有内容。
应用定义和开发层（Application Definition and Development Layer）
顾名思义，应用程序定义和开发层侧重于让工程师能够构建应用程序并使其运行的工具。上面讨论的所有内容都与构建可靠，安全的环境以及提供所有必需的应用程序依赖关系有关。
在这层包括：
- 数据库——使应用程序能够以有组织的方式收集数据的数据库。
- 流和消息——传递使应用程序能够发送和接收消息（事件和流）。它不是网络层，而是用于对消息进行排队和处理的工具。
- 应用程序定义和镜像构建——是帮助配置，维护和运行容器镜像（应用程序的可执行文件）的服务。
- 持续集成和交付（CI/CD）——使开发人员能够自动测试其代码是否与代码库（应用程序的其余部分）兼容，如果他们的团队足够成熟，甚至可以自动部署到生产中。
跨所有层运行的工具
回到类别上，下面讨论在所有层上运行的列分类。可观察性和分析是监控所有层的工具。另一方面，平台将这些层中的多种技术捆绑到一个解决方案中，包括可观察性和分析。
可观察性与分析（Observability and Analysis）
为了限制服务中断并降低MRRT（解决问题的时间），需要监控和分析应用程序的各个方面，以便立即发现并纠正任何异常情况。故障将在复杂的环境中发生，这些工具将通过帮助尽快识别和解决故障来帮助减轻影响。由于此类别遍历并监控所有层，因位于垂直面，而不是嵌入在特定层中。
在这层包括：
- 收集事件日志——有关进程的信息的日志记录工具。
- 监控解决方案——收集指标（数字系统参数，例如RAM可用性）。
- 跟踪——比监控和监控用户请求的传播更进一步。与服务网格相关。
- 混沌工程——是对生产中的软件进行测试的工具，可以在缺陷影响服务交付之前对其进行识别并加以修复。
平台（Platforms）
如上，每个模块都解决了一个特定的问题。仅存储并不能提供管理应用程序所需的全部功能。我们需要一个编排工具、容器运行时、服务发现、网络、API网关等。覆盖多层，平台将不同的工具捆绑在一起，以解决更大的问题。
配置和微调不同的模块以使其可靠和安全，并确保更新其利用的所有技术，并修补漏洞。使用平台，用户不必担心这些细节，可实现生产中的增值。
你可能会注意到，所有类别都围绕Kubernetes展开。这是因为Kubernetes是云原生堆栈的核心。别忘记，Kubernetes是CNCF的第一个孵化项目，之后才有了其他所有后续项目。
平台可分为四种：
- Kubernetes发行版（Kubernetes distributions）采用了未经修改的开源代码，尽管有供应商对其进行了修改，并围绕其市场添加了其市场需求的其他功能。
- 托管Kubernetes（Hosted Kubernetes）类似于发行版，但由提供商在其或用户自己的基础架构上进行管理。
- Kubernetes安装程序（Kubernetes installers），它们可以自动执行Kubernetes的安装和配置过程。
- PaaS/容器服务（PaaS/container services），与托管的Kubernetes相似，但是包含了广泛的应用程序部署工具集（通常是云原生环境的一部分）。
总结
在每种类别中，都有解决相同或相似问题的不同工具。有些是满足当下云原生技术的，有些则是全新的。区别在于它们的实现和设计方法。没有完美的技术，因为在大多数情况下技术受到设计和架构选择的限制，始终存在一个权衡。
在选择堆栈时，云原生工程师必须仔细考虑每种功能并进行权衡，以确定适合其用例的最佳选择。尽管这带来了额外的复杂性，但选择最适合应用程序需求的数据存储，基础架构管理，消息系统等是必须的。现在，架构系统比在云之前的原生世界中容易得多。而且，如果进行适当的架构设计，云原生技术将提供强大且急需的灵活性。
