如今，很多公司都在利用Kubernetes以及相關(guān)技術(shù)，將工作負(fù)載遷移到云端。只是，云遷移會(huì)面臨幾個(gè)重要挑戰(zhàn)，比如：如何將數(shù)據(jù)和應(yīng)用遷移上云，如何存儲(chǔ)云上數(shù)據(jù)，涉及哪些核心技術(shù)等等。說白了，云上的各種問題，都與數(shù)據(jù)庫息息相關(guān)。

事實(shí)上，在云原生概念出現(xiàn)之前，企業(yè)一直采用傳統(tǒng)數(shù)據(jù)庫處理各種數(shù)據(jù)問題。云原生概念出現(xiàn)后，企業(yè)有了更靈活的選擇，可以通過更現(xiàn)代化的應(yīng)用程序，讓數(shù)據(jù)庫應(yīng)用更具可擴(kuò)展性，更具彈性，以及更能滿足自動(dòng)化和可視化需求。

問題是，云原生數(shù)據(jù)庫到底是怎樣一種架構(gòu)？為什么那么多企業(yè)選擇云原生路線？本文將推薦幾個(gè)云原生數(shù)據(jù)庫成熟度模型，企業(yè)可以根據(jù)云架構(gòu)實(shí)際情況來評(píng)估，看看更適合哪種技術(shù)堆棧或者應(yīng)用模型！

云應(yīng)用模式演進(jìn)

在傳統(tǒng)云服務(wù)模式下，用戶主要API即服務(wù)的形式獲得服務(wù)，也就是我們常說的基礎(chǔ)架構(gòu)即服務(wù) (IaaS)、平臺(tái)即服務(wù) (PaaS) 和軟件即服務(wù) (SaaS)。

云原生技術(shù)出現(xiàn)后，為用戶帶來了新的體驗(yàn)，通過類似于PaaS模式的“變體”，即容器即服務(wù) (CaaS) 和功能即服務(wù) (FaaS)，企業(yè)可以獲得更好的云上自服務(wù)能力，能以最佳方式編排云上服務(wù)，并且可以讓權(quán)責(zé)分配更明晰。

云原生全景圖詳解(金色部分由云廠商負(fù)責(zé)，藍(lán)色部分由用戶自己負(fù)責(zé))

上述圖片有很多重要信息點(diǎn)，我們可以逐一拆解：

• IaaS：所謂IaaS，是指云提供商只需配置企業(yè)所需要的服務(wù)器，用戶仍然需要配置帳戶并安裝應(yīng)用程序所需的所有組件，包括中間件。
• PaaS：使用PaaS以后，用戶的工作量少了很多，無須經(jīng)過冗繁的配置，就可以將所有組件部署在現(xiàn)有的應(yīng)用程序中，包括服務(wù)器也可以作為平臺(tái)以云的形式提供服務(wù)，用戶可以在上面開發(fā)、運(yùn)行和管理自己的應(yīng)用程序。
• SaaS：SaaS，也被稱為是托管服務(wù)，用戶可以通過 API 使用軟件，這些 API 可以提供更強(qiáng)大、更高級(jí)別以及更抽象的業(yè)務(wù)功能。
• CaaS：CaaS 是提供一種上傳、運(yùn)行、擴(kuò)展以及管理應(yīng)用程序容器的方法，和PaaS一樣，都能幫助開發(fā)人員部署并運(yùn)行應(yīng)用程序。只是，PaaS會(huì)隱藏一部分容器化任務(wù)，有點(diǎn)獨(dú)斷專行。CaaS能更輕松地運(yùn)用多云托管功能，包括可以利用Kubernetes進(jìn)行容器管理。
• FaaS：FaaS，有時(shí)也稱為“無服務(wù)器”，是更抽象的 PaaS 版本，用戶只需要關(guān)注業(yè)務(wù)代碼邏輯，無需關(guān)注服務(wù)器資源。可以說，F(xiàn)aaS提供了一個(gè)更加細(xì)分和抽象的服務(wù)化能力。

值得一提的是，上述這些服務(wù)模式都可以組合使用，比如：企業(yè)可以將自己的業(yè)務(wù)系統(tǒng)部署在基于IaaS的虛擬機(jī) (VM) 上，也可以在基于CaaS 的容器中部署多個(gè)微服務(wù)，或者采用完全來自第三方服務(wù)的SaaS，再或者通過FaaS來協(xié)調(diào)各種服務(wù)之間的工作流以及數(shù)據(jù)流。

云原生數(shù)據(jù)庫成熟度模型

不同云應(yīng)用模式，為云原生架構(gòu)的誕生奠定了堅(jiān)實(shí)的技術(shù)基礎(chǔ)。回到前文提到的云原生數(shù)據(jù)庫以及數(shù)據(jù)服務(wù)成熟度模型問題，我們首先要弄清楚云原生的概念。

