譯者 | 李睿

審校 | 梁策 孫淑娟

如今，“云原生”這一概念已多用來表示應用邏輯和基礎設施(包括數據庫)的最佳實踐集合。然而，早在云計算或云原生概念出現幾十年前，許多支持應用程序運行的數據庫就已存在，只是這些傳統解決方案的數據引力限制了應用程序和工作負載的移動能力。隨著企業將業務遷移到云端，數據存儲方法該怎樣發展?需不需要云原生數據庫?云原生數據庫又意味著什么?以下我們來一一解答。

什么是云原生?

要定義“云原生”，需要先來明白什么是“原生”(Native)。對于個人而言，原生二字可能會讓你聯想到母語、本國或本地之類的概念，亦或是自然界里野生動物的原生棲息地，包括各個物種如何適應所處環境等。因此，我們也從這里出發來理解云原生的含義。

以下是云原生計算基金會(CNCF)對該術語的定義： “云原生技術使企業能夠在公共云、私有云和混合云等現代動態環境中構建和運行可擴展的應用程序，容器、服務網格、微服務、不可變基礎設施以及聲明性API都是典型例子。這些技術使松散耦合的系統具有彈性、可管理性和可觀察性，輔以強大的自動化，工程師可以最少的工作量進行高頻預測性更改。”

這一定義范圍相當寬泛，但來定義云原生數據庫還是有些吃力，就如CNCF景觀圖數據庫部分所示：

數據庫只是龐大的云計算領域中的一小部分

仔細觀察就會發現，這里包含各種各樣的產品：如傳統的關系數據庫和NoSQL數據庫，它們支持各種不同的數據模型，包括鍵/值、文檔和圖形。此外還包括現有數據庫之上的分層聚類、查詢或模式管理技術。這還不包括CNCF領域的其他有關類別，例如用于數據移動的流式傳輸和消息傳遞，或用于持久性的云原生存儲。

這些數據庫中哪些是云原生呢?除了專為云設計的數據庫，是否也包括那些可以適應云中工作的數據庫?在比爾·懷爾德 (Bill Wilder) 2012年出版的《云架構模式》(Cloud Architecture Patterns)一書中，他提出了一個有趣觀點，把“云原生”定義為：“任何經過架構而能充分利用云平臺的應用程序”。

根據這個定義，云原生數據庫就是那些經過架構，能充分利用底層云基礎設施的數據庫。但是，這樣定義也會有爭議。

為什么要關心數據庫是否是云原生?

或者換個方式來問，云原生數據庫有什么優勢?其中，推動云計算普及的兩個主要因素包括：成本和上市時間。

• 成本——即用即付的能力對于提高云采用率至關重要(但不意味著云計算價格低廉或成本管理簡單)。
• 上市時間——快速啟動基礎設施以進行原型設計、開發、測試和交付新應用程序和功能的能力(但不意味著云開發和運營容易)。

就像堆棧選擇中的其他因素一樣，這些目標也適用于數據庫選擇。

云原生數據庫的特征是什么?

現在，我們可以重新審視CNCF的定義，以有助于成本和上市時間目標實現來歸納出云原生數據庫的特征：

• 可擴展性——系統必須能夠動態增加容量，以吸收額外的工作負載。
• 彈性——必須能夠縮減規模，以便用戶只為所需資源付費。
• 恢復能力——系統抵受故障，必須保障不丟失數據。
• 可觀察性——能夠跟蹤活動，以及運行狀況檢查和處理故障轉移。
• 自動化——將操作任務落實為可重復邏輯，以降低出錯可能。這一特性最難實現，但對于實現大規模高交付速度至關重要。

云原生數據庫旨在落實這些要求，這讓它們與那些可以通過一些調整部署到云中的數據庫——“云就緒”數據庫區分開來。

什么最能代表云原生數據庫?

