作者 | Gaurav Rishi
譯者 | 張鋒
隨著應用容器化的速度加快，Day2服務已經成為一個迫在眉睫的問題。這些Day2服務包括數據管理功能，如備份和災難恢復以及應用程式遷移。在這個雲原生應用容器化的新世界中，微服務通常部署在多個位置（區域、雲、本地），同時使用多種數據服務（MongoDB、Redis、Kafka等）和存儲技術來存儲這些應用狀態。
在這種環境中，傳統基礎設施或基於虛擬機管理程序的解決方案將很難發揮作用，那麼為雲原生應用設計和實施這些數據管理功能的正確架構是什麼呢？你應該如何分析存儲供應商、數據服務供應商和雲供應商提供的各種數據管理選項來確定適合你環境和需求的正確方法呢？本文深入探討了各種數據管理方法在一致性、存儲要求和性能等多個屬性上的優缺點。
定義一個詞彙
首先，我們將解構和簡化技術棧以顯示數據可能在雲原生應用中的位置。
在考慮數據管理時，我們可以在上圖中顯示的一個（或多個）層上進行操作。讓我們列舉這些層：
1、物理存儲
該層包括各種存儲硬體選型，可以將狀態存儲在非易失性存儲器中，並可選擇從NVMe和SSD設備到旋轉型磁碟甚至磁帶的物理介質。它們有不同的外形尺寸，包括陣列和獨立機架伺服器。
物理存儲可以位於：
- 在本地，你可能會遇到來自希捷、西部數據和美光等供應商的存儲硬體。
- 在託管雲提供商的數據中心中。雖然你可能永遠不會接觸物理設備，但你知道它是雲的基礎架構一部分。
2、文件和塊存儲
該軟體層提供文件或塊級結構，以實現從底層物理存儲進行高效的讀寫操作。在文件和塊這兩種情況下，底層存儲可以是獨立的（本地磁碟）或共享的網絡資源（NAS 或 SAN）。
- 塊存儲允許你從本地或遠程磁碟創建具有低延遲並可通過iSCSI和FiberChannel等協議訪問的原始存儲卷。雲供應商上的塊存儲實現包括Amazon EBS和GCE 持久性磁碟。
- 文件存儲使用NFS和SMB等協議為文件語義和操作提供共享存儲。本地常見的文件存儲實現包括來自NetApp和Dell EMC的產品。雲供應商上的文件存儲實現包括 Amazon EFS、Google Cloud Filestore和Azure Files。
這一層通常提供快照功能，按照時間點創建卷的副本來進行保護。此外，在 Kubernetes 環境中，該層提供容器存儲接口 (CSI) 驅動程序來規範化API，讓上層可以使用這些API來調用快照功能。請注意，就所支持的功能而言，並非所有CSI實現都是相同的。
3、數據服務
這一層位於文件/塊存儲實現之上。它提供了各種資料庫實現以及日益流行的存儲類型，即對象（又名 blob）存儲。該層通常與應用程式進行交互，底層資料庫實現基於工作負載和業務邏輯來選擇。對於基於微服務的應用程式，多語言持久性是一種規範，因為每個微服務都會為當前的工作選擇最合適的數據服務。
一些資料庫類型和示例實現的子集包括：
- SQL資料庫：MySQL、PostgreSQL、SQL Server
- NoSQL資料庫：
- 鍵值存儲：Redis、BerkeleyDB
- 時間序列資料庫：InfluxDB 、Prometheus
- 圖資料庫：Neo4j、 GraphDB
- 寬列存儲：Cassandra、Azure Cosmos
- 文檔存儲：MongoDB、CouchDB
- 消息隊列：Kafka、RabbitMQ、Amazon SQS
- 對象存儲1：Amazon S3、Google Cloud Storage、Minio
這些資料庫還有幾個託管實例，稱為資料庫即服務 (DBaaS) 系統。這些通常包括上面列出的資料庫類別之一，有時可以提供自動擴展，同時滿足即服務 ( -aaS ) 業務的消費經濟。DBaaS系統的示例包括 Amazon RDS、MongoDB Atlas和Azure SQL。
從數據保護的角度來看，每個資料庫實現都提供了一組特定的實用程序（ PostgreSQL的pg_dump或WAL-E，MongoDB的mongodump等）來備份和恢復數據。值得注意的是，在一致性、恢復顆粒度和速度方面，許多實用程序具有不同的功能。無論它們是作為獨立實用程序提供還是作為即服務產品的一部分提供，通常僅限於特定的資料庫實現，或者至多是一種資料庫類型。
4、有狀態應用
應用程式層是業務邏輯所在的地方，在雲原生世界中，應用程式通常基於現代敏捷開發並作為分布式微服務實現。幾乎所有應用程式都有一個需要持久化的狀態。雖然有多種存儲應用程式狀態的模式，但我們需要在有狀態的 Kubernetes 應用程式的上下文中將以下信息作為一個原子單元來持久化和保護：
- 應用程式數據：跨各種數據服務、塊和文件存儲實現分布在多個容器上。
- 應用程式定義和配置：應用程式鏡像和相關的環境配置分布在各種 Kubernetes 對象中，包括ConfigMaps、Secrets等。
- 其他配置狀態：包括CI/CD流水線狀態、發布信息和關聯的Helm部署元數據。
上圖為一個有狀態應用程式的示例，它突出顯示了一些需要保護的組件和相關狀態。需要注意的是，對於實際部署，應用程式由數百個這樣的底層組件組成。此外，在雲原生架構中，保護的原子性單元需要是應用程式與底層數據服務或存儲基礎設施層。如前所述，這是因為應用程式的狀態包括分布在多個物理或虛擬節點和數據服務中的應用程式數據、定義和配置。
結論
從備份/恢復和應用程式可移植性的角度來看，一個好的數據管理解決方案需要將整個應用程式視為原子性單元，這使得傳統以管理程序為中心的解決方案不再適用。我們還展示了一個簡單的技術棧圖，從各種數據服務、塊和文件存儲以及跨本地和雲實現物理存儲的角度顯示應用程式狀態實際所在的位置。這定義了一個基本範疇，使我們能夠深入了解雲數據管理的操作層級。
附註
有些人可能爭辯認為對象存儲應該與文件/塊屬於同一層。在本文中，對象存儲將被視為另一種具有鍵值接口的數據服務，如果需要，可以在Kubernetes中運行。
原文連結：https://dzone.com/articles/demystifying-cloud-native-data-management-layers-of-operation
譯者介紹
張鋒，51CTO社區編輯，長期從事技術顧問工作，專注於運維/雲原生領域，精通網絡疑難故障分析，有很豐富的大型銀行運維工具建設實踐經驗。
來源： 51CTO技術棧