如今，很多公司都在利用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 等開源項目的誕生，則為云原生數據庫獲得更高發展提供了絕佳機會，使得更多企業可以在數據架構成熟度方面取得長足猛進的發展。

最后，我們期待更多企業加入到云原生數據庫這個大的技術生態中來，對成熟度模型和相關問題發表更多觀點。