作者：GauravRishi译者|张峰审稿人|Noe 随着应用容器化的加速，Day2服务成为迫在眉睫的问题。这些Day2服务包括数据管理功能，例如备份和灾难恢复以及应用程序迁移。在这个云原生应用程序容器化的新世界中，微服务通常部署在多个位置（区域、云、本地），同时使用多种数据服务（MongoDB、Redis、Kafka等）和存储技术来存储这些应用程序状态. 传统基础架构或基于管理程序的解决方案将难以在这种环境中发挥作用，那么为云原生应用程序设计和实施这些数据管理功能的正确架构是什么？您应该如何分析存储供应商、数据服务提供商和云提供商提供的各种数据管理选项，以确定适合您的环境和需求的正确方法？本文针对一致性、存储要求和性能等多个属性深入探讨了各种数据管理方法的优缺点。定义词汇 首先，我们将解构和简化技术堆栈，以显示数据在云原生应用程序中的位置。 在考虑数据管理时，我们可以在上图中显示的一个（或多个）层上进行操作。让我们列举一下等级： 1。物理存储 这一层包括各种存储硬件选项，可以将状态存储在非易失性内存中，选项范围从NVMe和SSD设备到旋转磁盘，甚至是磁带的物理介质。它们具有不同的外形，包括阵列和独立机架服务器。 物理存储可以位于： 在本地，您可能会遇到来自Seagate、WesternDigital和Micron等供应商的存储硬件。 在托管云提供商的数据中心。虽然您可能永远不会接触物理设备，但您知道它是云基础设施的一部分。 2。文件和块存储该软件层提供文件或块级结构，以支持从底层物理存储进行高效的读写操作。在文件和块的情况下，底层存储可以是独立的（本地磁盘）或共享网络资源（NAS或SAN）。块存储允许您以低延迟从本地或远程磁盘创建原始存储卷，并可通过iSCSI和FiberChannel等协议访问。云提供商上的块存储实现包括AmazonEBS和GCEPersistentDisk。文件存储使用NFS和SMB等协议为文件语义和操作提供共享存储。常见的本地文件存储实施包括NetApp和DellEMC的产品。云提供商上的文件存储实现包括AmazonEFS、GoogleCloudFilestore和AzureFiles。该层通常提供快照功能，创建卷的时间点副本以进行保护。另外，在Kubernetes环境中，这一层提供了一个容器存储接口（CSI）驱动来规范API，以便上层可以使用这些API来调用快照功能。请注意，并非所有CSI实现在支持的功能方面都是平等的。 3。数据服务这一层位于文件/块存储实现之上。它提供各种数据库实现以及越来越流行的存储类型，对象（又名blob）存储。该层通常与应用程序交互，并根据工作负载和业务逻辑选择底层数据库实现。对于基于微服务的应用程序，多语言持久化是常态，因为每个微服务都会为当前作业选择最合适的数据服务。 一些数据库类型和示例实现的子集包括： SQL数据库：MySQL、PostgreSQL、SQLServer NoSQL数据库： 键值存储：Redis、BerkeleyDB 时间序列数据库：InfluxDB、Prometheus 图数据库：Neo4j、GraphDB 宽列存储：Cassandra、AzureCosmos 文档存储：MongoDB、CouchDB 消息队列：Kafka、RabbitMQ、AmazonSQS 对象存储1：AmazonS3、GoogleCloudStorage、Minio这些数据库还有几个托管实例，称为数据库即服务(DBaaS)系统。这些通常包括上面列出的数据库类别之一，有时可以提供自动扩展，同时满足即服务(aaS)业务的消费者经济学。DBaaS系统的示例包括AmazonRDS、MongoDBAtlas和AzureSQL。从数据保护的角度来看，每个数据库实现都提供一组特定的实用程序（用于PostgreSQL的pg_dump或WAL-E，用于MongoDB的mongodump等）来备份和恢复数据。值得注意的是，许多实用程序在一致性、恢复粒度和速度方面具有不同的功能。无论它们是作为独立实用程序提供还是作为服务产品的一部分提供，它们通常仅限于特定的数据库实现，或至多一种数据库类型。 4。有状态应用程序应用程序层是业务逻辑所在的位置。在云原生世界中，应用程序通常基于现代敏捷开发并实现为分布式微服务。几乎所有的应用程序都有一个需要持久化的状态。虽然有多种存储应用程序状态的模式，但我们需要在有状态Kubernetes应用程序的上下文中将以下信息作为原子单元进行持久化和保护： 应用程序数据：跨各种数据服务，块和文件存储实现是分布式的跨多个容器。 应用定义和配置：应用镜像和相关环境配置分布在各个Kubernetes对象中，包括ConfigMaps、Secrets等。 其他配置状态：包括CI/CD流水线状态、发布信息、关联的Helm部署元数据. 上图是一个有状态应用程序的示例，它突出显示了一些需要保护的组件和相关状态。重要的是要注意，对于实际部署，应用程序由数百个这样的低级组件组成。此外，在云原生架构中，保护的原子单元需要是应用程序和底层数据服务或存储基础设施层。如前所述，这是因为应用程序的状态由分布在多个物理或虚拟节点和数据服务中的应用程序数据、定义和配置组成。结论 从备份/恢复和应用程序可移植性的角度来看，一个好的数据管理解决方案需要将整个应用程序视为一个原子单元，使得传统的以管理程序为中心的解决方案不再适用。我们还展示了一个简单的技术堆栈图，显示了应用程序状态在各种数据服务、块和文件存储以及跨本地和云实施的物理存储方面的实际位置。这定义了一个基本类别，使我们能够深入了解云数据管理的操作级别。 注意 有人可能会争辩说对象存储应该与文件/块处于同一层。在本文中，对象存储将被视为另一种具有键值接口的数据服务，如果需要可以在Kubernetes中运行。 原文链接：https://dzone.com/articles/demystifying-cloud-native-data-management-layers-of-operation译者介绍张峰，社区编辑，长期从事技术咨询工作期间，专注于运维/云原生领域，精通疑难网络故障分析，在大型银行运维工具建设方面具有丰富的实践经验。
