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

作者：李代麗 2022-05-24 14:26:11

云計算

云原生

數(shù)據庫 云原生數(shù)據庫到底是怎樣一種架構?為什么那么多企業(yè)選擇云原生路線?本文將推薦幾個云原生數(shù)據庫成熟度模型，企業(yè)可以根據云架構實際情況來評估，看看更適合哪種技術堆?；蛘邞媚Ｐ停?/p>

站在用戶的角度思考問題，與客戶深入溝通，找到高坪網站設計與高坪網站推廣的解決方案，憑借多年的經驗，讓設計與互聯(lián)網技術結合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網站設計、做網站、企業(yè)官網、英文網站、手機端網站、網站推廣、域名與空間、網站空間、企業(yè)郵箱。業(yè)務覆蓋高坪地區(qū)。

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

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

問題是，云原生數(shù)據庫到底是怎樣一種架構？為什么那么多企業(yè)選擇云原生路線？本文將推薦幾個云原生數(shù)據庫成熟度模型，企業(yè)可以根據云架構實際情況來評估，看看更適合哪種技術堆?；蛘邞媚Ｐ停?/p>

云應用模式演進

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

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

云原生全景圖詳解(金色部分由云廠商負責，藍色部分由用戶自己負責)

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

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

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

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

不同云應用模式，為云原生架構的誕生奠定了堅實的技術基礎?；氐角拔奶岬降脑圃鷶?shù)據庫以及數(shù)據服務成熟度模型問題，我們首先要弄清楚云原生的概念。

根據Bill Wilder 在其 2012 年的著作《云架構模式》中提出的云原生定義：“是指任何可以充分利用云平臺的應用程序?！?/p>

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

成熟度模型

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

云原生成熟度級別

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

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

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

成熟度級別1：基于Kubernetes 構建的運行模式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小結

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

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

分享標題：云原生數(shù)據庫成熟度模型分析
網址分享：http://www.dlmjj.cn/article/cdieogp.html