日前，“UCloud用戶開放日”***期活動順利舉行。UCloud關(guān)系型存儲研發(fā)部經(jīng)理羅成對系統(tǒng)梳理了UCloud數(shù)據(jù)庫產(chǎn)品UDB的發(fā)展歷程，并闡述了貫穿其中的產(chǎn)品設(shè)計理念，包括產(chǎn)品族介紹、架構(gòu)設(shè)計、未來規(guī)劃以及典型用戶案例。

[[224776]]

UDB產(chǎn)品的前世今生

UDB是UCloud于2013年1月正式推出的第三款產(chǎn)品，***先支持的是應(yīng)用最廣泛的MySQL數(shù)據(jù)庫。經(jīng)過五年的發(fā)展，UDB產(chǎn)品線越來越豐富，目前已廣泛支持業(yè)內(nèi)主流數(shù)據(jù)庫，如MySQL、MongoDB、PostgreSQL以及SQL Server，產(chǎn)品特性包括主從架構(gòu)、高可用、數(shù)據(jù)庫專區(qū)、跨區(qū)高可用、讀寫分離、彈性擴展、備份與恢復、監(jiān)控與告警等。

UDB產(chǎn)品非常適用于“三高”場景 —— 高性能、高可用、高并發(fā)，滿足多行業(yè)的業(yè)務(wù)需求，包括游戲、電子商務(wù)、企業(yè)服務(wù)、O2O、在線教育等。和UDB一同成長起來的客戶在上云之初就將UDB作為***。2014年，《刀塔傳奇》在AppStore排行榜連續(xù)幾個月***冠軍，部署使用UDB后，高峰時期同時在線支持超過4000個實例，還不包括從庫，整體發(fā)展非常迅速，UDB良好地支持了業(yè)務(wù)的發(fā)展。

UDB產(chǎn)品設(shè)計理念

UDB發(fā)展至今，貫穿其中的產(chǎn)品設(shè)計理念歸結(jié)起來有兩點：

◆  用戶需求驅(qū)動

UDB整體發(fā)展都緊跟用戶的需求，不斷進行產(chǎn)品更新、迭代;

◆  產(chǎn)品自然進化

云數(shù)據(jù)庫從字面上看是“云+數(shù)據(jù)庫”，部署在云平臺上，也會跟隨著云平臺的發(fā)展而不斷成長。

一個好的互聯(lián)網(wǎng)產(chǎn)品的定義是：通過可行的技術(shù)創(chuàng)造以及可持續(xù)發(fā)展的產(chǎn)品能力，滿足用戶需求。

UCloud一直都秉持著的信念是“用戶需求就是我們的下一個產(chǎn)品”，這里的需求有兩個層面：

◆  功能性需求

對于數(shù)據(jù)庫產(chǎn)品來說，它核心要解決的功能性需求是數(shù)據(jù)存儲、數(shù)據(jù)訪問安全。我們的理解是，數(shù)據(jù)放在這里，它怎么去落地、訪問、讀寫、保證數(shù)據(jù)安全可靠，這是基本的功能性需求。

◆  附加性需求

附加性需求包括穩(wěn)定、容災、容量、性能、性價比、可運維等。

云數(shù)據(jù)庫產(chǎn)品，首先要滿足用戶的功能性需求，再一步步滿足用戶的附加性需求，這是UDB的產(chǎn)品設(shè)計理念。

UDB的產(chǎn)品演進之路

云數(shù)據(jù)庫UDB發(fā)展了好幾年，需求層次從簡單到復雜，整個產(chǎn)品的演進也從簡單到復雜，其背后的驅(qū)動力可從內(nèi)外兩個方面來看：

◆  外驅(qū)動力

外驅(qū)動力，是說用戶接入使用數(shù)據(jù)庫后，用戶本身的成長促使UDB產(chǎn)品不斷進化，以滿足其新需求。比如，前面提到的《刀塔傳奇》，使用UDB后體量迎來爆發(fā)性增長，達到一定程度之后，需求層次也發(fā)生了變化，已經(jīng)不再局限于一些功能性需求，后面對一些附加性需求就越來越多了。

◆  內(nèi)驅(qū)動力

內(nèi)驅(qū)動力，也就是說基礎(chǔ)設(shè)施在變化，給UDB提供基礎(chǔ)設(shè)施的是UCloud云平臺，基礎(chǔ)設(shè)施越來越便宜，云平臺的能力是不斷進步的。另外一方面，性能更強勁、更具性價比的計算/存儲硬件不斷面世，也促使UDB汲取硬件價值，轉(zhuǎn)移到產(chǎn)品上。

這些內(nèi)外驅(qū)動力共同推動云數(shù)據(jù)庫的快速發(fā)展，縱觀整個UDB發(fā)展史，可以說經(jīng)歷了三重境界：

云數(shù)據(jù)庫1.0可以簡單理解為“云+數(shù)據(jù)庫”，在云上部署了一個數(shù)據(jù)庫。云有按需計價、快速交付、彈性擴容、高速網(wǎng)絡(luò)、多可用區(qū)、虛擬化等一系列特點，而數(shù)據(jù)庫本身解決了數(shù)據(jù)的結(jié)構(gòu)化存儲、標準化訪問、數(shù)據(jù)安全性等問題?？梢哉f，云跟數(shù)據(jù)庫結(jié)合起來已能很好的滿足用戶功能性需求與部分附加性需求。

