近年來，企業(yè)數(shù)字化變革的深入和智能制造、智慧城市、元宇宙等新興產(chǎn)業(yè)的興起，對云計算提出了更高的需求，傳統(tǒng)云計算難以滿足新興場景的算力需求，整合資源、統(tǒng)一調(diào)度、一致服務(wù)的分布式云計算正在被越來越多的企業(yè)所接受，分布式云計算頭部企業(yè)已在實(shí)踐領(lǐng)域取得建樹，為中國分布式云計算發(fā)展積累了寶貴的前期經(jīng)驗(yàn)。

一直以來，全球分布式云大會作為中國的倡導(dǎo)者，致力于為中國分布式云計算的發(fā)展提供最優(yōu)秀的技術(shù)和商業(yè)交流平臺。本次全球分布式云大會，全球分布式云聯(lián)盟攜手阿里云、騰訊云、火山引擎、PPIO邊緣云、亞馬遜云科技等分布式云計算頭部企業(yè)，展示分布式云計算階段性發(fā)展成果，進(jìn)一步普及和推廣分布式云計算的商業(yè)應(yīng)用！

在8月26日下午舉辦的【數(shù)據(jù)庫專題論壇】上，OceanBase 解決方案架構(gòu)師 周貴卿發(fā)表了題為《云上分布式數(shù)據(jù)庫應(yīng)用最佳實(shí)踐》的精彩演講，詳細(xì)內(nèi)容如下。

互聯(lián)網(wǎng)的早期技術(shù)架構(gòu)是單體架構(gòu)，ALL IN ONE應(yīng)用+數(shù)據(jù)庫的模式就可以承載業(yè)務(wù)需求，當(dāng)時的淘寶也是從“PHP+MySQL”的模式開始演進(jìn)的。隨著業(yè)務(wù)的增長，單體架構(gòu)已經(jīng)無法承載業(yè)務(wù)的容量，于是開始對架構(gòu)進(jìn)行模塊拆分，出現(xiàn)了一些垂直架構(gòu)。

2000年左右，互聯(lián)網(wǎng)的井噴式增長，分布式架構(gòu)初現(xiàn)雛形，研發(fā)人員會用到如Nginx、SLB等負(fù)載均衡框架，將后端的復(fù)雜應(yīng)用屏蔽；此時如果對后端應(yīng)用實(shí)例進(jìn)行增減，整個業(yè)務(wù)都是無感知的，這就是Spring Cloud的架構(gòu)。本質(zhì)上，微服務(wù)架構(gòu)是分布式架構(gòu)，解決的是分而治之的問題，而加入一些分布式中間件，如zookeeper、ETCD，或基于PAXOS、Raft、Zab等協(xié)議，解決全局業(yè)務(wù)的協(xié)調(diào)一致性。

伴隨互聯(lián)網(wǎng)技術(shù)架構(gòu)的發(fā)展，底層的數(shù)據(jù)庫從單體數(shù)據(jù)庫+高可用主從，到不同業(yè)務(wù)使用獨(dú)立的數(shù)據(jù)庫，再到分布式數(shù)據(jù)庫。而隨著業(yè)務(wù)體量的不斷增長，單個數(shù)據(jù)庫無法滿足需求，基礎(chǔ)組件會外掛很多中間件，如Sharding分庫分表、zookeeper等分布式一致性組件，數(shù)據(jù)庫架構(gòu)是異構(gòu)的，不止有分庫分表，部分?jǐn)?shù)據(jù)庫依然是主從，對業(yè)務(wù)架構(gòu)提出了很多挑戰(zhàn)。

當(dāng)前數(shù)據(jù)庫架構(gòu)——技術(shù)挑戰(zhàn)

當(dāng)前數(shù)據(jù)庫架構(gòu)基本上是MySQL一主多從架構(gòu)，業(yè)務(wù)寫入只能寫到Master，在業(yè)務(wù)爆發(fā)式增長下，寫入量激增MySQL單Master會成為瓶頸；日常備庫資源水位偏低，當(dāng)從庫的存儲已經(jīng)達(dá)到90%+，但資源（CPU）利用率只有5%-10%。

讀寫分離架構(gòu)是邏輯復(fù)制，由于業(yè)務(wù)量激增寫入量變大，邏輯復(fù)制的性能消耗，加上多活、跨機(jī)房等原因，會出現(xiàn)binlog主從延遲，新寫入的數(shù)據(jù)無法及時的被讀取出來，導(dǎo)致業(yè)務(wù)受到影響。

