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