如今，許多組織正在將采用云原生平臺作為其數字轉型戰略。云原生允許企業以更靈活的方式提供快速響應、用戶友好的應用程序。但是，支持云原生轉換的數據體系結構常常被忽略，希望它會自行處理。隨著數據成為每個組織的信息貨幣，企業如何在云計算轉型過程中避免常見的數據錯誤?在構建云原生應用程序時，應該知道哪些數據問題?如何從數據中獲得有價值的見解?

[[230147]]

以下將闡述企業在向云原生轉型過渡時必須考慮的六個關鍵因素：

(1)放棄面向服務體系結構(SOA)，采用微服務

盡管仍有許多遺留應用程序仍然是基于面向服務體系結構(SOA)的，但架構思維已經發生了變化，并且微服務獲得了廣泛的普及。開發人員可以通過創建許多協同工作的獨立服務來獲得許多益處，而不是構建單一應用程序。微服務架構在應用程序開發和簡單的代碼庫中提供更高的靈活性。可以獨立地實現更新和擴展服務，其服務可以采用不同的語言編寫，并連接到不同的數據層和選擇的平臺。這種策略允許開發人員和運營人員以更加和諧的方式一起工作。這種組件化架構需要一個數據庫平臺，可以輕松支持不同的數據類型、結構和編程語言。

(2)12-Factor App和云原生微服務

“十二要素應用程序”(12-Factor App)是一套幫助組織構建云原生應用程序的規則和準則。它是一個很好的起點，但是在數據平臺方面，有幾個因素(第4個和第5個)需要進一步檢查。

第4個因素：將支持服務視為附加資源：這里的“支持服務”大部分是指數據庫和數據存儲。這意味著微服務需要模式和底層數據存儲的專用單一所有權。

第5個因素：嚴格分離構建和運行階段，單獨的構建和運行階段意味著應用程序應該作為一個更多的無狀態進程執行，并且狀態通常被加載到后臺服務上。這進一步意味著數據庫和數據存儲應該是有狀態的服務。

(3)持續集成/持續交付

服務流程的擴散(每個服務可獨立部署)需要自動部署和回滾機制，這稱之為持續集成或持續交付(CI/CD)。實際上，如果沒有成熟的CI/CD功能，微服務的價值就無法完全實現。請注意，這種瞬態架構意味著數據庫實例也將是短暫的，并且它們還必須能夠根據需要輕松啟動。借助正確的云原生平臺和支持數據平臺，微服務變得易于部署。云原生平臺應處理對其運行的服務的管理，并且數據庫應處理數據擴展和監視，在必要事件中添加碎片，重新平衡、重定位或故障轉移。組合的數據庫和云原生解決方案減輕了監控數據庫和平臺的運營負擔，使企業可以花更多時間來開發和部署優質軟件。

(4)多云部署模型的重要性

如今的企業采用多云策略是出于多種原因：準備災難恢復情況，利用不同云計算基礎設施中托管應用程序之間的財務差異，增強安全性，或簡單地避免供應商鎖定。企業的應用程序代碼應該獨立于預期運行的平臺。

(5)整體與非整體

數據訪問和數據移動的傳統方法是令人望而卻步的。傳統方法涉及在其他運營數據存儲和數據倉庫/數據湖中的主數據存儲中創建數據的副本，其中數據在數小時或數天后更新，通常是批量更新。由于組織采用微服務和設計模式，數據在不同類型的數據存儲中傳輸的延遲阻礙了敏捷性，并阻止組織推進其業務計劃。

隨著采用扼殺模式逐漸將單一應用程序遷移到微服務架構，逐漸用新的應用程序和服務取代特定的功能。這意味著關聯的數據存儲也需要進行分區和組件化，這意味著每個微服務都可以擁有自己的關聯數據存儲/數據庫。

從數據角度來看，這意味著：

• 隨著每個微服務的增加，數據庫實例的數量也隨之增加，而再次指向需求上升或下降。
• 為了使這些微服務彼此進行通信，需要調用額外的HTTP，比如便于使用的REST API，這些都需要在任何平臺和語言中靈活擴展。在許多情況下，微服務只是發布指示更改的事件，而監聽器/訂閱者更新關聯的應用程序。

(6)云原生數據庫的基本要求

亞毫秒級響應時間僅供少數特殊應用使用。但是，在當今微服務架構的世界中，這是所有應用程序的必備條件。這個延遲要求需要***性能、***可擴展性的數據庫解決方案。

Active-Active數據復制

批處理模式下的數據復制曾經是一種流行的方法。但對于實時應用程序來說，事件存儲和事件采購的復制變得更具吸引力。在松散耦合且需要共享數據的微服務應用程序中，需要具有可調一致性的Active-Active數據復制。許多客戶使用Active-Active部署模型的原因很多，例如：

• 正在不斷更新的微服務中的共享數據集。
• 跨數據中心無縫遷移數據，以便用戶體驗不受影響。
• 減少故障情況并把故障切換到第二個數據中心，以***限度地減少停機時間。
• 處理大量傳入流量并通過無縫同步在多臺服務器上分配負載。
• 地理位置分散的應用程序(如多人游戲或實時競價/輪詢應用)，數據需要在多個地理位置之間同步。

數據的高可用性

當企業將一個巨大的應用程序分解成微服務，并且每個微服務都有自己的生命周期時，如何確保數據可用性?云原生應用程序開發人員應該根據恢復點目標(將丟失多少數據?)選擇數據存儲恢復時間目標(當事件發生時，需要多長時間才能恢復服務?)、高可用性特性、安裝拓撲結構和故障轉移策略。單節點數據庫實例不僅影響故障情況，還會影響客戶端宕機事件(如版本升級)影響可用性。

高可用性要求通常取決于應用程序的關鍵程度，但正確的數據庫和云原生讓解決方案的組合支持各種高可用性安裝策略，適用于從內部部署到關鍵任務應用程序的各種用例。