如今，很多公司都在利用Kubernetes以及相关技术，将工作负载迁移到云端。只是，云迁移会面临几个重要挑战，比如：如何将数据和应用迁移上云，如何存储云上数据，涉及哪些核心技术等等。说白了，云上的各种问题，都与数据库息息相关。

　　事实上，在云原生概念出现之前，企业一直采用传统数据库处理各种数据问题。云原生概念出现后，企业有了更灵活的选择，可以通过更现代化的应用程序，让数据库应用更具可扩展性，更具弹性，以及更能满足自动化和可视化需求。

　　问题是，云原生数据库到底是怎样一种架构?为什么那么多企业选择云原生路线?本文将推荐几个云原生数据库成熟度模型，企业可以根据云架构实际情况来评估，看看更适合哪种技术堆栈或者应用模型!

　　云应用模式演进

　　在传统云服务模式下，用户主要API即服务的形式获得服务，也就是我们常说的基础架构即服务 (IaaS)、平台即服务 (PaaS) 和软件即服务 (SaaS)。

　　云原生技术出现后，为用户带来了新的体验，通过类似于PaaS模式的“变体”，即容器即服务 (CaaS) 和功能即服务 (FaaS)，企业可以获得更好的云上自服务能力，能以最佳方式编排云上服务，并且可以让权责分配更明晰。

　　云原生全景图详解(金色部分由云厂商负责，蓝色部分由用户自己负责)

　　上述图片有很多重要信息点，我们可以逐一拆解：

　　IaaS：所谓IaaS，是指云提供商只需配置企业所需要的服务器，用户仍然需要配置帐户并安装应用程序所需的所有组件，包括中间件。

　　PaaS：使用PaaS以后，用户的工作量少了很多，无须经过冗繁的配置，就可以将所有组件部署在现有的应用程序中，包括服务器也可以作为平台以云的形式提供服务，用户可以在上面开发、运行和管理自己的应用程序。

　　SaaS：SaaS，也被称为是托管服务，用户可以通过 API 使用软件，这些 API 可以提供更强大、更高级别以及更抽象的业务功能。

　　CaaS：CaaS 是提供一种上传、运行、扩展以及管理应用程序容器的方法，和PaaS一样，都能帮助开发人员部署并运行应用程序。只是，PaaS会隐藏一部分容器化任务，有点独断专行。CaaS能更轻松地运用多云托管功能，包括可以利用Kubernetes进行容器管理。

　　FaaS：FaaS，有时也称为“无服务器”，是更抽象的 PaaS 版本，用户只需要关注业务代码逻辑，无需关注服务器资源。可以说，FaaS提供了一个更加细分和抽象的服务化能力。

　　值得一提的是，上述这些服务模式都可以组合使用，比如：企业可以将自己的业务系统部署在基于IaaS的虚拟机 (VM) 上，也可以在基于CaaS 的容器中部署多个微服务，或者采用完全来自第三方服务的SaaS，再或者通过FaaS来协调各种服务之间的工作流以及数据流。

　　云原生数据库成熟度模型

　　不同云应用模式，为云原生架构的诞生奠定了坚实的技术基础。回到前文提到的云原生数据库以及数据服务成熟度模型问题，我们首先要弄清楚云原生的概念。

　　根据Bill Wilder 在其 2012 年的著作《云架构模式》中提出的云原生定义：“是指任何可以充分利用云平台的应用程序。”

　　根据这个定义来理解，IaaS 和 PaaS 可以被称为“云就绪”，因为企业可以按原样安装希望临时的任何应用程序，而无需进行调整。然而，这是以真正的云原生解决方案所提供的灵活性为代价的。只有 CaaS、SaaS 和 FaaS 才能真正被认为是为云架构而生。因此，云原生可以认为是，代表了云原生架构的不同成熟度级别：

　　成熟度模型

　　在此模型中，我们将 CaaS 表示为“Kubernetes 原生”，SaaS 表示为“托管服务”，FaaS 表示为“无服务器”。如果我们将“云就绪”成熟度级别表示为 IaaS/PaaS 作为基线，我们得到一个看起来像这样的成熟度模型：

　　云原生成熟度级别

　　让我们从最不成熟到最成熟，逐一分析这些成熟度级别。

　　成熟度级别0：云数据就绪

　　第一个成熟度级别很容易达到。这是经典的提升和转移范式。任何可以部署在 IaaS 上的系统都将被视为云就绪。我们经常观察到的一种模式是，部署在 VM 中的单体应用程序，其中包含嵌入式数据库。只要企业将应用程序打包在一个 VM(或多个VM)中并连接任何所需的网络，就可以在云中运行它。这是一个完全有效的部署选项，通常是组织采用云的重要过渡阶段，但不能完全被视为云原生。

