|
新聞中心
當前位置：網(wǎng)站首頁 > 新聞中心
針對云原生轉型的6個關鍵數(shù)據(jù)策略
如今，許多組織正在將采用云原生平臺作為其數(shù)字轉型戰(zhàn)略。云原生允許企業(yè)以更靈活的方式提供快速響應、用戶友好的應用程序。但是，支持云原生轉換的數(shù)據(jù)體系結構常常被忽略，希望它會自行處理。
隨著數(shù)據(jù)成為每個組織的信息貨幣，企業(yè)如何在云計算轉型過程中避免常見的數(shù)據(jù)錯誤？在構建云原生應用程序時，應該知道哪些數(shù)據(jù)問題？如何從數(shù)據(jù)中獲得有價值的見解？以下將闡述企業(yè)在向云原生轉型過渡時必須考慮的六個關鍵因素：（1）放棄面向服務體系結構（SOA），采用微服務
盡管仍有許多遺留應用程序仍然是基于面向服務體系結構（SOA）的，但架構思維已經(jīng)發(fā)生了變化，并且微服務獲得了廣泛的普及。開發(fā)人員可以通過創(chuàng)建許多協(xié)同工作的獨立服務來獲得許多益處，而不是構建單一應用程序。微服務架構在應用程序開發(fā)和簡單的代碼庫中提供更高的靈活性?？梢元毩⒌貙崿F(xiàn)更新和擴展服務，其服務可以采用不同的語言編寫，并連接到不同的數(shù)據(jù)層和選擇的平臺。這種策略允許開發(fā)人員和運營人員以更加和諧的方式一起工作。這種組件化架構需要一個數(shù)據(jù)庫平臺，可以輕松支持不同的數(shù)據(jù)類型、結構和編程語言。
（2）12-Factor App和云原生微服務
“十二要素應用程序”（12-Factor App）是一套幫助組織構建云原生應用程序的規(guī)則和準則。它是一個很好的起點，但是在數(shù)據(jù)平臺方面，有幾個因素（第4個和第5個）需要進一步檢查。
第4個因素：將支持服務視為附加資源：這里的“支持服務”大部分是指數(shù)據(jù)庫和數(shù)據(jù)存儲。這意味著微服務需要模式和底層數(shù)據(jù)存儲的專用單一所有權。
第5個因素：嚴格分離構建和運行階段，單獨的構建和運行階段意味著應用程序應該作為一個更多的無狀態(tài)進程執(zhí)行，并且狀態(tài)通常被加載到后臺服務上。這進一步意味著數(shù)據(jù)庫和數(shù)據(jù)存儲應該是有狀態(tài)的服務。
（3）持續(xù)集成/持續(xù)交付
服務流程的擴散（每個服務可獨立部署）需要自動部署和回滾機制，這稱之為持續(xù)集成或持續(xù)交付（CI/CD）。實際上，如果沒有成熟的CI/CD功能，微服務的價值就無法完全實現(xiàn)。請注意，這種瞬態(tài)架構意味著數(shù)據(jù)庫實例也將是短暫的，并且它們還必須能夠根據(jù)需要輕松啟動。借助正確的云原生平臺和支持數(shù)據(jù)平臺，微服務變得易于部署。云原生平臺應處理對其運行的服務的管理，并且數(shù)據(jù)庫應處理數(shù)據(jù)擴展和監(jiān)視，在必要事件中添加碎片，重新平衡、重定位或故障轉移。組合的數(shù)據(jù)庫和云原生解決方案減輕了監(jiān)控數(shù)據(jù)庫和平臺的運營負擔，使企業(yè)可以花更多時間來開發(fā)和部署優(yōu)質軟件。
（4）多云部署模型的重要性
如今的企業(yè)采用多云策略是出于多種原因：準備災難恢復情況，利用不同云計算基礎設施中托管應用程序之間的財務差異，增強安全性，或簡單地避免供應商鎖定。企業(yè)的應用程序代碼應該獨立于預期運行的平臺。
（5）整體與非整體
數(shù)據(jù)訪問和數(shù)據(jù)移動的傳統(tǒng)方法是令人望而卻步的。傳統(tǒng)方法涉及在其他運營數(shù)據(jù)存儲和數(shù)據(jù)倉庫/數(shù)據(jù)湖中的主數(shù)據(jù)存儲中創(chuàng)建數(shù)據(jù)的副本，其中數(shù)據(jù)在數(shù)小時或數(shù)天后更新，通常是批量更新。由于組織采用微服務和設計模式，數(shù)據(jù)在不同類型的數(shù)據(jù)存儲中傳輸?shù)难舆t阻礙了敏捷性，并阻止組織推進其業(yè)務計劃。
隨著采用扼殺模式逐漸將單一應用程序遷移到微服務架構，逐漸用新的應用程序和服務取代特定的功能。這意味著關聯(lián)的數(shù)據(jù)存儲也需要進行分區(qū)和組件化，這意味著每個微服務都可以擁有自己的關聯(lián)數(shù)據(jù)存儲/數(shù)據(jù)庫。
從數(shù)據(jù)角度來看，這意味著：
隨著每個微服務的增加，數(shù)據(jù)庫實例的數(shù)量也隨之增加，而再次指向需求上升或下降。
為了使這些微服務彼此進行通信，需要調(diào)用額外的HTTP，比如便于使用的REST API，這些都需要在任何平臺和語言中靈活擴展。在許多情況下，微服務只是發(fā)布指示更改的事件，而監(jiān)聽器/訂閱者更新關聯(lián)的應用程序。
（6）云原生數(shù)據(jù)庫的基本要求
亞毫秒級響應時間僅供少數(shù)特殊應用使用。但是，在當今微服務架構的世界中，這是所有應用程序的必備條件。這個延遲要求需要最高性能、最具可擴展性的數(shù)據(jù)庫解決方案。
Active-Active數(shù)據(jù)復制
批處理模式下的數(shù)據(jù)復制曾經(jīng)是一種流行的方法。但對于實時應用程序來說，事件存儲和事件采購的復制變得更具吸引力。在松散耦合且需要共享數(shù)據(jù)的微服務應用程序中，需要具有可調(diào)一致性的Active-Active數(shù)據(jù)復制。許多客戶使用Active-Active部署模型的原因很多，例如：
正在不斷更新的微服務中的共享數(shù)據(jù)集。
跨數(shù)據(jù)中心無縫遷移數(shù)據(jù)，以便用戶體驗不受影響。
減少故障情況并把故障切換到第二個數(shù)據(jù)中心，以最大限度地減少停機時間。
處理大量傳入流量并通過無縫同步在多臺服務器上分配負載。
地理位置分散的應用程序（如多人游戲或實時競價/輪詢應用），數(shù)據(jù)需要在多個地理位置之間同步。
數(shù)據(jù)的高可用性
當企業(yè)將一個巨大的應用程序分解成微服務，并且每個微服務都有自己的生命周期時，如何確保數(shù)據(jù)可用性？云原生應用程序開發(fā)人員應該根據(jù)恢復點目標（將丟失多少數(shù)據(jù)？）選擇數(shù)據(jù)存儲恢復時間目標（當事件發(fā)生時，需要多長時間才能恢復服務？）、高可用性特性、安裝拓撲結構和故障轉移策略。單節(jié)點數(shù)據(jù)庫實例不僅影響故障情況，還會影響客戶端宕機事件（如版本升級）影響可用性。
高可用性要求通常取決于應用程序的關鍵程度，但正確的數(shù)據(jù)庫和云原生讓解決方案的組合支持各種高可用性安裝策略，適用于從內(nèi)部部署到關鍵任務應用程序的各種用例。
|
