如今，许多公司都在使用Kubernetes和相关技术将工作负载迁移到云端。然而，云迁移将面临几个重要的挑战，例如：如何将数据和应用程序迁移到云端，如何将数据存储在云端，涉及到哪些核心技术等等。说白了，云上的各种问题都和数据库息息相关。事实上，在云原生概念出现之前，企业一直在使用传统数据库来处理各种数据问题。云原生概念出现后，企业有了更灵活的选择，可以使用更多现代应用，让数据库应用更具扩展性、弹性，更能满足自动化和可视化需求。问题是，什么样的架构才是云原生数据库？为什么那么多企业选择云原生路线？本文将推荐几种云原生数据库成熟度模型。企业可以根据云架构的实际情况进行评估，看看哪种技术栈或应用模型更适合！云应用模型演进在传统的云服务模型中，用户主要以API即服务的形式获取服务，也就是我们常说的基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（软件即服务）。云原生技术出现后，给用户带来了全新的体验。通过类似于PaaS模式的“变种”，即容器即服务（CaaS）和功能即服务（FaaS），企业可以获得更好的云端自助服务。服务能力，可以对云服务进行最佳编排，权责分工更加清晰。云原生全景详解（金色部分为云提供商负责，蓝色部分为用户自己负责）。上图包含了很多重要的信息点，我们可以一一拆解：IaaS：所谓IaaS就是云提供商只需要配置企业的一台服务器即可，用户还需要配置一个账号和安装应用程序所需的所有组件，包括中间件。PaaS：使用PaaS后，用户的工作量少了很多，所有的组件都可以部署在现有的应用程序中，不需要复杂的配置，包括服务器也可以作为一个平台，以云的形式提供服务，用户可以自行开发，在上面运行和管理您自己的应用程序。SaaS：SaaS，也称为托管服务，允许用户通过提供更强大、更高层次、更抽象的业务功能的API来使用软件。CaaS：CaaS提供了一种上传、运行、扩展和管理应用程序容器的方式。与PaaS一样，它可以帮助开发人员部署和运行应用程序。只是PaaS会隐藏一些容器化的任务，有点武断。CaaS使利用多云托管功能变得更加容易，包括利用Kubernetes进行容器管理。FaaS：FaaS，有时也称为“无服务器”，是PaaS的更抽象版本。用户只需关注业务代码逻辑，无需关注服务器资源。可以说，FaaS提供了一种更加细分和抽象的面向服务的能力。值得一提的是，以上所有服务模式都可以组合使用。例如，企业可以将自己的业务系统部署在基于IaaS的虚拟机（VM）上，或者将多个微服务部署在基于CaaS的容器中。或者完全从第三方服务使用SaaS，或者使用FaaS来协调各个服务之间的工作流和数据流。云原生数据库成熟度模型和不同的云应用模型为云原生架构的诞生奠定了坚实的技术基础。回到上文提到的云原生数据库和数据服务成熟度模型问题，首先要明确云原生的概念。根据BillWilder在2012年的《云架构模式》一书中提出的云原生定义：“指的是任何能够充分利用云平台的应用程序。”根据这个定义，IaaS和PaaS可以称为“云就绪”，因为企业可以按原样安装他们想要的任何应用程序，无需调整。然而，这是以牺牲真正的云原生解决方案所提供的灵活性为代价的。只有CaaS、SaaS和FaaS才能真正被视为云架构的原生。因此，云原生可以被认为代表了云原生架构的不同成熟度级别：一个成熟度模型服务器。如果我们将“云就绪”成熟度级别表示为IaaS/PaaS作为基线，我们得到一个成熟度模型看起来像这样：CloudNativeMaturityLevels让我们从最不成熟到最成熟来分析这些成熟度级别。成熟度级别0：云数据就绪第一个成熟度级别很容易达到。这是经典的提升和转移范式。任何系统可以部署在IaaS上的将被视为云就绪。我们经常观察到的一种模式是部署在VM中的单体应用程序，其中包含嵌入式数据库。只要您将应用程序打包在一个VM（或多个VM）中并连接它到任何所需的网络，你可以在云中运行它。这是一个非常有效的部署选项，通常是组织采用云的重要过渡阶段，但不能完全认为它是云原生的。Maturity级别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提供了一个RESTfulAPI，它支持开发人员习惯的熟悉的HTTP访问模式，以及一个新的GraphQLAPI，该API对于Web和移动应用程序以及无模式的面向文档的API特别有用。成熟度3级：无服务器数据即使您拥有自己的管理平台，或从第三方购买托管，您仍然需要考虑成本。这两种情况的典型问题是：如何根据工作负载的实际需求调整部署资源的数量，以最大限度地减少浪费？即使在像Cassandra这样高度可扩展的弹性系统中，也很难独立扩展计算和存储资源。如果企业只能扩展他们需要的数据库部分会怎样？FaaS或无服务器方法来了。通过将Cassandra等云原生数据库分解为更小的功能，可以更有效地分离和管理计算和存储利用率。无论是接口、路由器，还是读写功能，都成为可扩展的独立功能。这种模式最大的优点是可以大大提高资源利用率，支持多租户。Serverless架构模式改变了很多人的视角，不再思考“我的数据库能跑在Kubernetes上吗？”这样的话题。并转向“我怎样才能获得成本最低的解决方案？”总结随着云计算实践的不断成熟，我们将云原生的架构理念和设计方法应用到我们栈的各个层次，是实现云原生数据库最有效的方式，笔者认为，一个云原生数据库的成熟度基于容器化（CaaS）、托管服务（SaaS）、无服务器（FaaS）等最佳实践的模型代表了云端数据高效使用的最佳方法论，K8ssandra、Stargate等开源项目的诞生提供了极好的云原生数据库获得更高发展的契机，让更多的企业在数据架构的成熟度上有了长足的进步，最后，我们期待更多的企业加入到云原生数据库的大技术生态中，对成熟度模型发表更多的看法及相关问题。