關(guān)于未來數(shù)據(jù)庫的發(fā)展，云數(shù)據(jù)庫已不再是簡單的“云+數(shù)據(jù)庫”，而是“云×數(shù)據(jù)庫”，功能更像是矩陣式進化?，F(xiàn)在業(yè)界比較關(guān)注的AWS Aurora DB就非常典型，它是RDS發(fā)展到一定階段之后，克服了許多挑戰(zhàn)，不斷自我迭代，進化出的新一代產(chǎn)品，更好地覆蓋了用戶更高級的需求。目前來講，個人認為Aurora DB很好地代表了數(shù)據(jù)庫2.0的階段。

UDB用戶案例解析

之前說到，UDB非常適用于“三高”場景，下面結(jié)合真實案例為大家解析UDB是如何應(yīng)用于這些業(yè)務(wù)場景的：

應(yīng)用場景之業(yè)務(wù)持續(xù)可用

應(yīng)用場景之高性能

應(yīng)用場景之彈性擴容

應(yīng)用場景之高性價比

◆  應(yīng)用場景之業(yè)務(wù)持續(xù)可用

我們做過一個調(diào)研：如果客戶開始使用的是單點數(shù)據(jù)庫，一旦宕機，現(xiàn)場更換硬件短則需要幾分鐘，長則需要幾個小時，而且這種因宕機導致業(yè)務(wù)不可用的情況，后果是非常嚴重的。

UDB則通過一個簡單、實用、可靠的基礎(chǔ)架構(gòu)解決了上述問題，它包括一個代理節(jié)點、主數(shù)據(jù)庫、備數(shù)據(jù)庫。

這種架構(gòu)的優(yōu)點在于：

1） 足夠簡單，因為它的組件比較少。架構(gòu)設(shè)計上，UDB一直奉行“簡單即可靠”。

2） 節(jié)點可以分布在不同的可用區(qū)，可以滿足跨可用區(qū)的容災需求。

通過主備模式，任意一個組件都有主備、熱備，因此可以做到兩層容災：DB容災和Proxy容災。下圖介紹了DB數(shù)據(jù)容災，DB容災原先VIP代理的是一個主庫，進行容災時則代理備庫，非常簡單。

另外一個是Proxy容災，進行VIP跨可用區(qū)漂移，在VPC2.0的網(wǎng)絡(luò)架構(gòu)下，可以直接從可用區(qū)1漂到可用區(qū)2。

以金融和保險行業(yè)為例，金融行業(yè)因安保限制，需要“兩地三中心”架構(gòu)。UCloud的兩地三中心解決方案首先在北京機房建一個主庫，使用跨可用區(qū)的高可用產(chǎn)品，同時在上海有個備庫，中間通過UDPN網(wǎng)絡(luò)專線打通，結(jié)合UDTS數(shù)據(jù)傳輸產(chǎn)品，可進行可靠的、持續(xù)的數(shù)據(jù)傳輸，這樣就能做到“兩地三中心”需求。

互聯(lián)網(wǎng)用戶也有“兩地三中心”的需求，將網(wǎng)絡(luò)UDPN打通之后，從庫能跟主庫自然進行同步。只要把主從關(guān)系建立好，網(wǎng)絡(luò)打通，自然就能在這3個可用區(qū)進行地域級容災能力。MongoDB的兩地容災方案更為簡單。

◆  應(yīng)用場景之高性能

使用數(shù)據(jù)庫最容易出現(xiàn)的瓶頸就是I/O。普通DB面對I/O密集型的應(yīng)用非常被動，集中表現(xiàn)為DB反應(yīng)慢，緊接著的并發(fā)癥是網(wǎng)絡(luò)延遲增高、慢查詢增多、連接數(shù)增多，雪崩效應(yīng)很容易把DB打垮。

UCloud提供了一個解決方案——高性能SSD機型，底層采用PCI-e和NVMe SSD，其I/O能力吞吐量非常大。如果它對于性能要求更高，則推薦使用獨享實例，這樣可以使用整臺整機，不會跟別人產(chǎn)生I/O的競爭；如果要求再高，那推薦分布式數(shù)據(jù)庫UDDB，不僅容量可以擴展，性能也可以彈性擴展。典型客戶包括互聯(lián)網(wǎng)、游戲、電商、社交這些對于I/O要求特別高的用戶。統(tǒng)計數(shù)據(jù)顯示，高性能SSD UDB已經(jīng)是不少用戶重要業(yè)務(wù)的***。

在單節(jié)點性能無法滿足業(yè)務(wù)需求的情況下，UCloud提供讀寫分離解決方案，完全可以做到性能成倍擴展。顧名思義，讀寫分離就是“讀”和“寫”分開，“寫”可以放在一個節(jié)點上，“讀”可以放在其他從庫上，基礎(chǔ)架構(gòu)圖如下：

