傳統企業資料庫上雲案例分享

2021-09-20 11:22:36 字數 4071 閱讀 1604

摘要:在網際網路的浪潮衝擊下,很多傳統企業都選擇上雲。阿里雲在做基於網際網路的分布式應用,因此在傳統企業上雲的過程中,阿里雲也同樣面臨一些資料庫相關的各種衝擊和需求。在武漢雲棲大會上,阿里雲高階產品專家王偉做了名為「

傳統企業資料庫上雲案例分享

」的精彩演講。

傳統企業應用缺點

傳統企業面臨很多架構變遷,正是由於這些變遷,阿里雲在應用架構上做了分布式改造,阿一直在思考如何幫助傳統企業上雲。很多金融、保險、製造業為了適應網際網路的高併發、大流量衝擊,都選擇上雲並且都在做適用性的改造。這個時候大家都在想資料庫怎麼辦,很多企業都在考慮資料庫是不是也要做分布式的改造。那究竟什麼樣的業務場景才需要做資料庫分布式架構呢?

首先我們要明白傳統企業應用架構和網際網路的分布式應用架構到底有什麼不同。其實從資源層面、資料層面、中介軟體層面、應用的開發層面等,每乙個層面都面臨著一些改變。

1.資源層面。傳統的應用架構在使用微型機、儲存裝置等等一些物理硬體。而目前在網際網路分布式應用下,阿里雲在使用公有雲、私有雲、混合雲等等一些混合式的架構。

2.資料層面。傳統的應用在使用集中化的資料庫,比如oracle、sqlserver等資料庫,為什麼叫集中化的資料庫?因為傳統應用為了實現多個節點之間共享和最大限度的保證資料的一致性,習慣把資料檔案存放在一台集中化的儲存裝置裡面。而在網際網路分布式應用下,阿里雲一直倡導去集中化的資料庫的理念,所以目前阿里雲在使用mysql、hbase、redis等等一些分布式的架構。

3.中介軟體層面。傳統應用在使用weblogic/was/mq等等,目前為了做一些微服務的改造,阿里雲在使用swarm/k8s/mesos等等一些架構來基於微服務做一些排程。

4.從應用架構、應用框架來說,傳統的應用在使用spring/struts/soa,現在阿里雲在使用一些微服務架構,例如像docker。

5.傳統企業的開發運維採用可控發布,保守運維,經常乙個新功能的發布動輒幾周甚至幾個月的時間才能上線。而現在阿里雲在使用devops,應用可以隨時上線。在做這些改造之前,應用響應慢並且經常在應用層無法橫向擴充套件,現在做了微服務改造,每乙個微服務都可以適應靈活的彈性和壓力去做一些擴充套件。

因此在目前分布式的改造之下,阿里雲認為對資料庫有更高的要求,總結就是需要敏捷、分布式、低成本等特點。每乙個微服務都對應乙個小的資料庫,所以說需要大量的資料去支援乙個業務,需要靈活性的排程,所以對敏捷性是有要求的。同時因為量級比較大,也希望實現分布式機構。並且由於使用的資料庫多了,使用商業資料庫成本太大,因此需要降低成本。

豐富的雲上資料庫

阿里雲認為傳統的行業做網際網路的創新,需要的資料庫主要有以下特點:

1.自主可控:基於開放架構,基於開源的優化。

2.高可用:跨機房容災,滿足金融級業務系統全天候對外提供穩定可靠的客戶服務。

3.高效能:網際網路+金融的創新業務所需的流量彈性。

4.支援雲:私有雲和公有雲互通一致的體感,降低使用和運維難度。

5.易運維:大體量自動化、運維體系合規化要求(基線、環境適配、管理體系等)。

6.資料安全: 審計&資料強一致性&多中心容災部署。

7.成本優化:it總體擁有成本必須下降。

基於以上特點,阿里雲提供了豐富的雲上資料庫。例如關係型資料庫有mysql、sql server postgresql ppas(⾼高度相容oracle) polardb。nosql資料庫有redis mongodb hbase memcache。混合分析資料庫有hybriddb for mysql hybriddb for postgresql。搜尋與時序資料庫有opensearch elasticsearch hitsdb。另外還提供像dts、dms、hdm等資料庫服務與工具。

對於這麼多資料庫型別和不同資料庫引擎而言,阿里雲還有很多不同的版本。以mysql為例,有基礎版、高可用版、金融版。基礎版就是在ecs的基礎上,加雲盤上部署的mysql資料庫,它提供非常高的價效比,**基本上跟你買乙個ecs加乙個雲盤是一樣的,但是阿里雲在此之上已經整合好了資料庫產品。高可用版實際上就是做了主從資料的複製,可以保證資料庫的資料可用性。當主節點宕機以後,阿里雲可以快速的把業務切換到從節點去,從而保證資料庫的可用性,同時還有很多企業級的功能,包括讀寫分離,讀寫分離是做資料庫橫向擴充套件最便捷的一種方式,應用不用做任何更改,把寫入在主節點執行,把查詢在唯讀節點執行,無形之中增強了主庫的能力。金融版是跨三機房、三節點的三副本的版本,預設實現了同城三機房的容災。金融版直接部署在三個機房,它可以保證資料在三個機房做複製,並且當乙個機房不管是因為電源的故障還是因為光纖的故障而失效,整個資料庫也不會受到影響,資料庫主節點會自動遷移到另外兩個機房之一,繼續提供服務,同時金融版整合了sql審計、高頻監控等。

