作者 | Catherine Paganini、Jason Morgan

来源 | K8sMeetup

头图 | 下载于视觉中国

前文介绍了如何将所有应用程序组件作为整体来编排和管理（编排和管理层）。本文将介绍云原生全景图的最上层：应用程序定义和开发层。

现在我们来到了云原生全景图的最上层。应用程序定义和开发层，顾名思义，聚焦在帮助工程师构建应用程序并使其运行的工具上。本系列前面的文章都是关于构建可靠安全的环境以及提供所有必需的应用程序依赖，应用程序定义和开发层则是关于构建软件。

数据库

是什么

数据库管理系统是一个应用程序，可帮助其他应用程序高效地存储和检索数据。

数据库能保障数据存储，仅授权的用户能访问数据，并且允许用户通过专门的请求来检索数据。尽管数据库类型繁多，但它们的总体目标都是相同的。

解决的问题

大多数应用程序都需要有效的方式来存储和检索数据，并且保证数据安全。数据库使用成熟的技术以结构化的方式进行此操作。

如何解决

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

对应工具

我们已经了解了数据库管理系统是一种用于存储和检索数据的应用程序。它使用一种通用的语言和界面，并且可以被多种语言和框架轻松使用。

常见的两种数据库类型为：结构化查询语言（SQL）数据库和 NoSQL 数据库。应用程序该使用哪种数据库应该由其需求来驱动。

Kubernetes 支持有状态的应用程序，近年来使用 Kubernetes 的使用越来越广泛，我们已经看到了利用容器化技术的新一代数据库。这些新的云原生数据库旨在将 Kubernetes 的扩展性和可用性优势引入数据库。YugaByte 和 Couchbase 之类的工具是典型的云原生数据库，Vitess 和 TiKV 是该领域的 CNCF 项目。

注意：查看此类别时会发现以 DB 结尾的多个名称（例如 MongoDB、CockroachDB、FaunaDB），你可能会猜测它们代表数据库。还有以 SQL 结尾的各种名称（例如 MySQL 或 MemSQL）。一些是已经适应了云原生环境的“老派”数据库，还有一些是兼容 SQL 的 NoSQL 数据库，例如 YugaByte 和 Vitess。

数据流和消息传递

是什么

数据流和消息传递工具通过在系统之间传输消息（即事件）来实现服务到服务的通信。单个服务连接到消息传递服务以发布事件和（或）从其他服务读取消息。这种动态变化创造了一个环境，在这个环境中单个应用要么是发布者，即可编写事件；要么是订阅事件的订阅者，或者更可能是两者兼而有之。

解决的问题

随着服务激增，应用程序环境变得越来越复杂，应用程序之间的通信编排也更具挑战性。数据流或消息平台提供了一个中心位置来发布和读取系统中发生的所有事件，从而使应用程序可以一起工作，而不必相互了解。

如何解决

当一个服务执行其他服务应该知道的事情时，它会将事件“发布”到数据流或消息传递工具。需要了解这些事件类型的服务将订阅并监视数据流或消息传递工具。这就是“发布-订阅”的本质。

通过引入管理通信的“中间层”可以使服务彼此解耦。服务只是监视事件、采取行动并发布新事件，这样能建立高度分离的体系结构。在此体系结构中，服务可以协作而无需彼此了解。这种解耦使工程师能够添加新功能，而无需更新下游应用程序（消费者）或发送大量查询。系统的解耦程度越高，更改的灵活性和适应性就越高，而这正是工程师在系统中所追求的。

对应工具

数据流和消息传递工具早在云原生技术成为现实之前就已经存在了。为了集中管理关键业务事件，组织建立了大型的企业级服务总线。但是，当我们在云原生环境中谈论数据流和消息传递时，通常是指 NATS、RabbitMQ、Kafka 或云提供的消息队列之类的工具。

消息传递和数据流传输系统为编排系统进行通信提供了一个中心位置。消息总线提供了所有应用程序都可以访问的公共位置，应用程序都可以通过发布消息来告诉其服务它们在做什么，或者通过订阅消息来查看正在发生的事情。

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

应用程序定义和镜像构建

是什么

应用程序定义和镜像构建是一个广泛的类别，可以分为两个主要的子类别：

• 聚焦于开发的工具：可帮助将应用程序代码构建到容器和（或）Kubernetes 中；

• 聚焦于运维的工具：以标准化的方式部署应用。

无论是加快或简化开发环境，提供标准化的方式来部署第三方应用程序，还是简化编写新的 Kubernetes 扩展的过程，此类别的工具都可以优化 Kubernetes 开发和运维人员的体验。

解决的问题

Kubernetes（或者容器化环境）非常灵活且功能强大。这种灵活性也带来了复杂性，主要体现在对于各种新用例有众多配置选项。开发人员必须将代码容器化，并在类生产环境中进行开发。在快速的发布计划周期下，运维人员需要以一种标准化的方法来将应用程序部署到容器环境中。