本文以Apache Cassandra™為例來審視云原生數據庫的定義。雖然Cassandra在開發時“云原生”一詞尚未普及，但由于受到了公共云基礎設施的啟發(例如亞馬遜AWS的Dynamo論文和谷歌公司的BigTable)，它在架構影響上有許多相似之處。因為這層關系，Cassandra體現了以下原則：

• Cassandra通過添加節點展示了橫向可擴展性，并且可以彈性縮減，以在高峰負載期之外釋放資源。
• 在默認情況下，Cassandra是一個AP系統，也就是說，它如CAP定理中所述的那樣優先考慮可用性和分區容錯性，而不是一致性。Cassandra的內置復制、無共享架構和自我修復功能有助于保證彈性。
• Cassandra節點公開日志記錄、指標和查詢跟蹤，從而實現可觀察性。
• 自動化是Cassandra最具挑戰性的方面，這也是數據庫常碰到的一個問題。

雖然Cassandra集群自動化的初始部署比較簡單，但其他任務(例如擴展或升級)可能非常耗時且難以自動化。畢竟，即使是對單節點數據庫操作也很有挑戰，許多數據庫管理員也都認同這點。幸運的是，K8ssandra項目為在Kubernetes上部署Cassandra提供了最佳實踐，其中包括在交付運營(“Day 2”)后的自動化操作方面取得了重大進展。

云原生數據庫是否必須在Kubernetes上運行?

有關Kubernetes，當人們談論云中的數據庫時，實際上是在說需要某種存儲的有狀態工作負載。但在云計算世界中，有狀態是個麻煩事。數據引力相當棘手——由于法規和法律的限制，數據可能難以移動，而且成本可能會變得非常高昂。

由于最初不是為有狀態工作負載而設計，在開始使用Kubernetes部署容器化應用程序時，其面臨的挑戰有增無減。目前出現了推動部署數據庫在Kubernetes上運行的新趨勢，以在單一平臺上運行整個堆棧來最大限度地提升開發和運營效率。Kubernetes對云原生數據庫有哪些額外要求呢?

(1)容器化

首先，數據庫必須在容器中運行。這聽起來顯而易見，但也需要做些工作。存儲必須外部化，內存和其他計算資源必須適當調整，應用程序日志和指標必須可用于基礎設施，以進行監控和日志聚合。

(2)存儲

接下來，需要將數據庫的存儲需求映射到Kubernetes架構。每個數據庫節點最起碼要提出一個持久卷聲明，Kubernetes可以使用它來分配具有適當容量和輸入/輸出(I/O)特征的存儲卷。數據庫通常使用Kubernetes狀態集進行部署，這有助于管理存儲卷到pod的映射，并保持一致、可預測的身份。

(3)自動化操作

最后，需要工具來管理和自動化數據庫操作，這當中包括安裝和維護。通常這由Kubernetes操作員模式實現。操作員模式本身是一個控制回路，它觀察Kubernetes資源的狀態，并采取措施以助其實現。這樣的話，它們就類似于Kubernetes的內置控制器，但關鍵區別在于它們了解特定域的狀態，從而幫助Kubernetes做出更好決策。

例如，K8ssandra項目使用cass-operator，它定義了一個名為“Cassandra Datacenter”的Kubernetes自定義資源(CRD)，由它來描述Cassandra集群每個頂級故障域的期望狀態。這比處理有狀態集或單個pod的抽象水平更高。

Kubernetes數據庫操作員通常有助于解答以下問題：

• 故障轉移期間會發生什么?(pod、磁盤、網絡)
• 向外擴展時會發生什么?(pod重新安排)
• 如何執行備份?
• 如何有效檢測和預防故障?
• 軟件如何升級?(滾動重啟)

結論

云原生數據庫是按可擴展性、彈性、韌性、可觀察性和自動化等云原生原則設計的數據庫。就如Cassandra所示，自動化通常是最終關卡，但在Kubernetes中運行數據庫可以有效助力企業朝著這一目標邁進。

原文標題：The Search for a Cloud-Native Databaseby，作者：Pieter Humphrey

原文地址：https://www.51cto.com/article/703313.html