雲原生資料庫成熟度模型分析

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

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