1. 应用定义与开发（App Definition and Development）

到目前为止，我们所讨论的一切都与构建可靠、安全的环境和提供所有必要的依赖性有关。我们现在已经到达了 CNCF 云原生景观的顶层。顾名思义，应用程序定义和开发层侧重于使工程师能够构建应用程序的工具。

1.1. 数据库（Database）

1.1.1. 是什么？

数据库是其他应用程序可以有效存储和检索数据的应用程序。数据库允许您存储数据，确保只有授权用户才能访问数据，并允许用户通过专门的请求检索数据。虽然有许多不同类型的数据库采用不同的方法，但它们最终都有相同的总体目标。

1.1.2. 解决什么问题？

大多数应用程序都需要一种有效的方法来存储和检索数据，同时保证数据的安全。数据库采用经过验证的技术以结构化的方式实现这一点，但要做到这一点还需要相当多的复杂性。

1.1.3. 有什么作用？

数据库为应用程序存储和检索数据提供了一个通用接口。开发人员使用这些标准接口和相对简单的查询语言来存储、查询和检索信息。同时，数据库允许用户持续备份和保存数据，以及加密和管理对数据的访问。

1.1.4. 技术 101

数据库是存储和检索数据的应用程序，使用与许多不同语言和框架兼容的通用语言和接口。

通常，有两种常见的数据库类型：结构化查询语言（SQL）数据库和无SQL数据库。特定应用程序使用的数据库应该由其需求和约束决定。

随着Kubernetes的兴起及其支持有状态应用程序的能力，我们看到新一代数据库利用了容器化。这些新的云原生数据库旨在为数据库带来Kubernetes的可扩展性和可用性优势。像YugaByte和Couchbase这样的工具是云原生数据库的例子，尽管像MySQL和Postgres这样的传统数据库在Kubernetes集群中成功且有效地运行。

Vites和TiKV是该领域的CNCF项目。

提示

如果您查看这个类别，您会注意到多个名称以DB结尾（例如MongoDB、CockroachDB、FaunaDB），正如您所猜测的，它代表数据库。您还会看到以SQL结尾的各种名称（例如MySQL或memSQL）-它们仍然相关。有些是“老派”数据库，已经适应了云原生的现实。还有一些没有SQL但与SQL兼容的数据库，如YugaByte和Vites。

1.2. 流媒体与消息（Streaming & Messaging）

1.2.1. 是什么？

为了实现一个共同的目标，服务需要相互通信并保持循环。每次服务执行某项操作时，它都会发送有关该特定事件的消息。

流媒体和消息传递工具通过在系统之间传输消息（即事件）实现服务到服务的通信。单个服务连接到消息服务，以发布事件、读取其他服务的消息，或两者兼而有之。这种动态创建了一个环境，其中单个应用程序要么是发布者，也就是说它们编写事件，要么是阅读事件的订阅者，或者更可能是两者兼而有之。

1.2.2. 解决什么问题？

随着服务的激增，应用程序环境变得越来越复杂，使得应用程序之间的通信管理变得更具挑战性。流媒体或消息平台为发布和读取系统内发生的所有事件提供了一个中心位置，允许应用程序协同工作，而无需了解彼此的任何信息。

1.2.3. 有什么作用？

当一个服务做了其他服务应该知道的事情时，它会将事件“发布”到流媒体或消息中心。需要了解这些类型事件的服务，“订阅”并观看流媒体或消息传递中心。这就是发布-订阅模型的本质，并由这些工具提供功能。

通过引入管理所有通信的“中间层”，我们正在将服务彼此间的关联进行解耦。他们只是关注事件，采取行动，然后发布新的事件。

这里有一个例子。当您首次注册 Netflix 时，“注册”服务会向消息平台发布一个“新注册事件”，其中包含更多详细信息，如姓名、电子邮件地址、订阅级别等。订阅注册事件的“帐户创建者”服务会看到该事件并创建您的帐户。同时订阅新注册活动的“客户通信”服务将把您的电子邮件地址添加到客户邮件列表中，并生成欢迎电子邮件，等等。

这允许一个高度解耦的体系结构，其中服务可以进行协作，而无需相互了解。这种解耦使工程师能够添加新功能，而无需更新下游应用程序（称为消费者）或发送大量查询。一个系统的解耦程度越高，它的变化就越灵活和顺从。这正是工程师们在系统中所追求的。

1.2.4. 技术101

消息和流媒体工具早在云原生概念出现之前就已经存在了。为了集中管理业务关键事件，组织构建了大型企业服务总线。但当我们在云原生场景中讨论消息传递和流时，我们通常指的是 NATS、RabbitMQ、Kafka 或云提供的消息队列等工具。