如何解决

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

开发云原生应用程序带来了一系列全新的挑战，因此需要大量多样化的工具来简化应用程序的构建和部署。当你需要解决环境中的开发和运维问题时，可以看看此类别中的工具。

对应的工具

应用程序定义和构建工具涵盖了广泛的功能，比如使用 KubeVirt 将 Kubernetes 扩展到虚拟机，或使用 Telepresence 之类的工具将开发环境移植到 Kubernetes 中来加速应用程序开发等。从整体上讲，该领域中的工具可以解决开发人员面临的正确编写、打包、测试或运行自定义应用程序的问题，也可以解决运维人员面临的部署和管理应用程序的问题。

Helm 是该类别中唯一一个毕业的项目，为许多应用程序部署模式奠定了基础。Helm 允许 Kubernetes 用户部署和自定义一些流行的第三方应用程序，Artifact Hub（CNCF 沙箱项目）和 Bitnami 等项目已采用 Helm 来提供精选的应用程序目录。Helm 也足够灵活，允许用户自定义自己的应用程序部署。

Operator Framework 是一个孵化项目，旨在简化构建和部署 Operator 的过程。Operator 不在本文讨论范围之内，但请注意，它类似于 Helm，有助于部署和管理应用程序。Cloud Native Buildpacks 是另一个孵化项目，旨在简化将应用程序代码构建到容器中的过程。

持续集成和持续交付

是什么

持续集成（CI）和持续交付（CD）工具可通过嵌入式质量保证实现快速高效的开发过程。CI 通过立即构建和测试代码来自动化代码变更，确保生成可部署的制品。CD 则更进一步，推动该制品进入部署阶段。

成熟的 CI/CD 系统会监视源代码中的变更，自动构建和测试代码，然后将其从开发阶段转移到生产阶段。在此过程中，CI/CD 系统必须通过各种测试或验证来决定该过程是继续还是失败。

解决的问题

构建和部署应用程序是一个困难重重且容易出错的过程，特别是当过程中涉及很多人为干预和手动步骤时。如果不将代码集成到代码库中，开发人员在软件上花的时间越长，识别错误所花费的时间就越长，问题修复也就越困难。通过定期集成代码，可以及早发现错误并更轻松地排除故障。毕竟，在几行代码中查找错误比在几百行代码中查找错误要容易得多。

尽管 Kubernetes 之类的工具为运行和管理应用程序提供了极大的灵活性，它们也为 CI/CD 工具带来了新的挑战和机遇。云原生 CI/CD 系统能够利用 Kubernetes 本身来构建、运行和管理 CI/CD 流程（通常称为流水线）。Kubernetes 还提供应用程序运行状况的信息，从而使云原生 CI/CD 工具能够更轻松地确定给定的变更是否成功，是否需要回滚。

如何解决

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

假设开发人员更改了 Web 应用的代码。CI 系统会看到代码更改，然后构建并测试该 Web 应用的新版本。CD 系统获取该新版本，并将其部署到开发、测试、预生产以及最终生产环境中。在流程的每个步骤之后测试已部署的应用程序时，它会执行此操作。这些系统一起构成了该 Web 应用的 CI/CD 管道。

对应工具

随着时间的流逝，市面上已经有了许多工具来帮助将代码从存储库移至运行最终应用程序的生产环境。像大多数其他计算领域一样，云原生开发的到来改变了 CI/CD 系统。类似 Jenkins （可能是市场上使用最广泛的 CI 工具）的传统工具已经通过完善迭代，以更好地适应 Kubernetes 生态系统。Flux 和 Argo 等公司率先开发了一种称为 GitOps 的持续交付的新方法。

通常，该领域的项目和产品是：

• CI 系统；

• CD 系统；

• 帮助 CD 系统确定代码是否准备好投入生产的工具；和（或）

• 前三者的合集（Spinnaker 和 Argo 就是如此）。

Argo 和 Brigade 是该领域中仅有的 CNCF 项目，但是你可以找到由持续交付基金会（Continuous Delivery Foundation）托管的更多项目。在此空间中寻找工具，可以帮助组织自动化生产路径。

总结

应用程序定义和开发层中的工具使工程师能够构建云原生应用程序。该层的工具包括：

• 数据库：存储和检索数据；

• 数据流和消息传递工具：实现相互分离、精心设计的架构；

• 应用程序定义和镜像构建工具：包含可改善开发人员和操作员体验的多种技术；

• CI/CD 工具：确保代码处于可部署状态，并帮助工程师及早发现错误，从而确保代码质量。

CSDN协同行业大佬
打造13长热门知识图谱及IT成长路线
助力千万IT人成长，快速实现职场进阶！

更多精彩推荐

☞经典永不过时！重温设计模式☞PassMark 更新排行，苹果 M1 杀疯了☞干货！Redis集群工作原理解析

点分享点收藏点点赞点在看