更換引擎的目的是為了擁有更好的動力，做更多技術(shù)上的創(chuàng)新。但是橫亙在眼前的問題是，如何才能做到穩(wěn)妥創(chuàng)新，保證駕駛中的飛機(jī)平穩(wěn)順利的運行，這其實是有非常大的挑戰(zhàn)。

在過去三代架構(gòu)的演進(jìn)中我們可以看到，本質(zhì)上每一代架構(gòu)的迭代基本上都是以兩到三年為周期，這其中會有非常高的人力投入和成本開銷。

第二個挑戰(zhàn)就是從傳統(tǒng)的商業(yè)數(shù)據(jù)庫遷移到OceanBase數(shù)據(jù)庫之上，我們?nèi)绾伪ＷC遷移過程中以及遷移以后的穩(wěn)定性。

另外一個非常大的挑戰(zhàn)就是數(shù)據(jù)質(zhì)量，在金融企業(yè)里，數(shù)據(jù)承載的不僅只是錢，更承載了數(shù)以億計用戶的信任。所以數(shù)據(jù)一條不能丟，一條不能錯，這是我們做數(shù)據(jù)庫的底線。

當(dāng)然，包括兼容性問題和性能風(fēng)險也給數(shù)據(jù)庫的架構(gòu)升級帶來重重挑戰(zhàn)。

基于上述問題和挑戰(zhàn)，同時經(jīng)過螞蟻十年數(shù)據(jù)庫架構(gòu)升級的先進(jìn)經(jīng)驗，螞蟻金服為客戶打造了這款一站式數(shù)據(jù)遷移解決方案——OceanBase遷移服務(wù)（OceanBaseMigration Service，簡稱OMS）。

OMS的發(fā)展演進(jìn)

OMS的演進(jìn)是以業(yè)務(wù)為驅(qū)動，并且與OceanBase的架構(gòu)升級和不斷發(fā)展密不可分。

早在2014-2015年期間，螞蟻主站上的一些核心業(yè)務(wù)，包括大家熟知的交易業(yè)務(wù)，支付業(yè)務(wù)和會員業(yè)務(wù)等，需要從Oracle遷移到OceanBase上。當(dāng)時的OMS還是以一個工具類、模塊化的形態(tài)支撐著這些項目。

所以在2015年我們開始對OMS的方案進(jìn)行全面的調(diào)研，力求沉淀出通用的系統(tǒng)化的解決方案。

在2016年，OMS已經(jīng)有了平臺化的架構(gòu)，引入了大規(guī)模編排的思想，將整個遷移特別是切換過程中繁瑣易錯的環(huán)節(jié)全部集成到平臺。這一時期，OceanBase也完成了從0.5版本到1.0版本的架構(gòu)升級，這一年OMS還支撐了網(wǎng)商銀行、印度PayTM以及主站的核心業(yè)務(wù)升級到OceanBase 1.0版本。

到了2018年的時候，無論在基礎(chǔ)功能層面還是任務(wù)編排層面，OMS都已經(jīng)被打磨得日趨完善。今年OMS已經(jīng)支持了螞蟻森林，螞蟻商戶平臺以及眾多大量核心及非核心的業(yè)務(wù)從MySQL遷移到OceanBase之上。與此同時，在外部業(yè)務(wù)包括很多已經(jīng)上線OceanBase的商業(yè)銀行，也已經(jīng)驗證了使用OMS一鍵遷移到OceanBase的能力。

OMS的方案優(yōu)勢

OceanBase遷移服務(wù)其實主要解決了五個重要的問題。

1.負(fù)載回放驗證：其中第一個核心的問題就是負(fù)載回放驗證，通過采集源端數(shù)據(jù)庫的SQL流量，在目標(biāo)庫OceanBase上回放，可以驗證其在OceanBase上的功能是否兼容、性能是否出現(xiàn)問題等。同時基于螞蟻DBA十多年的經(jīng)驗沉淀，OMS會為客戶提供性能等方面的調(diào)優(yōu)建議。

2.秒級數(shù)據(jù)校驗：第二點就是數(shù)據(jù)校驗，OMS有三層數(shù)據(jù)校驗，可以做到秒級的延遲。舉一個例子，比如說我們想把傳統(tǒng)商業(yè)數(shù)據(jù)庫替換成OceanBase，如果在遷移過程中任何一條數(shù)據(jù)出現(xiàn)了錯誤，在一秒鐘內(nèi)就可以快速發(fā)現(xiàn)。校驗的延遲可以完全保證在一秒以內(nèi)，根據(jù)螞蟻線上的經(jīng)驗，大概在100-200毫秒之間。