UCloud有一位做在線K歌APP的用戶從自建數(shù)據(jù)庫遷移到UCloud云平臺上，當時用戶的數(shù)據(jù)庫因業(yè)務(wù)增長迅速，遇到了性能瓶頸，使用了這套讀寫分離方案之后，其性能成倍擴展，用戶使用“1主帶5從”的架構(gòu)，吞吐量可增長到6倍，不僅吞吐量上去，連接數(shù)也可以上去。因此，通過讀寫分離，業(yè)務(wù)將不再受單點連接數(shù)限制，也不再受單點容量的限制，可以平行擴展數(shù)據(jù)庫吞吐能力，連接數(shù)上去，并發(fā)能力就越來越強了。

◆  應(yīng)用場景之彈性擴容

互聯(lián)網(wǎng)應(yīng)用有“起量很小，爆發(fā)很快”的特點。這些應(yīng)用對云平臺的彈性擴容能力要求很高：首先，底層基礎(chǔ)架構(gòu)必須具備彈性擴展能力，從應(yīng)用層來講，后端無狀態(tài)的服務(wù)非常好做彈性擴展，但DB是有狀態(tài)的；其次，是存在熱點應(yīng)用，也就是說整個DB都是為了這個應(yīng)用在服務(wù)，就容易把整個DB拖垮。

隨著業(yè)務(wù)的不斷發(fā)展，某應(yīng)用平臺后端的單點數(shù)據(jù)庫起初承受巨大的壓力。在UDB上，數(shù)據(jù)庫架構(gòu)一步步從MongoDB Primary單點，到高可用副本集，再到分片集群演進，抗住了業(yè)務(wù)增長的壓力。數(shù)據(jù)量與分片個數(shù)成線性比例增加。

舉個例子，某家排行榜Top 10的社交應(yīng)用APP，其業(yè)務(wù)可能達到一年30億條數(shù)據(jù)量的增長，這還是比較保守的估計。該APP希望能有一款彈性擴容，業(yè)務(wù)兼容性好且性價比優(yōu)的解決方案。當時，該應(yīng)用已經(jīng)每天有***的數(shù)據(jù)量，查詢已經(jīng)走了索引，簡單的SQL優(yōu)化對其來講并不能提升太多。   

UCloud推薦的解決方案是UDDB。

這個方案有幾個優(yōu)勢，非常滿足這款社交應(yīng)用APP的需求：

彈性擴容：應(yīng)對數(shù)據(jù)增長只需添加UDB節(jié)點，將新產(chǎn)生的數(shù)據(jù)寫入新的節(jié)點；

靜默擴容：擴容操作100%不影響業(yè)務(wù)；

按需付費：業(yè)務(wù)上線前期，僅需購買1個節(jié)點，存儲未來3個月數(shù)據(jù)，如果業(yè)務(wù)快速增長，再添加節(jié)點，避免前期投入過大；

業(yè)務(wù)高度兼容： 客戶業(yè)務(wù)程序僅改動2條SQL。

◆  應(yīng)用場景之高性價比

有些客戶業(yè)務(wù)涉及到海量數(shù)據(jù)存儲，比如物聯(lián)網(wǎng)場景，部分智能終端一天的數(shù)據(jù)采集量就有幾億規(guī)模。數(shù)據(jù)采集上來需要存儲并保留較長時間（比如3個月）。在面對這種高并發(fā)、數(shù)據(jù)持續(xù)寫入的情況時，UDDB方案也能很好的滿足客戶需求。

針對類似場景，如果采用物理機自建，隱性投入很大，UCloud推薦高壓縮UDB+數(shù)據(jù)庫專區(qū)解決方案，能很好地降低數(shù)據(jù)庫成本。由于數(shù)據(jù)庫專區(qū)具有獨享性，這樣可以把整臺機器的利用率提升，專區(qū)的整機具有更大存儲空間，另外可以按時間滾動重用。同時進行DB壓縮之后，即使是普通數(shù)據(jù)盤也能滿足客戶需求，因為物聯(lián)網(wǎng)應(yīng)用大量冷數(shù)據(jù)。***達到的效果是整個數(shù)據(jù)庫的規(guī)模壓縮比在3.2倍左右，數(shù)據(jù)量由原先150TB減少到目前52TB，總體成本節(jié)約26%。

UDB的未來展望

從UDB產(chǎn)品負責人的角度，對UDB未來的期待是——消除用戶對數(shù)據(jù)庫獲得和使用的門檻?，F(xiàn)在，獲得門檻已經(jīng)消除，用戶可以方便地在線購買云數(shù)據(jù)庫。

隨著UDB產(chǎn)品逐漸成熟和完善，用戶只需做一些編排工作，后端應(yīng)用就可以直接用起來，而不必關(guān)注太多后端技術(shù)細節(jié)。但這還不夠，在云數(shù)據(jù)庫獲得門檻已基本解決的形勢下，降低使用門檻還要做很多努力。因此，今后要實現(xiàn)更多產(chǎn)品功能與特性來支持用戶業(yè)務(wù)，將用戶完全從數(shù)據(jù)庫“解放”出來。