　　成熟度级别1：基于Kubernetes 构建的运行模式

　　此级别通常代表企业已将单体应用程序分解为更小的微服务状态，这些微服务可以部署在容器中并独立扩展。这是非常重要的一步，但是像 Docker 这样的容器技术本身并不能提供管理应用程序生命周期和确保高可用性和可扩展性所需的一切。

　　Docker 运行时和 Docker-compose 非常适合开发和测试环境;但对于生产使用来说，企业需要监控正在发生的事情并采取行动来维持服务水平，所以以Kubernetes等为代表的容器编排正是为此目的而创建。

　　众所周知，Kubernetes发展迅猛，2020 年云原生计算基金会 (CNCF) 的一项调查发现，92% 的受访公司在生产中运行容器，其中83%的企业已经部署并使用了 Kubernetes。

　　有意思的是， Kubernetes 在部署微服务和应用程序方面很受欢迎，但是我们却很少看到数据库部署在上面，这其中的原因是什么?

　　虽然 ，Kubernetes 最初是为无状态工作负载而设计的，但通过最新的改进，也可以引入有状态应用，比如通过Cassandra，就可以有效地将数据库部署到容器中。

　　但事实上，我们经常看到容器化应用程序将存储职责委托给在 Kubernetes 之外运行的组件架构，比如通过虚拟机或裸机上运行自我管理的数据库。这种方式导致网络和安全的复杂性增加，以及监控等功能的重复。这种转移存储能力的方式，将云原生数据库推向下一个成熟度模型。

　　成熟度级别 2：托管数据服务

　　仅在 Kubernetes 等容器化环境中部署数据库，本身并不足以提供云原生数据库所需要的特性，包括可扩展性、弹性、可视化和自动化等。

　　要达到托管服务或“数据库即服务”(DBaaS) 的级别，企业需要额外的操作逻辑，例如：维护操作，包括扩展/缩减、备份/恢复、软件更新和故障排除，监控和可观察性，包括指标、日志记录和跟踪等。

　　例如，cass-operator 是 Cassandra 的开源 Kubernetes 运算符，用于处理上述维护任务。K8ssandra 是另一个基于cass-operator 的开源项目，为在 Kubernetes 上部署和运行 Cassandra 提供完整的生态系统。这种方法使企业可以灵活地创建自己定制化的管理应用，该部署近似于第三方 DBaaS 的功能。

　　只不过，企业需要的是“数据即服务”，而不仅仅是“数据库即服务”。所以，要想在数据平台中提供成熟的 SaaS 解决方案，企业不仅仅需要支持数据库查询语言(如 CQL 或 SQL)的端点，开发人员还渴望使用熟悉的语言和框架轻松访问的API。这就是另一个开源项目启动背后的最根本原因——一个名为 Stargate 的数据网关。

　　Stargate 提供了一个 RESTful API，支持开发人员习惯的熟悉的 HTTP 访问模式，同时也是一个新的 GraphQL API，对于Web 和移动应用程序以及无模式的面向文档的 API 特别有用。

　　成熟度级别3 ：数据的无服务器模式

　　即使企业拥有自己的管理平台，或从第三方购买了托管服务，仍然需要考虑成本问题。

　　这两种情况的典型问题是：如何根据工作负载的实际需求调整部署的资源量，以最大程度地减少浪费?即使在像 Cassandra 这样的高度可扩展的弹性系统中，也很难独立扩展计算和存储资源。如果企业能够仅扩展所需要的数据库部分怎么办?

　　FaaS 或无服务器方式迎来用武之地。通过将 Cassandra 等云原生数据库分解为更小的功能，可以更有效地解耦和管理计算和存储利用率。不管是接口、路由器，还是读取和写入功能，都成为可扩展的独立功能。该模式的最大优势是，可以极大地提高资源的利用率，并支持多租户。

　　无服务器的架构模式，改变了很多人的观点，不再考虑类似于“我的数据库可以在 Kubernetes 中运行吗?”这样的话题，而是转移到“我如何才能为我的特定数据库工作负载获得成本最低的解决方案?”

　　小结

　　随着云计算实践的不断成熟，我们将云原生架构理念和设计方法应用于我们堆栈的各个层面，是云原生数据库落地的最有效路径。笔者认为，基于容器化 (CaaS)、托管服务 (SaaS) 和无服务器 (FaaS) 等最佳实践的云原生数据库成熟度模型代表了云中数据有效利用的最佳方法论。而K8ssandra 和 Stargate 等开源项目的诞生，则为云原生数据库获得更高发展提供了绝佳机会，使得更多企业可以在数据架构成熟度方面取得长足猛进的发展。

　　最后，我们期待更多企业加入到云原生数据库这个大的技术生态中来，对成熟度模型和相关问题发表更多观点。