在高可用架構(gòu)上，MySQL主庫Down機(jī)，HA架構(gòu)存在數(shù)據(jù)丟失風(fēng)險，且需要 DBA手工做主從切換，業(yè)務(wù)連續(xù)性無法保障。

Sharding分庫，本質(zhì)是由多個數(shù)據(jù)庫組成，存在中間件瓶頸問題，跨庫事務(wù)、一致性、關(guān)聯(lián)查詢等問題。

用戶選擇適應(yīng)應(yīng)用的數(shù)據(jù)庫架構(gòu)，就等于同時對運(yùn)維提出了相應(yīng)的要求，隨著業(yè)務(wù)量的快速增長，也面臨著規(guī)?；\(yùn)維的問題。

DBA在日常運(yùn)維時，磁盤或服務(wù)器的故障是小概率事件，但規(guī)?；\(yùn)維時，故障就可能每天都在發(fā)生，導(dǎo)致DBA的工作變得碎片化，充滿著性能調(diào)優(yōu)、故障處理、宕機(jī)恢復(fù)等工作，影響業(yè)務(wù)正常開展。

通常來說，當(dāng)故障發(fā)生時，DBA應(yīng)當(dāng)是企業(yè)數(shù)據(jù)庫穩(wěn)定性的最后一道保障，但他的日常工作過于瑣碎，也缺乏良好的工具支撐，企業(yè)全局的業(yè)務(wù)連續(xù)性存在非常大的隱患。

數(shù)據(jù)庫架構(gòu)演進(jìn)

數(shù)據(jù)庫的架構(gòu)演進(jìn)，單機(jī)架構(gòu)已經(jīng)都到瓶頸，無法滿足大多數(shù)業(yè)務(wù)應(yīng)用的訴求；當(dāng)前絕大數(shù)企業(yè)采用的是分庫分表架構(gòu)，架構(gòu)理念采用的是PG數(shù)據(jù)庫的PG XC架構(gòu)，將分庫分表、分布式一致性等中間件下移到數(shù)據(jù)庫能力上，但依然是一套外掛架構(gòu)，面對偏分析的場景可能會導(dǎo)致事倍功半；隨著谷歌Spanner的發(fā)布，數(shù)據(jù)庫進(jìn)入分布式時代，并且Spanner實(shí)現(xiàn)了全球一致性。

螞蟻集團(tuán)從2010年開始探索原生分布式數(shù)據(jù)庫領(lǐng)域；2014年的去IOE過程中，支付寶業(yè)務(wù)遷移到OceanBase，至今已有八年，扛過了一次又一次雙十一“洪峰”，峰值一度高達(dá)6100萬次/秒，同時也經(jīng)過了大量金融場景的考驗(yàn)。到目前，OceanBase已經(jīng)100%成為螞蟻集團(tuán)的數(shù)據(jù)庫底座，總規(guī)模達(dá)到數(shù)百萬量級。

下一代數(shù)據(jù)庫架構(gòu)——OceanBase

OceanBase的主要特性有以下幾點(diǎn)：

1 多云架構(gòu)

·支持多云部署，裸金屬/公有云/私有云均支持部署

·不依賴專有硬件，基于普通X86/ARM提供金融級別高可用

2 原生分布式 多副本強(qiáng)一致性

·數(shù)據(jù)自動分布對應(yīng)用透明，無需中間件分庫分表

·全對等節(jié)點(diǎn)，讀寫多活

·多副本，Paxos協(xié)議副本間強(qiáng)一致性

3 極致水平擴(kuò)展 線性高性能

·集群在線橫向擴(kuò)容/縮容，不停服務(wù)

·性能線性擴(kuò)展，單集群超過 1000 臺服務(wù)器，單庫數(shù)據(jù)量超過2PB，峰值處理6100萬次/秒

4 多租戶模式

·支持多運(yùn)行模式， 高度兼容Oracle/MySQL數(shù)據(jù)類型、對象、函數(shù)、SQL語法、過程語言

·單一OceanBase 集群靈活支持多個Oracle/MySQL租戶

·租戶間資源隔離，且可以在線動態(tài)調(diào)整

5 平滑高可用 容災(zāi)切換

·表/表分區(qū)級的高可用，自動故障/災(zāi)難切換

·少數(shù)副本故障，RPO=0（不丟數(shù)），RTO<30s（自動內(nèi)部平滑切換）

核心優(yōu)勢 1：極致水平可擴(kuò)展

