基於容器的金融資料庫雲平臺DBaaS設計實踐分享

 

　　本文根據曾玉成老師在2018年5月11日【第九屆中國資料庫技術大會（DTCC2018）】現場演講內容整理而成。

 

　　 講師介紹：  

　　中國銀聯資深資料庫專家，資料庫團隊負責人 曾玉成

 

　　中國銀聯資深資料庫專家，資料庫團隊負責人，銀聯技術專家委員會委員；團隊負責銀聯資訊總中心資料庫、大資料相關運維工作；13年大型核心金融交易系統資料庫設計及運維經驗，最近5年帶領團隊在開源技術包括資料庫雲、分散式資料庫、大資料、容器技術、規模化運維等方向進行實踐和探索。

 

　　 分享大綱：

 

　　1. 銀聯轉型發展的技術需求

 

　　2. 資料庫雲的銀聯方案

 

　　3. 資料庫雲建設的挑戰

 

　　4. 發展及暢想

 

　　 一、銀聯轉型發展的技術需求

 

　　金融行業資料庫技術發展趨勢

 

　　從金融行業來講我們大概有這麼幾個趨勢，之前的話大家都知道在銀行裡面或者金融系統裡面用的都是一些IOE，像一些產品的資料庫加小機加儲存，現在是因為我們的業務也是在不斷地網際網路化和移動化方向發展，同時現在因為對金融機構來講監管有一些要求，比如說一些開源、國產化、自主可控這些方面對我們來講就提出來一些新的要求。

 

　　因此金融行業的技術發展有這麼幾個趨勢，有點像網際網路企業一樣，就是說微服務化、分散式化、平臺化、自動化、智慧化這樣一個發展趨勢，大部分的銀行或者金融機構裡面目前的現狀可能是商業產品，同時也有大量的這種開源的資料庫並行的現狀，總體的話就是自主可控、分散式、PssS雲化和自動化。

 

　　 銀聯轉型發展的技術需求

 

　　這個是針對我們銀聯自己來講的話，就是我們銀聯在業務的轉型對我們技術的需求。之前的話大家可能也都知道基本上銀聯的業務場景就是POS刷卡、ATM取錢、操作，但是這幾年的話業務發展慢慢的也是移動網際網路化，比如說像我們的一些產品，包括雲閃付APP，大家用的是apple pay這些產品，還有一些銀聯線上掃碼支付，這些都是移動網際網路的這樣一個業務場景。

 

　　那麼這些業務系統的話跟我們有相關的一些特點，第一個就是業務來的很快，而且規模都很大，然後像這些APP的話經常會搞一些活動，那麼對一些需求也是風險的要求比較高的，比如說我們搞活動的時候買了會員，是平時的N倍，另外一個就是我們因為規模大了以後，平臺可靠性這一塊要求挺高，因此就是說這樣一個背景情況下，對於我們的基礎知識架構這一塊提出來一些新的要求，比如說要有更快的服務交換能力，更高的資源利用，還有一個更靈活的大規模的管理能力。

 

　　剛才前面講到的就是知識架構那一塊需要那些能力的話，那我們通過什麼方法來解決呢？比如說我怎麼快速去交付，我怎麼樣去彈性提供資源，然後我在想可能大家想的都一樣，通過雲的方法去做，那麼做資料庫雲去解決這些問題。那作為一個資料庫雲架構，應該有靈活的資源彈性調動能力，高效的資源利用率，服務安全可靠，具備大規模的服務管理。

 

　　 二、資料庫雲的銀聯方案

 

　　我們銀聯這一塊就是在金融行業裡面做開源這一塊的話相對來講應該是比較早的，我們在2012年的時候就開始做，那個時候的話因為數量比較少，早期的話我們主要是用手工加一些自動化指令碼製作的一些運維，但是到2014年的時候，我們生產的Mysql資料庫越來越多了，那時候我們就想著做平臺來管理那時候是DBaaS1.0。

 

　　但是到了2015年的時候，也就是當時容器這種技術出現了，當時我們在想容器這種技術的話是不是能夠把資料實現平臺化，所以當時我們2016年的時候就做了DBaaS2.0這個版本，那麼這個DBaaS平臺我們是基於docker做的。在這期間我們平臺主要做了兩個服務，一個是做了我們的基於Mysql開發的資料庫。然後我們上面的服務的話基本上也是分步策劃的，也能夠做到SCALE OUT彈性擴充套件，這個是我們目前的現狀大概是2.0的版本，然後我們現在正在做的是智慧化自助化的功能。

 

　　我們現在這個版本總結下來有這麼幾個特點。第一個就是自主可控，這個平臺所有的開發，包括上面提供的資料庫服務，這個都是我們自己自研的，這個也是符合我們國家對金融安全監管的要求的。第二個就是彈性伸縮實現了SCALE UP和SCALE OUT。第三個就是我們高度服務化，我們把這個企業結構進行服務化的一些設計，我們很快速地把一些資料庫產品進行包裝。第四個的話就是我們當時是2015年就開始做資料庫容器化，我們很早的時候，2015年的時候就把這個做出來了，而且大規模地在生態環境中用了，用在我們的金融領域，這應該在國內的金融領域算是比較早的。

 

