翻译|李睿评论|梁策孙淑娟今天，“云原生”的概念大多被用来指代应用逻辑和基础设施（包括数据库）的最佳实践的集合。然而，许多支持应用程序的数据库在云计算或云原生概念出现之前几十年就已经存在，但这些传统解决方案的数据引力限制了移动应用程序和工作负载的能力。随着企业业务上云，数据存储方式应该如何发展？我们需要云原生数据库吗？云原生数据库是什么意思？让我们一一回答。什么是云原生？要定义“云原生”，你需要了解“原生”是什么。对个人来说，本土这个词可能会让你想起母语、本土国家或地方等概念，或者自然界中野生动物的本土栖息地，包括每个物种如何适应环境。因此，我们也从这里开始理解云原生的含义。以下是云原生计算基金会（CNCF）对该术语的定义：“云原生技术使企业能够在公共云、私有云和混合云、容器、服务网格等现代动态环境中构建和运行可扩展的应用程序、微服务、不可变基础设施和声明式API是典型的例子。这些技术使松散耦合的系统具有弹性、可管理和可观察性。借助强大的自动化，工程师可以以最小的努力执行高级操作。频繁的预测更改。”这个定义相当宽泛，但云原生数据库的定义还是有些困难，如CNCF风景图数据库部分所示：数据库只是浩瀚云计算领域中的一小部分，其中包括种类繁多的产品：例如传统的关系数据库和NoSQL数据库，它们支持各种不同的数据模型，包括键/值、文档和图。还包括基于现有数据库的层次聚类、查询或模式管理技术。这不包括CNCF域中的其他相关类别，例如用于数据移动的流媒体和消息传递，或用于持久性的云原生存储。这些数据库中哪些是云原生的？除了为云设计的数据库之外，它们是否还包括那些可以适应在云中工作的数据库？在BillWilder2012年出版的《云架构模式》（CloudArchitecturePatterns）一书中，他提出了一个有趣的观点，将“云原生”定义为：“任何被架构为充分利用云平台的应用程序”。根据这个定义，云原生数据库是那些被设计为充分利用底层云基础设施的数据库。然而，这样的定义也会引起争议。为什么要关心数据库是否是云原生的？或者换个说法，云原生数据库有什么优势？其中，推动云计算普及的两个主要因素包括：成本和上市时间。成本——即付即用的能力对于提高云采用率至关重要（但并不意味着云计算便宜或成本管理容易）。上市时间——快速启动基础设施以进行原型设计、开发、测试和交付新应用程序和功能的能力（但并不意味着轻松的云开发和运营）。这些目标适用于数据库选择，就像堆栈选择中的其他因素一样。云原生数据库有什么特点？现在，我们可以重新审视CNCF的定义来总结云原生数据库的特性，以帮助实现成本和上市时间目标：可扩展性——系统必须能够动态增加容量以吸收额外的工作负载。弹性——必须能够按比例缩小，以便用户只为他们需要的东西付费。弹性-系统具有抗故障能力，必须保证不会丢失数据。可观察性——跟踪活动以及健康检查和处理故障转移的能力。自动化-将操作任务实施为可重复的逻辑，以减少出错的可能性。此功能最难实现，但对于大规模实现高交付速度至关重要。云原生数据库旨在实现这些要求，这使它们有别于那些可以通过一些调整部署在云中的数据库——“云就绪”数据库。什么最能代表云原生数据库？本文以ApacheCassandra?为例，考察云原生数据库的定义。尽管Cassandra是在“云原生”一词尚未流行时开发的，但由于其灵感来自公共云基础设施（例如亚马逊AWS的Dynamo论文和谷歌的BigTable），因此在架构影响方面有许多相似之处。由于这种关系，Cassandra体现了以下原则：Cassandra通过添加节点表现出水平可扩展性，并且可以弹性缩减以释放高峰负载时段之外的资源。默认情况下，Cassandra是一个AP系统，也就是说，如CAP定理所述，它优先考虑可用性和分区容错性而不是一致性。Cassandra的内置复制、无共享架构和自我修复功能有助于确保弹性。Cassandra节点公开日志记录、指标和查询跟踪，从而实现可观察性。自动化是Cassandra最具挑战性的方面，也是数据库的常见问题。虽然自动化Cassandra集群的初始部署很简单，但其他任务（例如扩展或升级）可能非常耗时且难以自动化。毕竟，即使是单节点数据库操作也可能具有挑战性，许多DBA都同意这一点。幸运的是，K8ssandra项目提供了在Kubernetes上部署Cassandra的最佳实践，包括在自动化交付后操作（“第2天”）方面取得的重大进展。云原生数据库必须运行在Kubernetes上吗？对于Kubernetes，当人们谈论云中的数据库时，他们实际上是在谈论需要某种存储的有状态工作负载。但在云计算的世界里，有状态是一件令人讨厌的事情。数据引力是棘手的——由于监管和法律限制，数据可能难以移动，而且它可能变得非常昂贵。由于它最初不是为有状态工作负载设计的，因此使用Kubernetes部署容器化应用程序的挑战只会增加。有一种新趋势正在推动部署在Kubernetes上运行的数据库，以在单一平台上运行整个堆栈，以最大限度地提高开发和运营效率。Kubernetes对云原生数据库有哪些额外要求？(1)容器化首先，数据库必须运行在容器中。这听起来很明显，但也需要一些工作。存储必须外部化，内存和其他计算资源的大小必须适当，并且应用程序日志和指标必须可供基础设施用于监控和日志聚合。(2)存储接下来需要将数据库的存储需求映射到Kubernetes架构上。至少，每个数据库节点都有一个持久卷声明，Kubernetes可以使用它来分配具有适当容量和输入/输出(I/O)特征的存储卷。数据库通常使用Kubernetes有状态集进行部署，这有助于管理存储卷到pod的映射并保持一致、可预测的身份。(3)自动化操作最后，需要工具来管理和自动化数据库操作，包括安装和维护。通常这是由Kubernetes操作符模式实现的。操作符模式本身是一个控制循环，它观察Kubernetes资源的状态并采取行动来帮助实现它。这样，它们类似于Kubernetes的内置控制器，但关键区别在于它们了解特定域的状态，这有助于Kubernetes做出更好的决策。例如，K8ssandra项目使用cass-operator，它定义了一个名为“CassandraDatacenter”的Kubernetes自定义资源(CRD)，它描述了Cassandra集群的每个顶级故障域的期望状态。这是比处理有状态集或单个pod更高级别的抽象。Kubernetes数据库操作员通常有助于回答以下问题：故障转移期间会发生什么？当（容器、磁盘、网络）横向扩展时会发生什么？（pod重新安排）如何执行备份？如何有效检测和预防故障？软件如何升级？（滚动重启）结论云原生数据库是按照可伸缩性、弹性、弹性、可观察性和自动化等云原生原则设计的数据库。正如Cassandra所展示的那样，自动化往往是最后的障碍，但在Kubernetes中运行数据库可以有效地帮助企业朝着这个目标迈进。原标题：TheSearchforaCloud-NativeDatabasebyPieterHumphrey
