云原生景观：应用程序定义和开发层解决了什么问题？如何解决的？

Posted 2021-04-02 容器魔方

应用程序定义和开发层是Cloud Native Computing Foundation的Cloud Native景观的第四层。

顾名思义，应用程序定义和开发层，是侧重于帮助工程师构建应用程序并使其运行的工具。我们在前几篇文章中讨论的所有内容都与构建可靠，安全的环境以及提供所有必需的应用程序依赖关系有关。

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

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

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

数据库

是什么?

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

它确保数据被存储，只有授权用户才能访问它，并允许用户通过专门的请求来检索它。尽管有许多不同类型的数据库，但它们最终都具有相同的目标。

解决了什么问题?

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

它如何解决?

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

相应的解决工具

我们已经确定数据库管理系统是一个存储和检索数据的应用程序。它使用一种公共语言和界面来做到这一点，并且可以被多种不同的语言和框架轻松使用。

通常，我们看到两种数据库类型：结构化查询语言（SQL）数据库和NoSQL数据库。应用程序使用哪个数据库应该由其需求和约束来驱动。

随着Kubernetes的兴起及其支持有状态应用程序的能力，我们已经看到了利用容器化的新一代数据库。这些新的云原生数据库旨在将Kubernetes的扩展性和可用性优势带入数据库。诸如YugaByte和Couchbase之类的工具是云原生数据库的示例。Vitess和TiKV是该领域的CNCF项目。

备注

如果你查看此类别，你会注意到以DB结尾的多个名称（例如MongoDB，CockroachDB，FaunaDB），和以SQL结尾的各种名称（例如mysql或memSQL），他们多数是传统的数据库。还有一些新兴的数据库，例如YugaByte和Vitess。

流媒体和消息传递

是什么?

流和消息传递工具，通过在系统之间传输消息（即事件）来实现服务到服务的通信。它不是网络层，而是用于对消息进行排队和处理的工具。

解决了什么问题?

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

它如何解决?

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

通过引入管理所有通信的“中间层”，我们使服务彼此分离。他们只是监视事件，采取行动并发布新事件。

这有助于建立高度分离的体系结构，使服务可以协作而无需彼此了解。这种解耦使工程师能够添加新功能，而无需更新下游应用程序（消费者）或发送大量查询。系统的解耦越多，更改的灵活性和适应性就越高。而这正是工程师在系统中所追求的。

相应的解决工具

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

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

其中，NATS提供成熟的邮件系统，Cloudevents是用于消息格式的标准化。Strimzi，Pravega和Tremor都是围绕流和消息传递的独特用例量身定制的。

应用程序定义和镜像构建

是什么?

应用程序定义和镜像构建是一个广泛的类别，可以分为两个主要类别。首先，以开发人员为重点的工具可帮助将应用程序代码构建到容器或Kubernetes中。其次，以运维为中心的工具以标准化方式部署应用。无论是加快或简化你的开发环境，提供标准化的方式来部署第三方应用程序，还是简化编写Kubernetes扩的过程，此类别都可以作为优化许多项目和产品的统筹工具。

解决了什么问题?

Kubernetes和容器化环境非常灵活且功能强大。这种灵活性也带来了复杂性，主要是针对各种经常使用的新用例提供了众多配置选项。

开发人员必须将其代码容器化，并具有在生产环境中进行开发的能力。随着发布计划的迅速完成，运营商需要一种标准化的方法来将应用程序部署到容器环境中。

它如何解决?

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

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

相应的解决工具

该领域的工具可以解决以开发人员为中心的问题，例如如何正确编写，打包，测试或运行自定义应用程序，也可以解决以运维人员为中心的问题，例如部署和管理应用程序。

Helm是该类别中唯一一个毕业的项目，它支持许多应用程序部署模式。Helm足够灵活，允许用户自定义自己的应用程序部署。

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

这个空间还有很多，要探索所有这些都需要专门的文章。但是，如果你想让开发人员和运维人员更轻松地使用Kubernetes，请进一步研究这些工具。你可能会找到满足你需求的东西。

持续集成和持续交付

是什么?

持续集成（CI）和持续交付（CD）工具可通过质量保证实现快速高效的开发。使开发人员能够自动测试代码，自动打包，甚至还可以自动部署到生产环境中。

持续集成（CI）通过立即构建和测试代码来确保代码能够产生可部署的应用程序，从而自动执行代码更改。持续交付（CD）向前迈出了一步，并推动了应用程序进入部署阶段。

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

解决了什么问题?

构建和部署应用程序是一个困难且容易出错的过程。特别是在涉及大量人工干预和手动步骤的情况下。开发人员如果长时间没有集成代码，识别错误所花费的时间就越长，并且修复起来就越困难。通过定期集成代码，可以及早发现错误并更轻松地排除故障。

尽管Kubernetes之类的工具为运行和管理应用程序提供了极大的灵活性，但它们也为CI/CD工具带来了新的挑战和机遇。云原生CI/CD系统能够利用Kubernetes本身来构建，运行和管理CI/CD流程，通常称为流水线。

Kubernetes还提供有关我们应用程序运行状况的信息，从而使云原生CI/CD工具能够更轻松地确定应用程序的更改是否成功或是否需要回滚。

它如何解决?

持续集成（CI）工具可确保开发人员引入的任何代码更改或更新自动，连续地构建，验证并与其他更改集成。每次开发人员添加更新时，都会触发自动测试，以确保只有好的代码才能将其导入系统。

CD扩展了CI，包括将CI流程的结果推送到准生产和生产的环境中。

相应的解决工具

云原生开发的到来改变了CI/CD系统。诸如Jenkins之类的一些传统工具已经过完善迭代以更好地适应Kubernetes生态系统。Flux和Argo等其他公司率先开发了一种被称为GitOps的连续交付新方法。

结论

如我们所见，应用程序定义和开发层中的工具使工程师能够构建云原生应用程序。你将找到用于存储和检索数据的数据库，或者允许解耦的，精心设计的体系结构的流和消息传递工具。

应用程序定义和镜像构建工具包含可改善开发人员和运维人员体验的多种技术，CI/CD可确保代码处于可部署状态，并帮助工程师尽早发现任何错误，从而确保更好的代码质量。

文章来源：K8s中文社区

译者：王延飞

原文链接：http://mtw.so/5GRZww

推荐阅读

扫描二维码 ｜ 加入技术交流群