　　我們平臺的話自動化和自助化是我們一個最基本的要求，就是在這個平臺上我們所有的操作、運維、管理基本上都是做到簡單。通用性高是在部署方面體現，比如說我們很多環境，我們銀聯有很多開發、研發，部署等等，有的產品做的特別複雜，部署要好幾天，但是這個也不好用。

 

　　 基於docker的DBaaS建設的幾個重要難點

 

　　 容器管理框架

 

　　講一下我們當時做那個容器的框架選擇的時候為什麼我們選的是Swarm。因為當時其實也是面臨兩個選擇，一個是用Swarm另一個是用K8s，但是同樣2015年那個時候來看的話，我們是研究了一下發現就是說做資料庫的話，這兩個都不能很好地解決我們的問題，就是說它的原生的一些網路架構或者一些管理架構都沒法滿足我們的一些需求，所以這兩個都是要我們定製和開發的，要在我們自己去設想開發，所以我們當時就選了Swarm。

 

　　為什麼選這個呢？首先是因為它是一個輕量級的，然後可定製性比較高，就是開發相對難度要小一點，所以我們選擇了Swarm，當時來講Swarm其實發展勢頭還是蠻好的，特別是這兩年發展的比較好，但是就是到今天為止K8s也沒有辦法完完全全滿足資料庫容器化的這個需求，它也沒有用原生態去做一個複雜的資料庫平臺網路和儲存模型，我們也一直在關注這個的發展。

 

　　 平臺網路解決方案

 

　　這個是我們技術上面的一個解決方案，想跟大家分享一下。首先是網路這一塊，那麼做容器，做資料庫的話，網路這塊是很關鍵的，你什麼樣的網路模型那麼就用你這個資料庫的效能。比如說我們Docker計算網路模式，你用其他的原生模式去試一下就知道，你會發現效能損耗非常大，但如果你不用它，你用其他的那些模式你會發現那個網路沒法做隔離。它怎麼樣做到一種方案就是說我既能夠把網路隔離起來，同時又能夠把網路對它的效能不受影響，那時候我們就選擇了一個方案叫做過SR_IOV技術，就是把一款物理網路卡進行虛擬化，現在普通的萬兆網路卡都可以做到64個或128個虛擬卡，那麼把這個虛擬網路卡通過VF方式放入網路記憶體，大概具體的做法就是說速度之上，把這個網路卡虛擬化了以後，然後通過Net NS對映給Docker, 雙網路卡bonding。VF上還可以直接配置Qos策略，相較於物理環境下無損耗，這一點是非常非常可貴的，就是在我們做資料庫容器化的時候一個很關鍵的點，這個方案我後來也看到了，就是螞蟻金服他們自己以前做的也是這種方案。

 

　　 平臺儲存管理解決方案

 

　　另外一個就是儲存這一塊。之前我們用容器平臺做儲存這一塊大概有兩種選擇，一種選擇是用本地儲存，另一個選擇是分散式儲存，那麼這兩種方案都有缺點，第一個用本地儲存的話有一個很大的問題，就是資料遷移性的問題，你要被通過備份，這個是一個比較耗時的問題。同時一般本地儲存的空間是比較小的，那它的一兩個T就沒了。如果是用的共享儲存的話有一個最大的問題就是效能問題，那有沒有一種方法就是說我們既能夠做到資料快速遷移，同時又滿足儲存隔離，那我們後來用了金融行業用的比較多的一種方案，就是用外部儲存。

 

　　 平臺服務-自研分散式資料庫UPSQL

 

　　平臺服務-自研分散式快取UPredis

 

　　這個是我們平臺上第三個難做的就是說你提供的服務這一塊，你怎麼樣做一個服務的執行的服務能力。

 

　　 三、資料庫雲建設的挑戰

 

　　DBaaS建設的風險及應對

 

　　前面介紹的是我們做這個平臺的過程當中總結下來的五點比較關鍵的一些點，其實也是暴露了我們在整個過程當中最重要的一些經驗吧，也是跟大家分享一下。

 

　　同時另外還有一些經驗跟大家分享一下就是說DBaaS其實也是有很大的投入的，所以先來分享一個就是說DBaaS不是適合每個公司都去做，因為它還是有一些技術門檻在裡面，還是有一些投入在裡面。

 

　　管理這一塊的話我覺得一個概念就是說整體上在雲環境下你要有這樣一個意識，就是任何一個模組都是不可靠的，所以你在設計這個平臺的時候你要想任何一個模組故障的話是否會受到影響。包括前面剛才講的補充一下，為什麼投入性蠻大的？我們做這些東西其實銀聯的話現在有還算比較大的一個團隊，有30個人做這件事情，包括做我們定製的資料庫，包括做這個平臺，還是有一點規模的。

 

　　 四、發展及暢想

 

　　銀聯DBaaS產品服務情況

 

　　 發展及暢想

 

　　這個是我們對這個產品的話的一些規劃，就是說現在只是提供了我們分公司的資料庫，那麼我們接下來肯定會進一步在上面封裝更多的產品，其實銀聯是DB2的使用大戶，那麼我們怎麼樣把這個服務擴充套件到這個平臺這是非常關鍵的，也是一個比較難做的事情。另外一個就是縱向的，就是平臺智慧化這一塊，我們正在做的一個事情就是說我怎麼樣做好這個智慧分析調優。最後是增值服務方面，我們做資料的轉移、風險監控、大資料分析之類的。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28285180/viewspace-2213720/，如需轉載，請註明出處，否則將追究法律責任。