这些系统的共同点是它们支持的架构模式。云原生环境中的应用程序交互要么是精心安排的，要么是精心编排的。还有很多，但我们可以说，编排是指集中管理的系统，编排系统允许各个组件独立运行。

消息和流媒体系统为编排好的系统提供了一个通信的中心位置。消息总线提供了一个公共的位置，所有应用程序都可以通过发布消息来告诉其他人他们在做什么，或者通过订阅消息来查看发生了什么。

NATS和Cloudevents项目都在这个领域孵化CNCF项目。NATS提供了一个成熟的消息传递系统，Cloudevents致力于标准化系统之间的消息格式。Strimzi、Pravega和Tremor都是沙箱项目，每个项目都针对流媒体和消息传递的独特用例进行了定制。

1.3. 应用定义与镜像构建(Application Definition & Image Build)

1.3.1. 是什么？

应用定义和镜像构建是一个广泛的类别，可以分为两个主要子组。首先，以开发人员为中心的工具可以帮助他将应用程序代码构建到容器和/或Kubernetes中。第二，以操作为中心的工具，以标准化的方式部署应用程序。无论您是想加快或简化开发环境，提供部署第三方应用程序的标准化方法，还是想简化编写新 Kubernetes 扩展的过程，这一类别都是优化 Kubernete 开发者和运营商体验的众多项目和产品的总称。

1.3.2. 解决什么问题？

Kubernetes 和更普遍的容器化化环境具有很好的灵活性和强大功能。这种灵活性也带来了复杂性，主要表现为多种配置选项以及对各种用例的多种需求。开发人员需要在将代码容器化时创建可复制镜像的能力。运维人员需要一种标准化的方法来将应用程序部署到容器环境中，最后，平台团队需要提供工具来简化内部和第三方应用程序的镜像创建和应用程序部署。

1.3.3. 有什么作用？

该领域的工具旨在解决一些开发人员或运维人员面临的挑战。在开发人员方面，有一些工具可以简化扩展Kubernetes以构建、部署和连接应用程序的过程。许多项目和产品有助于存储或部署预打包的应用程序。这些允许运维人员速部署流媒体服务，如 NATS 或 Kafka，或安装服务网格，如 Linkerd。

开发云原生应用程序带来了一系列全新的挑战，需要大量不同的工具来简化应用程序构建和部署。当您开始解决环境中的操作和开发人员问题时，请寻找此类工具。

1.3.4. 技术101

应用程序定义和构建工具包含大量功能。从使用KubeVirt将Kubernetes扩展到虚拟机，到通过允许您使用Telepresence等工具将开发环境移植到Kubernete来加快应用程序开发。从更高的层次上讲，这个领域中的工具可以解决开发人员关注的问题，如如何正确编写、打包、测试或运行自定义应用程序，也可以解决操作关注的问题（如部署和管理应用程序）。

Helm是该类别中唯一一个毕业项目，它支持许多应用程序部署模式。Helm允许Kubernetes用户部署和定制许多流行的第三方应用程序，它已经被其他项目采用，如Artifact Hub（CNCF沙箱项目）。像Bitnami这样的公司也提供了精心策划的应用程序目录。最后，Helm足够灵活，允许用户自定义自己的应用程序部署，并且经常被组织用于自己的内部发布。

Operator 框架是一个孵化项目，旨在简化 Operator 的构建和部署过程。Operator 不在本指南的范围内，但请注意，他们帮助部署和管理应用程序，类似于 Helm。另一个孵化项目 Cloud Native Buildpacks 旨在简化将应用程序代码构建到容器中的过程。

在这个空间里还有很多东西，探索它们需要专门的章节。但是，如果你想让 Kubernetes 对开发者和运维人员更容易使用，请进一步研究这些工具。你很可能会找到满足你需要的东西。

1.4. 持续集成与部署（Continuous Integration & Delivery）

1.4.1. 是什么？

持续集成（CI）和持续交付（CD）工具可保障质量的情况下实现快速高效的开发。CI 能够在代码变动时自动的立即构建和测试，确保生成可部署的制品。CD 更进一步，将制品推进到部署阶段。

成熟的 CI/CD 系统可以监视源代码的变化，自动构建和测试代码，然后将其从开发阶段转移到生产阶段；在那过程中必须通过各种测试或验证，以确定是否应该继续执行或失败终止。这类工具支持这种方法。

1.4.2. 解决什么问题？

构建和部署应用程序是一个困难且容易出错的过程，特别是当它涉及大量人工干预和手动步骤时。开发人员在没有将软件集成到代码库的情况下处理软件的时间越长，识别错误所需的时间就越长，修复起来就越困难。通过定期集成代码，可以及早发现错误并更容易进行故障排除。毕竟，在几行代码中查找错误要比在几百行代码中找到错误容易得多；或者更糟糕的是，在进入生产环境后才发现它。

