盡管仍有許多遺留應(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ā)和簡單的代碼庫中提供更高的靈活性。可以獨立地實現(xiàn)更新和擴(kuò)展服務(wù)，其服務(wù)可以采用不同的語言編寫，并連接到不同的數(shù)據(jù)層和選擇的平臺。這種策略允許開發(fā)人員和運營人員以更加和諧的方式一起工作。這種組件化架構(gòu)需要一個數(shù)據(jù)庫平臺，可以輕松支持不同的數(shù)據(jù)類型、結(jié)構(gòu)和編程語言。

 

 

“十二要素應(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ù)。

 

 

服務(wù)流程的擴(kuò)散(每個服務(wù)可獨立部署)需要自動部署和回滾機(jī)制，這稱之為持續(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ì)軟件。

 

 

如今的企業(yè)采用多云策略是出于多種原因：準(zhǔn)備災(zāi)難恢復(fù)情況，利用不同云計算基礎(chǔ)設(shè)施中托管應(yīng)用程序之間的財務(wù)差異，增強(qiáng)安全性，或簡單地避免供應(yīng)商鎖定。企業(yè)的應(yīng)用程序代碼應(yīng)該獨立于預(yù)期運行的平臺。

 

 

數(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ù)庫。

 

 

•隨著每個微服務(wù)的增加，數(shù)據(jù)庫實例的數(shù)量也隨之增加，而再次指向需求上升或下降。

 

•為了使這些微服務(wù)彼此進(jìn)行通信，需要調(diào)用額外的HTTP，比如便于使用的REST API，這些都需要在任何平臺和語言中靈活擴(kuò)展。在許多情況下，微服務(wù)只是發(fā)布指示更改的事件，而監(jiān)聽器/訂閱者更新關(guān)聯(lián)的應(yīng)用程序。

 

 

亞毫秒級響應(yīng)時間僅供少數(shù)特殊應(yīng)用使用。但是，在當(dāng)今微服務(wù)架構(gòu)的世界中，這是所有應(yīng)用程序的必備條件。這個延遲要求需要最高性能、最具可擴(kuò)展性的數(shù)據(jù)庫解決方案。

 

 

批處理模式下的數(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ù)中心，以最大限度地減少停機(jī)時間。

 

•處理大量傳入流量并通過無縫同步在多臺服務(wù)器上分配負(fù)載。

 

•地理位置分散的應(yīng)用程序(如多人游戲或?qū)崟r競價/輪詢應(yīng)用)，數(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ù)庫實例不僅影響故障情況，還會影響客戶端宕機(jī)事件(如版本升級)影響可用性。

 

高可用性要求通常取決于應(yīng)用程序的關(guān)鍵程度，但正確的數(shù)據(jù)庫和云原生讓解決方案的組合支持各種高可用性安裝策略，適用于從內(nèi)部部署到關(guān)鍵任務(wù)應(yīng)用程序的各種用例。

 

版權(quán)聲明：本文為企業(yè)網(wǎng)D1Net編譯，轉(zhuǎn)載需注明出處為：企業(yè)網(wǎng)D1Net，如果不注明出處，企業(yè)網(wǎng)D1Net將保留追究其法律責(zé)任的權(quán)利。