根據(jù)Bill Wilder 在其 2012 年的著作《云架構(gòu)模式》中提出的云原生定義：“是指任何可以充分利用云平臺(tái)的應(yīng)用程序。”

根據(jù)這個(gè)定義來理解，IaaS 和 PaaS 可以被稱為“云就緒”，因?yàn)槠髽I(yè)可以按原樣安裝希望臨時(shí)的任何應(yīng)用程序，而無需進(jìn)行調(diào)整。然而，這是以真正的云原生解決方案所提供的靈活性為代價(jià)的。只有 CaaS、SaaS 和 FaaS 才能真正被認(rèn)為是為云架構(gòu)而生。因此，云原生可以認(rèn)為是，代表了云原生架構(gòu)的不同成熟度級(jí)別：

成熟度模型

在此模型中，我們將 CaaS 表示為“Kubernetes 原生”，SaaS 表示為“托管服務(wù)”，F(xiàn)aaS 表示為“無服務(wù)器”。如果我們將“云就緒”成熟度級(jí)別表示為 IaaS/PaaS 作為基線，我們得到一個(gè)看起來像這樣的成熟度模型：

云原生成熟度級(jí)別

讓我們從最不成熟到最成熟，逐一分析這些成熟度級(jí)別。

成熟度級(jí)別0：云數(shù)據(jù)就緒

第一個(gè)成熟度級(jí)別很容易達(dá)到。這是經(jīng)典的提升和轉(zhuǎn)移范式。任何可以部署在 IaaS 上的系統(tǒng)都將被視為云就緒。我們經(jīng)常觀察到的一種模式是，部署在 VM 中的單體應(yīng)用程序，其中包含嵌入式數(shù)據(jù)庫。只要企業(yè)將應(yīng)用程序打包在一個(gè) VM(或多個(gè)VM)中并連接任何所需的網(wǎng)絡(luò)，就可以在云中運(yùn)行它。這是一個(gè)完全有效的部署選項(xiàng)，通常是組織采用云的重要過渡階段，但不能完全被視為云原生。

成熟度級(jí)別1：基于Kubernetes 構(gòu)建的運(yùn)行模式

此級(jí)別通常代表企業(yè)已將單體應(yīng)用程序分解為更小的微服務(wù)狀態(tài)，這些微服務(wù)可以部署在容器中并獨(dú)立擴(kuò)展。這是非常重要的一步，但是像 Docker 這樣的容器技術(shù)本身并不能提供管理應(yīng)用程序生命周期和確保高可用性和可擴(kuò)展性所需的一切。

Docker 運(yùn)行時(shí)和 Docker-compose 非常適合開發(fā)和測試環(huán)境;但對(duì)于生產(chǎn)使用來說，企業(yè)需要監(jiān)控正在發(fā)生的事情并采取行動(dòng)來維持服務(wù)水平，所以以Kubernetes等為代表的容器編排正是為此目的而創(chuàng)建。

眾所周知，Kubernetes發(fā)展迅猛，2020 年云原生計(jì)算基金會(huì) (CNCF) 的一項(xiàng)調(diào)查發(fā)現(xiàn)，92% 的受訪公司在生產(chǎn)中運(yùn)行容器，其中83%的企業(yè)已經(jīng)部署并使用了 Kubernetes。

有意思的是， Kubernetes 在部署微服務(wù)和應(yīng)用程序方面很受歡迎，但是我們卻很少看到數(shù)據(jù)庫部署在上面，這其中的原因是什么？

雖然 ，Kubernetes 最初是為無狀態(tài)工作負(fù)載而設(shè)計(jì)的，但通過最新的改進(jìn)，也可以引入有狀態(tài)應(yīng)用，比如通過Cassandra，就可以有效地將數(shù)據(jù)庫部署到容器中。

但事實(shí)上，我們經(jīng)常看到容器化應(yīng)用程序?qū)⒋鎯?chǔ)職責(zé)委托給在 Kubernetes 之外運(yùn)行的組件架構(gòu)，比如通過虛擬機(jī)或裸機(jī)上運(yùn)行自我管理的數(shù)據(jù)庫。這種方式導(dǎo)致網(wǎng)絡(luò)和安全的復(fù)雜性增加，以及監(jiān)控等功能的重復(fù)。這種轉(zhuǎn)移存儲(chǔ)能力的方式，將云原生數(shù)據(jù)庫推向下一個(gè)成熟度模型。

成熟度級(jí)別 2：托管數(shù)據(jù)服務(wù)