在線擴(kuò)容（應(yīng)用無感知），面對洪峰場景，在線擴(kuò)容增加每個高可用域（Zone）的OceanBase 節(jié)點(diǎn)的數(shù)量，數(shù)據(jù)庫租戶也增加資源單元，系統(tǒng)自動將表/表分區(qū)的各個副本重均衡分布到新增加的OceanBase 節(jié)點(diǎn)，采用物理拷貝，每節(jié)點(diǎn)性能>500MB/s，無需重新 Hash 每條記錄，同時，應(yīng)用無感知，無需像分庫分表那樣對應(yīng)用配合大量改造。該方法同樣支持在線縮容的操作。

核心優(yōu)勢 2：平滑高可用/容災(zāi)切換

OceanBase內(nèi)部自動切換、無需人工干預(yù)和復(fù)雜決策流程，基于Paxos協(xié)議的典型多副本(三副本或以上)部署，能夠?qū)崿F(xiàn)數(shù)據(jù)強(qiáng)一致性、持續(xù)可用，主備自動切換，對上層業(yè)務(wù)透明。一旦發(fā)生單機(jī)、機(jī)房、城市級故障，OceanBase 內(nèi)部自動故障切換，不影響服務(wù)（RTO < 30s），不丟任何數(shù)據(jù)（RPO = 0）。

核心優(yōu)勢3：計算資源整合和存儲成本下降

一方面，OceanBase 通過DBaaS能力，多租戶隔離，例如在一主兩從架構(gòu)下，通過多租戶能力，主可用區(qū)提供寫入，下一位租戶就可以置入下一個可用區(qū)，讓機(jī)器資源充分利用，按需分配調(diào)整資源（快速升降配），讀寫能力都可以放在從節(jié)點(diǎn)上。

另一方面，OceanBase自主研發(fā)的存儲引擎，通過數(shù)據(jù)編碼機(jī)制以lsm存儲架構(gòu)，無性能損耗，存儲成本至少省 80% 以上。

從金融走向千行百業(yè)、走向全球

2020年，OceanBase開啟商業(yè)化進(jìn)程，兩年來，積累了400多家客戶，不僅是金融場景，在運(yùn)營商、石油化工、電力、旅游出行等千行百業(yè)均有應(yīng)用，同時也在海外市場取得了優(yōu)異的成績。

OceanBase Cloud整體架構(gòu)

顯性成本之外，運(yùn)維是數(shù)據(jù)庫使用過程中的隱性成本，沒有良好的工具支撐，就會變向增加運(yùn)維的成本。OceanBase Cloud中，集成了一系列完善的工具，將螞蟻集團(tuán)多年的運(yùn)維經(jīng)驗(yàn)積累的能力賦能給用戶。

案例：助力攜程旅行實(shí)現(xiàn)高質(zhì)量客服業(yè)務(wù)服務(wù)質(zhì)量

在該案例中，攜程客服大規(guī)模的業(yè)務(wù)流量，數(shù)據(jù)存儲達(dá)到MySQL存儲極限，只能保證兩個月數(shù)據(jù)的存儲；MySQL主備架構(gòu)，無法通過橫向擴(kuò)容擴(kuò)展存儲性能；采用MySQL機(jī)房間主備方案，在機(jī)房故障條件下無法保證數(shù)據(jù)強(qiáng)一致和快速業(yè)務(wù)恢復(fù)能力。

針對上述痛點(diǎn)，OceanBase都一一予以解決。

針對存儲極限問題，OceanBase替換MySQL，獲得接近85%的數(shù)據(jù)壓縮能力，同樣的存儲配置情況下即可獲得存儲一年數(shù)據(jù)的業(yè)務(wù)價值。

針對擴(kuò)容問題，采用OceanBase提供的橫向擴(kuò)容能力，通過OCP一鍵式白屏操作，加減機(jī)器即可應(yīng)對業(yè)務(wù)的擴(kuò)所容，保證業(yè)務(wù)的服務(wù)質(zhì)量。

針對高可用問題，基于OceanBase多副本一致性保證，保證RPO=0 ，RTO<3分鐘。

整個遷移過程非常平滑，OMS數(shù)據(jù)遷移和同步能力，保證了數(shù)據(jù)庫切換過程的平滑穩(wěn)定。遷移后，攜程在同等硬件投入前提下獲得超過一年的數(shù)據(jù)存儲能力，滿足業(yè)務(wù)需求；自動的故障切換，提高針對機(jī)房，機(jī)器故障的快速恢復(fù)能力，保證SLA；同等應(yīng)將投入前提下，通過技術(shù)升級，得到強(qiáng)數(shù)據(jù)一致性保證，降低數(shù)據(jù)丟失風(fēng)險。