針對雲原生轉型的6個關鍵資料策略

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

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

(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部署模型的原因很多，例如：

•正在不斷更新的微服務中的共享資料集。

•跨資料中心無縫遷移資料，以便使用者體驗不受影響。

•減少故障情況並把故障切換到第二個資料中心，以最大限度地減少停機時間。

•處理大量傳入流量並通過無縫同步在多臺伺服器上分配負載。

•地理位置分散的應用程式(如多人遊戲或實時競價/輪詢應用)，資料需要在多個地理位置之間同步。

資料的高可用性

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

高可用性要求通常取決於應用程式的關鍵程度，但正確的資料庫和雲原生讓解決方案的組合支援各種高可用性安裝策略，適用於從內部部署到關鍵任務應用程式的各種用例。

原文釋出時間為：2018-05-22

本文作者：Priya Balakrishnan

本文來自雲棲社群合作伙伴“企業網D1Net”，瞭解相關資訊可以關注“企業網D1Net”。