译者 | 李睿

审校 | 梁策 孙淑娟

如今，“云原生”这一概念已多用来表示应用逻辑和基础设施(包括数据库)的最佳实践集合。然而，早在云计算或云原生概念出现几十年前，许多支持应用程序运行的数据库就已存在，只是这些传统解决方案的数据引力限制了应用程序和工作负载的移动能力。随着企业将业务迁移到云端，数据存储方法该怎样发展?需不需要云原生数据库?云原生数据库又意味着什么?以下我们来一一解答。

什么是云原生?

要定义“云原生”，需要先来明白什么是“原生”(Native)。对于个人而言，原生二字可能会让你联想到母语、本国或本地之类的概念，亦或是自然界里野生动物的原生栖息地，包括各个物种如何适应所处环境等。因此，我们也从这里出发来理解云原生的含义。

以下是云原生计算基金会(CNCF)对该术语的定义： “云原生技术使企业能够在公共云、私有云和混合云等现代动态环境中构建和运行可扩展的应用程序，容器、服务网格、微服务、不可变基础设施以及声明性API都是典型例子。这些技术使松散耦合的系统具有弹性、可管理性和可观察性，辅以强大的自动化，工程师可以最少的工作量进行高频预测性更改。”

这一定义范围相当宽泛，但来定义云原生数据库还是有些吃力，就如CNCF景观图数据库部分所示：

数据库只是庞大的云计算领域中的一小部分

仔细观察就会发现，这里包含各种各样的产品：如传统的关系数据库和NoSQL数据库，它们支持各种不同的数据模型，包括键/值、文档和图形。此外还包括现有数据库之上的分层聚类、查询或模式管理技术。这还不包括CNCF领域的其他有关类别，例如用于数据移动的流式传输和消息传递，或用于持久性的云原生存储。

这些数据库中哪些是云原生呢?除了专为云设计的数据库，是否也包括那些可以适应云中工作的数据库?在比尔·怀尔德 (Bill Wilder) 2012年出版的《云架构模式》(Cloud Architecture Patterns)一书中，他提出了一个有趣观点，把“云原生”定义为：“任何经过架构而能充分利用云平台的应用程序”。

根据这个定义，云原生数据库就是那些经过架构，能充分利用底层云基础设施的数据库。但是，这样定义也会有争议。

为什么要关心数据库是否是云原生?

或者换个方式来问，云原生数据库有什么优势?其中，推动云计算普及的两个主要因素包括：成本和上市时间。

成本——即用即付的能力对于提高云采用率至关重要(但不意味着云计算价格低廉或成本管理简单)。上市时间——快速启动基础设施以进行原型设计、开发、测试和交付新应用程序和功能的能力(但不意味着云开发和运营容易)。

就像堆栈选择中的其他因素一样，这些目标也适用于数据库选择。

云原生数据库的特征是什么?

现在，我们可以重新审视CNCF的定义，以有助于成本和上市时间目标实现来归纳出云原生数据库的特征：

可扩展性——系统必须能够动态增加容量，以吸收额外的工作负载。弹性——必须能够缩减规模，以便用户只为所需资源付费。恢复能力——系统抵受故障，必须保障不丢失数据。可观察性——能够跟踪活动，以及运行状况检查和处理故障转移。自动化——将操作任务落实为可重复逻辑，以降低出错可能。这一特性最难实现，但对于实现大规模高交付速度至关重要。

云原生数据库旨在落实这些要求，这让它们与那些可以通过一些调整部署到云中的数据库——“云就绪”数据库区分开来。

什么最能代表云原生数据库?

本文以Apache Cassandra™为例来审视云原生数据库的定义。虽然Cassandra在开发时“云原生”一词尚未普及，但由于受到了公共云基础设施的启发(例如亚马逊AWS的Dynamo论文和谷歌公司的BigTable)，它在架构影响上有许多相似之处。因为这层关系，Cassandra体现了以下原则：

Cassandra通过添加节点展示了横向可扩展性，并且可以弹性缩减，以在高峰负载期之外释放资源。在默认情况下，Cassandra是一个AP系统，也就是说，它如CAP定理中所述的那样优先考虑可用性和分区容错性，而不是一致性。Cassandra的内置复制、无共享架构和自我修复功能有助于保证弹性。Cassandra节点公开日志记录、指标和查询跟踪，从而实现可观察性。自动化是Cassandra最具挑战性的方面，这也是数据库常碰到的一个问题。

虽然Cassandra集群自动化的初始部署比较简单，但其他任务(例如扩展或升级)可能非常耗时且难以自动化。毕竟，即使是对单节点数据库操作也很有挑战，许多数据库管理员也都认同这点。幸运的是，K8ssandra项目为在Kubernetes上部署Cassandra提供了最佳实践，其中包括在交付运营(“Day 2”)后的自动化操作方面取得了重大进展。

云原生数据库是否必须在Kubernetes上运行?

有关Kubernetes，当人们谈论云中的数据库时，实际上是在说需要某种存储的有状态工作负载。但在云计算世界中，有状态是个麻烦事。数据引力相当棘手——由于法规和法律的限制，数据可能难以移动，而且成本可能会变得非常高昂。

由于最初不是为有状态工作负载而设计，在开始使用Kubernetes部署容器化应用程序时，其面临的挑战有增无减。目前出现了推动部署数据库在Kubernetes上运行的新趋势，以在单一平台上运行整个堆栈来最大限度地提升开发和运营效率。Kubernetes对云原生数据库有哪些额外要求呢?

(1)容器化

首先，数据库必须在容器中运行。这听起来显而易见，但也需要做些工作。存储必须外部化，内存和其他计算资源必须适当调整，应用程序日志和指标必须可用于基础设施，以进行监控和日志聚合。

(2)存储

接下来，需要将数据库的存储需求映射到Kubernetes架构。每个数据库节点最起码要提出一个持久卷声明，Kubernetes可以使用它来分配具有适当容量和输入/输出(I/O)特征的存储卷。数据库通常使用Kubernetes状态集进行部署，这有助于管理存储卷到pod的映射，并保持一致、可预测的身份。

(3)自动化操作

最后，需要工具来管理和自动化数据库操作，这当中包括安装和维护。通常这由Kubernetes操作员模式实现。操作员模式本身是一个控制回路，它观察Kubernetes资源的状态，并采取措施以助其实现。这样的话，它们就类似于Kubernetes的内置控制器，但关键区别在于它们了解特定域的状态，从而帮助Kubernetes做出更好决策。

例如，K8ssandra项目使用cass-operator，它定义了一个名为“Cassandra Datacenter”的Kubernetes自定义资源(CRD)，由它来描述Cassandra集群每个顶级故障域的期望状态。这比处理有状态集或单个pod的抽象水平更高。

Kubernetes数据库操作员通常有助于解答以下问题：

故障转移期间会发生什么?(pod、磁盘、网络)向外扩展时会发生什么?(pod重新安排)如何执行备份?如何有效检测和预防故障?软件如何升级?(滚动重启)结论

云原生数据库是按可扩展性、弹性、韧性、可观察性和自动化等云原生原则设计的数据库。就如Cassandra所示，自动化通常是最终关卡，但在Kubernetes中运行数据库可以有效助力企业朝着这一目标迈进。

原文标题：The Search for a Cloud-Native Databaseby，作者：Pieter Humphrey

关键词： 应用程序 基础设施 工作负载 可观察性 可扩展性