3.分鐘級即時回滾：第三點也是最重要的一點，就是OMS有隨時回滾的能力，而且回滾是無損的。這也是我們前面所強(qiáng)調(diào)的穩(wěn)妥創(chuàng)新的基石。

4.多種數(shù)據(jù)庫類型支持：目前OMS支持源端數(shù)據(jù)庫類型有Oracle、MySQL、OceanBase等等，支持全量遷移和增量數(shù)據(jù)同步。

5.一鍵完成遷移：整個數(shù)據(jù)遷移鏈路和回滾機(jī)制的搭建基本上都是通過一鍵操作完成，使用簡便。

OMS的技術(shù)架構(gòu)

OMS的核心方案其實非常簡單，我們把OceanBase變成Oracle/MySQL的一個備庫。

傳統(tǒng)的商業(yè)數(shù)據(jù)庫一般都是有主庫和備庫的：主庫承擔(dān)寫的流量，如果主庫出現(xiàn)問題，我們會把數(shù)據(jù)切到備庫，然后通過OMS提供的一整套虛擬主備庫的解決方案完成切換。比如原來Oracle有一個主庫一個備庫，然后OceanBase其實變成了一個虛擬的備庫。

整個數(shù)據(jù)庫架構(gòu)的升級也會變得異常簡單，簡單到只是做了一個主備切換?；貪L也會變得非常簡單，其實也是做了一次主備切換。

從OMS的整體架構(gòu)來看，其實一個非常關(guān)鍵的點就是，我們在傳統(tǒng)的商業(yè)數(shù)據(jù)庫和OceanBase之間建立了一套虛擬的主備鏈路，整個OMS里用到的所有組件，其實都是在螞蟻和阿里有很多年技術(shù)沉淀的，也都是基于真實場景所產(chǎn)生的。

OMS的遷移流程

OceanBase遷移服務(wù)的整體遷移流程其實只有七步。

1.評估：首先第一步是通過負(fù)載回放工具做兼容性分析;

2.PoC：接下來OceanBase云平臺可以幫助客戶部署一套PoC集群;

3.預(yù)遷移：然后OMS把線上的Oracle的數(shù)據(jù)預(yù)遷移到一個測試庫里；

4.驗證：在這個測試庫里用負(fù)載回放工具去回放這些SQL，然后找到SQL里不兼容，性能或者數(shù)據(jù)質(zhì)量不滿足預(yù)期的部分，并提供優(yōu)化建議；

5.正式遷移：前四步做完了以后，業(yè)務(wù)需要調(diào)整或者需要優(yōu)化的SQL已經(jīng)完成優(yōu)化，然后就可以正式遷移了。首先把原有的全量數(shù)據(jù)遷過來，然后再把增量變化的那部分?jǐn)?shù)據(jù)實時同步過來；

6.校驗：等到所有的數(shù)據(jù)準(zhǔn)備好以后，然后我們繼續(xù)完成三級校驗；

7.切換和回滾：等到所有的校驗都完成以后，可以一鍵完成切換和回滾功能。

通過這七步就可以輕松完成從傳統(tǒng)商業(yè)數(shù)據(jù)庫到分布式數(shù)據(jù)庫的完整遷移。

螞蟻商戶平臺承載著商戶檔案數(shù)據(jù)信息，訂購關(guān)系、簽約信息的數(shù)據(jù)和相應(yīng)的服務(wù)能力。其中一部分業(yè)務(wù)使用的是MySQL數(shù)據(jù)庫，還有一部分核心業(yè)務(wù)使用的是Oracle數(shù)據(jù)庫。

隨著商戶的快速增長以及業(yè)務(wù)場景的不斷豐富，商戶平臺數(shù)據(jù)增長迅速，數(shù)據(jù)規(guī)模相當(dāng)龐大。尤其是MySQL的單表瓶頸日益明顯，DDL變更、DML更新的性能與風(fēng)險已經(jīng)無法承擔(dān)。

螞蟻金服技術(shù)專家韓谷悅介紹道，“OceanBase能夠支持?jǐn)?shù)據(jù)的無限擴(kuò)展，滿足商戶業(yè)務(wù)的容量與性能需求。那么如果我們換一種數(shù)據(jù)庫底盤，其實所要面對的性能、穩(wěn)定性和數(shù)據(jù)質(zhì)量的風(fēng)險同樣不可避免?！?/strong>