作者 | Gaurav Rishi
譯者 | 張鋒
審校 | Noe
隨著應用容器化的速度加快，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社區編輯，長期從事技術顧問工作，專注于運維/云原生領域，精通網絡疑難故障分析，有很豐富的大型銀行運維工具建設實踐經驗。