虽然Kubernetes等工具为运行和管理应用程序提供了极大的灵活性，但它们也为 CI/CD 工具带来了新的挑战和机遇。云原生 CI/CD 系统能够利用Kubernetes本身来构建、运行和管理CI/CD流程，通常称为管道。Kubernetes还提供了有关应用程序健康的信息，使云原生 CI/CD 工具能够更轻松地确定给定的更改是否成功或是否应该回滚。

1.4.3. 有什么作用？

CI 工具确保开发人员引入的任何代码更改或更新都能自动、持续地构建、验证并与其他更改集成。每次开发人员添加更新时，都会触发自动测试，以确保只有好的代码才能进入系统。CD 扩展了 CI，将CI过程的结果推送到类似生产或生产环境中。

假设开发人员更改了 web 应用程序的代码。CI 系统看到代码更改，然后构建并测试该web应用程序的新版本。CD 系统采用新版本，并将其部署到开发、测试、预生产和最终生产环境中。它在流程中的每个步骤之后测试部署的应用程序时都会这样做。所有这些系统共同代表了该 web 应用程序的 CI/CD 管道。

1.4.4. 技术101

随着时间的推移，已经构建了许多工具来帮助将代码从源代码存储库移动到生产环境。与大多数其他计算领域一样，云原生开发的出现改变了 CI/CD 系统。一些传统工具，如 Jenkins，可能是市场上最丰富的 CI 工具，已经彻底改头换面，以更好地适应 Kubernetes 生态系统。其他工具，如 Flux 和 Argo，开创了一种称为 GitOps 的新的持续交付方式，OpenGitOp 项目正在努力将其定义为供应商中立的标准。

通常，您会发现这个领域的项目和产品要么是（1）CI 系统，要么是（2）CD 系统，要么就是（3）帮助 CD 系统决定代码是否可以投入生产的工具，或者是（4）在 Spinnaker 和 Argo 的情况下，这三者都是。Flux 和 Argo 是 CNCF 在此领域的两个孵化项目，以及 CNCF 沙箱项目 Brigade、Keptn 和 OpenKruise。您还可以找到由持续交付基金会托管的更多选择。在这个领域寻找工具，以帮助您的组织自动化您的生产路径。

[!TIP|style:flat] CDF（持续交付基金会） CD Foundation 是一个开源社区，它提高了世界上交付软件的安全性和速度。

1.5. 总结：应用定义与交付

正如我们所看到的，应用程序定义和开发层中的工具使工程师能够构建云原生用程序。您将发现用于存储和检索数据的数据库，或支持解耦、编排架构的流式处理和消息传递工具。应用程序定义和镜像构建工具包括多种技术，可改善开发人员和操作员的体验。最后，CI/CD帮助工程师及早发现任何错误，通过提高质量来确保代码可以部署。

本章总结了CNCF景观的各个层次。接下来，我们将关注可观察性和分析“专栏”

1.6. 经验推荐

此层为容器平台上应用开发相关的部分，侧重于使工程师能够构建应用程序并使其运行的工具，主要分为数据库服务、消息队列服务、应用的定义与镜像构建服务、持续集成和部署能力等四个方面进行展开。这一层主要是聚集了与应用相关的通用的架构、工具以提供相关能力。

在云原生数据库中，可以考虑使用 TiKV 或者 Vitess 做相关的数据库服务。实际业务中 MySQL/MariaDB、Redis、MongoDB、PostgresQL、Cassadra、TIDB 是主流的选择；商业产品中微软的 SQLServer，IBM 的 DB2、Oracle 也是老牌实力派。

在流与消息分类中，Cloudevents 和 NATS 是目前推荐的选择。实际上 kafka 和 RabbitMQ 在实际的项目中被使用的也往往更多一些。在大数据场景下 Flink 和 Spark 是不错选择。

而在应用定义与镜像构建方面，HELM 和 Operator 确实是很多项目现在是实践选型中较多的类型。但 Buildstage、BuildPacks、KubeVirt 也是当前热点的选择。

而关于持续集成和持续部署的能力，目前 Argo、Flux、Keptn 已经是孵化中的项目，可以推荐的选择。而实际上 Jenkins 是目前最为主流的相关工具，，围绕 Jenkins 已然产生了大量的生态环境，Jenkins 已经有超过1300+的插件支持，几乎大部分主流的项目都提供了 Jenkins 插件的支持，另外 Gitlab 出现在这里也是因为 Gitlab 的功能中基本上可以完成软件生命周期的很多部分，远远不只是进行代码仓库的管理。这里社区单独成立 CDF 基金会来评估和管理所有的 CD 工具。