僅在 Kubernetes 等容器化環(huán)境中部署數(shù)據(jù)庫，本身并不足以提供云原生數(shù)據(jù)庫所需要的特性，包括可擴(kuò)展性、彈性、可視化和自動(dòng)化等。

要達(dá)到托管服務(wù)或“數(shù)據(jù)庫即服務(wù)”(DBaaS) 的級(jí)別，企業(yè)需要額外的操作邏輯，例如：維護(hù)操作，包括擴(kuò)展/縮減、備份/恢復(fù)、軟件更新和故障排除，監(jiān)控和可觀察性，包括指標(biāo)、日志記錄和跟蹤等。

例如，cass-operator 是 Cassandra 的開源 Kubernetes 運(yùn)算符，用于處理上述維護(hù)任務(wù)。K8ssandra 是另一個(gè)基于cass-operator 的開源項(xiàng)目，為在 Kubernetes 上部署和運(yùn)行 Cassandra 提供完整的生態(tài)系統(tǒng)。這種方法使企業(yè)可以靈活地創(chuàng)建自己定制化的管理應(yīng)用，該部署近似于第三方 DBaaS 的功能。

只不過，企業(yè)需要的是“數(shù)據(jù)即服務(wù)”，而不僅僅是“數(shù)據(jù)庫即服務(wù)”。所以，要想在數(shù)據(jù)平臺(tái)中提供成熟的 SaaS 解決方案，企業(yè)不僅僅需要支持?jǐn)?shù)據(jù)庫查詢語言(如 CQL 或 SQL)的端點(diǎn)，開發(fā)人員還渴望使用熟悉的語言和框架輕松訪問的API。這就是另一個(gè)開源項(xiàng)目啟動(dòng)背后的最根本原因——一個(gè)名為 Stargate 的數(shù)據(jù)網(wǎng)關(guān)。

Stargate 提供了一個(gè) RESTful API，支持開發(fā)人員習(xí)慣的熟悉的 HTTP 訪問模式，同時(shí)也是一個(gè)新的 GraphQL API，對(duì)于Web 和移動(dòng)應(yīng)用程序以及無模式的面向文檔的 API 特別有用。

成熟度級(jí)別3 ：數(shù)據(jù)的無服務(wù)器模式

即使企業(yè)擁有自己的管理平臺(tái)，或從第三方購買了托管服務(wù)，仍然需要考慮成本問題。

這兩種情況的典型問題是：如何根據(jù)工作負(fù)載的實(shí)際需求調(diào)整部署的資源量，以最大程度地減少浪費(fèi)?即使在像 Cassandra 這樣的高度可擴(kuò)展的彈性系統(tǒng)中，也很難獨(dú)立擴(kuò)展計(jì)算和存儲(chǔ)資源。如果企業(yè)能夠僅擴(kuò)展所需要的數(shù)據(jù)庫部分怎么辦？

FaaS 或無服務(wù)器方式迎來用武之地。通過將 Cassandra 等云原生數(shù)據(jù)庫分解為更小的功能，可以更有效地解耦和管理計(jì)算和存儲(chǔ)利用率。不管是接口、路由器，還是讀取和寫入功能，都成為可擴(kuò)展的獨(dú)立功能。該模式的最大優(yōu)勢是，可以極大地提高資源的利用率，并支持多租戶。

無服務(wù)器的架構(gòu)模式，改變了很多人的觀點(diǎn)，不再考慮類似于“我的數(shù)據(jù)庫可以在 Kubernetes 中運(yùn)行嗎?”這樣的話題，而是轉(zhuǎn)移到“我如何才能為我的特定數(shù)據(jù)庫工作負(fù)載獲得成本最低的解決方案？”

小結(jié)

隨著云計(jì)算實(shí)踐的不斷成熟，我們將云原生架構(gòu)理念和設(shè)計(jì)方法應(yīng)用于我們堆棧的各個(gè)層面，是云原生數(shù)據(jù)庫落地的最有效路徑。筆者認(rèn)為，基于容器化 (CaaS)、托管服務(wù) (SaaS) 和無服務(wù)器 (FaaS) 等最佳實(shí)踐的云原生數(shù)據(jù)庫成熟度模型代表了云中數(shù)據(jù)有效利用的最佳方法論。而K8ssandra 和 Stargate 等開源項(xiàng)目的誕生，則為云原生數(shù)據(jù)庫獲得更高發(fā)展提供了絕佳機(jī)會(huì)，使得更多企業(yè)可以在數(shù)據(jù)架構(gòu)成熟度方面取得長足猛進(jìn)的發(fā)展。

最后，我們期待更多企業(yè)加入到云原生數(shù)據(jù)庫這個(gè)大的技術(shù)生態(tài)中來，對(duì)成熟度模型和相關(guān)問題發(fā)表更多觀點(diǎn)。