阿里雲資料庫穩點、高效的秘訣

阿里雲能做到資料的高可用、一致性主要從以下方面來考慮:

1.資料複製技術的演進

做資料庫的高可用是一定要做資料複製的。mysql原生提供兩種方式的複製,一種是非同步複製,比如是一主一從,中間做非同步複製。但是從節點勢必會引起延遲,當主節點發生故障的時候,這個時候不知道從節點的資料是不是最新的,因此如果切換從節點,很有可能會造成資料的丟失。為了解決這個問題,mysql官方提供了另一種方式,半同步複製。半同步複製也是一主一從,主節點在寫入資料的同時,會產生日誌,然後傳送日誌給從節點。因此當主節點宕機,至少可以保證從節點是有資料的。但是同時也會產生另乙個問題,當主節點在等從節點響應的時候,如果發生網路的故障,最終還是降級成非同步。因此阿里雲在alisql上做了增強,叫做雙通道複製,也就是說同時有一條半同步複製通道和非同步複製通道,通過這兩個通道可以確定性的得知當前主資料庫和從資料庫的資料是否一致。

2.拜占庭將軍問題與分布式一致性演算法

拜占庭將軍問題在分布式領域是乙個比較傳統的問題,為了解決拜占庭將軍問題,十幾年前有乙個paxos演算法,但是paxos演算法過於複雜,在很長一段時間都沒有計算機語言可以實現,後來paxos演算法做了簡化,即raft演算法。通過raft演算法可以解決分布式一致性問題,因此阿里雲把raft演算法放到了mysql核心裡面。底層維護了三個資料庫節點,一主兩備的複製拓撲結構意味著每個節點都是全量的資料,資料庫事務日誌(log)從主庫同步複製到所有的備庫,當集群中超過半數的節點都寫入成功後,事務才能完成提交。雖然是同步複製,但由於是三個點,因此單個節點的故障不會影響到例項整體的可用性。這種設計的好處顯而易見,即在不損失可用性的情況下,通過較高的資料冗餘度來換取更好的可靠性,同時支援跨機房的部署方式,具備機房容災能力。

3.對於資料安全的重視

安全是根植於阿里雲核心的原生功能。從安全的角度,阿里雲做了事前、事中、事後三個方面的安全審計,事前阿里雲可以做vpc專有網路、ip白名單、防暴力破解、靈活賬號許可權管理等,事中做了 ssl加密、tde加密、攔截sql注入攻擊,事後可以做 sql審計、轉殖例項等。

結語

阿里雲認為傳統企業要做網際網路分布式的改造,並不是一步就可以完成,因為企業的業務量可能還沒有這麼大,所以如果企業現在的業務系統跑在單個mysql資料庫上面,那麼接下來可以做一些讀寫分離。如果讀寫分離承載不了企業的業務系統,接下來可以做一些垂直的拆分,可以通過微服務去架構,不要用乙個資料庫承載業務架構,而是用多個資料庫承載業務。如果垂直拆分還不夠,可以使用阿里雲的polardb資料庫,如果polardb資料庫還達不到企業的需求,你就應該考慮網際網路分布式的改造了。

本文由雲棲志願小組黃小凡整理

SAP企業應用關鍵變革 撼動傳統資料庫

文章講的是sap企業應用關鍵變革 撼動傳統資料庫,這是乙個真實的故事 一位82歲的老人在幾個月前開始使用ipad,就在這短短的幾個月中產生的資料量,遠遠超出其81年人生歷程所創造的資料總和。這就是乙個大資料時代所帶來的改變,甚至整個人類社會在過去12個小時裡創造的資料總量,就能超過人類從誕生之時到2...

某雲上分布式資料庫SQL優化案例

其中i uid是a表的水平拆分鍵,accesion是b表的水平拆分鍵 select from a a where a.i uid in select b.union an from b b where b.accesion 以下操作均發生在物理mysql伺服器的 節點上 例如mycat explai...

資料庫案例

資料庫案例 儲存的資料庫結構 greendao的介紹 什麼是greendao?greendao的官方文件 greendao的作用?greendao的優缺點?greendao的使用 匯入gradle外掛程式和dao 生成 建立儲存物件實體類 greendao初始化 使用greendao實現增刪改查增刪...