【觀察】OMS釋出，產品化加速OceanBase商業落地
老魚/文
經常看筆者文章的朋友，對OceanBase應該不會陌生，源自螞蟻金服和阿里巴巴業務，且完全自主研發的一款金融級分散式關係資料庫。
作為資料庫領域的觀察者，筆者見過不少號稱自主研發或基於開源軟體二次開發的商業資料庫產品，OceanBase是其中為數不多，讓筆者覺得靠譜的資料庫產品，因為它來自於業務的真實需求，更為重要的是接受了業務的檢驗。
試問，一個連自己都不敢用或從未在真實業務中採用的資料庫產品，讓客戶去當小白鼠，客戶又如何能放心去使用？ 這些年，資料庫技術領域風起雲湧，引發了百花齊放的盛局，但細數眾多的新興資料庫產品，真正能做到這點的卻很少，穩定性、效能都無法讓市場信服。
全球最大的雲端計算公司，亞馬遜AWS的技術實力毋庸置疑，自研資料庫產品很多，從關係資料庫、資料倉庫到NoSQL資料庫一個不缺，但即便如此，亞馬遜自家核心業務系統卻依舊跑在Oracle之上。
而OceanBase早在商業化之前，就已經在支付寶的核心業務上落地。據瞭解，目前支付寶全部核心業務：交易、支付、會員、賬務系統均執行在OceanBase資料庫上。
每年的“雙十一”則是對OceanBase的一次大規模壓力測試。2017年更是創造了4200萬次/秒處理峰值的紀錄，這在全球也是絕無僅有的。
不過，作為新興資料庫產品，OceanBase雖然風光無限，但也同樣面臨挑戰，那就是產品化不足。因為，不是每家金融企業都有著阿里般強大的技術能力，這勢必導致對產品化依賴程度很高。
螞蟻金服資深總監馮柯對筆者說，OceanBase在商業化輸出過程中，一開始，的確遇到不少這方面的問題。同一個元件，在阿里內部用的很好，但跑在外面就會出現各種各樣的問題。因此，在過去的一年裡，OceanBase團隊在產品化上做了很多。
2018年9月，OceanBase2.0釋出，在產品化之路上又邁出一大步。同時，還對OCP（OceanBase雲平臺）做了大規模版本升級，最核心的變化是把平臺原來依賴的所有外部元件全部去掉，從而使得OCP進化成可以在外部獨立部署的通用型產品。
在2.0釋出不到4個月，2019年1月4日，螞蟻金服ATEC城市峰會上，又正式釋出了一站式OceanBase遷移服務OMS（OceanBase Migration Service），該服務目前支援的資料庫包括Oracle、MySQL、OceanBase。
實際上，OMS並不是憑空出現，而是做了很多年。螞蟻金服資深技術專家師文匯告訴筆者，在過去的十多年時間裡，螞蟻在整個基礎資料庫架構上一共經歷了三代升級。第一代的IOE架構，第二代的OE+分散式中介軟體架構，第三代架構是OceanBase+分散式中介軟體。架構的迭代，涉及到大量的資料庫遷移工作。到了第三代，更是涉及核心業務全面從Oracle往OceanBase遷移，非核心業務從MySQL向OceanBase遷移。
據螞蟻金服技術專家韓谷悅介紹，OMS方案調研於2015年啟動，基於此前大量遷移積累的經驗和踩過的坑，到2016年OMS已經有了平臺化的架構，與此同時，OceanBase從0.5升級到1.0。2017年，OMS在技術功能和任務編排方面已日趨完善，並完成長尾Oracle庫的遷移，2018年完成MySQL遷移到OceanBase。與此同時，在商業銀行也實現了OceanBase一鍵遷移。
通常在資料庫遷移中，企業最關注3個方面的問題，其一、如何平滑遷移已有的資料和應用？眾所周知，企業應用絕大多數都是圍繞資料庫來開發，因此，在決定採用新資料庫之前，如果無法準確掌握業務改造的工作量，就無法有效控制專案進度風險。如果無法對新系統進行準確的容量評估，就無法提前識別和規避切換後系統可能出現的效能問題。
其次，如何最大化的降低資料遷移的成本？如果無法保證關鍵資料遷移過程中的遷移效果和資料質量，長時間的業務停機將是不可避免的。這對絕大多數企業尤其是金融企業來說，是無法接受的。如果切換後一旦新系統發生不可預期的穩定性問題，沒有整體可回滾能力，那業務就將嚴重受損。
最後是如何將時間壓縮到最短？帶著這3個問題，我們看看OMS的遷移能力與優勢。
以螞蟻商戶平臺數據庫遷移為例，螞蟻商戶平臺主要承載商戶檔案，訂購關係、簽約等資料和相關服務能力，在遷移到OceanBase之前，業務有部分跑在MySQL之上，也有部分跑在Oracle之上。
隨著商戶不斷增加及線上線下業務場景的不斷豐富，商戶平臺的整體資料規模已經非常龐大，並且還在呈現不斷上漲勢頭，效能瓶頸和風險日趨明顯。但遷移到OceanBase不可避免的要面臨風險和挑戰。
首先面臨的問題就是，異構資料庫相容性如何？其次是海量資料庫遷移資料質量如何保證？最為重要的是，商戶平臺直接對接支付系統，在螞蟻核心業務和交易鏈路中都承擔著非常重要的職責，如何做資料庫遷移才能讓業務無感知，實現平滑的切換和回滾？
據韓谷悅介紹，在業務評估與改造方面，此前遷移一個業務最少需要花費一到兩個月時間，進行業務改造和適配，但基於OMS自動化的相容性評估報告以及負載回放能力，螞蟻商戶平臺業務前期改造只用了一週。
資料遷移和校驗方面，雖然遷移時長與資料量及網路資源密切相關，但在提升遷移質量方面，OMS可以將增量遷移的延遲控制在毫秒級，即便跨城的情況下，最多也只需要三秒鐘，而對於驗證出所有不一致的資料，OMS還提供修正的結果方案，從而極大提升遷移和校驗的整體效率。
在業務切換方面，通常切換前需要制定比較嚴密的方案，並且切換之前和過程中需要檢查和校驗環節非常繁瑣，因為一步差錯就可能會導致資料不一致，OMS通過引入大規模編排能力把所有繁瑣環節都落到了平臺中，OMS還提供了整合部分中介軟體的能力，無論在遷移還是校驗過程中都用時很少。
在業務回滾方面，回滾之前需要承擔重大的決策風險，商戶平臺業務進行切換整體遷移過程中也發過抖動，但從登陸系統到完成回滾只用了幾分鐘。
韓谷悅說，螞蟻商戶平臺整個遷移時間在3個多星期，不足一個月。因此無論是從人力成本還是時間成本上看，基於OMS都得到了極大提升。
總的來看，OMS亮點無論是多型別資料庫支援，分鐘級即時回滾，負載回放驗證，秒級資料驗證，亦或是一鍵完成遷移等等，最終的結果都是降低業務向OceanBase資料庫遷移的門檻，從而加速OceanBase商業化落地。
對金融企業而言，系統架構從集中式轉向分散式是大勢所趨。在資料庫層面，要從單機資料庫轉向分散式資料庫雖極具誘惑，但更換資料庫，企業決策依然會非常謹慎，因為涉及到巨大的風險和成本，其中就包含資料庫遷移過程中的風險和成本。而OMS的出現至少一定程度上消除了這一阻礙。
而截止到今天，OceanBase已經在南京銀行、浙商銀行、人保健康險、常熟農商行、蘇州銀行、廣東農信、網商銀行等多家商業銀行和保險機構上線。全球前三名的支付平臺，兩家的核心繫統都在使用OceanBase資料庫。