厲害了，螞蟻金服！創造了中國自己的資料庫OceanBase（下）

厲害了，螞蟻金服！創造了中國自己的資料庫OceanBase（上）

接上文：

OceanBase的研發方法論

總結OceanBase的開發過程，總會試圖尋找一些研發方法論，就像微軟的軟體開發「三駕馬車」那樣的方法論。但正如陳萌萌所總結的：「我們其實更多的時候是與運維、業務團隊等一起在定義問題。我們會看到一些問題，找到真正要解決的問題是什麼，然後幫助用戶定義這個問題。在定義問題時，有時候我們會開一個會，分析某問題是由資料庫團隊解決、還是由業務團隊解決，而在開會之前可能大家都不知道最後要達到什麼樣的效果。很多時候我們在做這些不確定的事情。」

OceanBase本身是在做一個沒有先例可參考的分散式資料庫，純粹做分散式系統，全世界谷歌做得最好。陽振坤在百度時所帶領的分散式團隊已經是國內當時最強的分散式技術團隊，也從谷歌吸收了很多分散式技術的思想。但當後來試圖把分散式架構與關係型資料庫結合在一起的時候，就再也沒有先人的經驗，而只能靠團隊自己琢磨。雖然OceanBase到目前為止還沒有發表過論文、還是在做業務，但楊傳輝回憶OceanBase中有很多是別人沒有想過方法，可能要做一個新的方案要想好久，要思考半年到一年後面再決定去做。

在具體開發的執行過程中，測試是很重要的工作。分散式系統的異常處理很容易出錯，平常機器不出故障，到上線業務突然出一個故障時，可能就是一個大故障，而這種異常處理的測試比較難。OceanBase有容災模擬框架，就是隨時把一台機器殺死，而這樣的容災測試隨時在運行。另外，對於並發處理的測試，即某個條件的達成可以突然觸發兩個線程的先後順序或一個變數的訪問順序出錯，OceanBase也是隨時在模擬這樣的場景，讓這樣的小概率事件儘早出現。

在開發的過程上，OceanBase通常是一個人寫出來的代碼，要另外一個人去讀和審查，通過的代碼才會提交。OceanBase團隊還寫了很多自動測試用的框架，開發人員要自己做單元測試和一部分的功能測試，集成測試則由專門的人來完成，OceanBase的測試人員很少只有幾個人，大部分的測試都是靠自動化完成。

因為OceanBase是軟體、硬體和業務集成在一起的整體優化，而當軟體、硬體和業務碰到一起的時候，經常會出現各種碎片化的小場景問題，那麼又是怎麼解決的呢？陳萌萌介紹說，當遇到這樣的場景時，就會提前把大家拉到一個釘釘群里，把需求丟到群中，技術團隊根據需求提供反饋建議，業務團隊也會反饋在試驗中遇到的問題。這些碎片化的場景和問題，很難區分到是軟體、硬體還是業務的問題，因此群里有運維、開發、業務甚至還有負責業務拓展的BD和負責產品的PD，只要需要關注的人員都可以進到群里。陳萌萌透露他自己平常關注的活躍群就至少在20個以上，也就是至少一天發一條消息的群，他也在更多的可能十天半個月才發一條消息的技術討論群中。

以前在甲骨文公司的時候，陳萌萌說大家更習慣用郵件的慢節奏溝通方式，到了阿里系就是碎片化的溝通。首先每個人有負責的業務或技術方向，空閑的時間就會把群里的來龍去脈都過一遍。有些群是按需找人，在群里被@了就肯定會關注這些消息，如果沒有被@，就會找不是特別緊急時候再把群里的消息過一遍。雖然群很多，但是真正過群消息的時候，幾分鐘時間還是能夠把過去幾天的消息都過一遍。這樣總是能區分哪些是需要第一時間響應的，哪些可以後續持續關注的。

一般OceanBase團隊的工作時間是早9點到晚9點12個小時，但也有大促的「雙十一」、「6.18」、春節紅包壓測等緊急情況。當然，隨著OceanBase的發展，需要處理緊急事件的情況在減少。陳萌萌回憶，以前跟著業務團隊壓測到凌晨，甚至說半夜被揪起來的情況，會經常發生。

「我記得經歷過很多故障都挺戲劇化的：因為一旦出現一些問題以後，各方面的人都會被半夜拉起來，大家臨時被拉到一個群裡面，誰也不知道當時發生了什麼，但是每個人可能有一部分的信息，大家很快把各自的信息扔到群裡面，這樣就對出來到底發生了什麼。每個人都有點膽戰心驚，生怕自己做的那部分導致了什麼問題。」陳萌萌回憶說。「我記得有一次故障，半夜11點說有一個問題需要大家上線去看，一幫人包括主管都上線看問題，一直到凌晨四五點。一開始大家都在，慢慢發現問題越來越聚焦，相關的人員就上來，一直到凌晨四五點才解決問題。中間大家在群裡面各種排查信息分析，提出各種建議，雖然沒有坐在一起，但就像關在一個屋子裡面開了連夜的戰鬥會一樣。」

陳萌萌總結了阿里這種獨特的技術討論群解決問題的過程：「這是一個不停過濾信息再分析的過程。如果一開始不掌握所有信息，誰也總結不了。對完信息後，有人發現說某個地方需要關注，別的人再把相關信息加過來，慢慢連成一個邏輯。當你回頭再看群里消息的時候，這個現象特別明顯。信息一開始是散的，然後慢慢才能達成一致，最後走下去。」

當然，群里也會有熟悉各種「疑難雜症」的「老中醫」，一般是經驗比較豐富的人員，見到的問題也比較多，所以別人可能還在猜測的時候，「老中醫」就會給一個很靠譜的可能性，沿著這個可能性去看的話，發現確實可以通過這個角度去挖掘解決問題的方案。

然而，即使討論出了可能的解決方案，「大家還是挺膽戰心驚的，敲命令都是讓專門負責運維的人員去敲，這個時候的關鍵在於手不抖、別敲錯，因為萬一敲錯了那就是二次故障。所以我們都會找一個心理素質好的同事操作，大家誰也不要吱聲，看著這個同事安靜地把命令敲完。」因為不管通過群里的討論，選擇一條最保險最靠譜的操作方式，但在系統裡面直接敲命令都有可能直接動數據，敲錯一個鍵就有可能把所有數據都刪了，這是沒法挽回的，「所有人在操作的時候都不敢出氣」。

當然，每次處理完故障後，也會復盤找到以後的解決方案，最後形成知識庫也就是應急預案再固化到程序里，通過程序防止下一個錯誤。

前面提到整個OceanBase並沒有一個統一的產品經理，因為OceanBase的功能列表是對標商業資料庫。但還是會有產品開發的規劃，通常以財年為單位、雙十一為重要節點，比如某個版本必須要在下一個雙十一之前做出來並且穩定運行，再通過雙十一檢驗。「保持這樣一個節奏」，蔣志勇補充。

成功之道：不斷證明自己

「以前分散式系統谷歌裡面是有的，但是資料庫領域沒有一個人用到生產系統裡面。包括我們最初用PAXOS協議做資料庫的時候，傳統資料庫從業人員帶著原有思維看這件事，大家覺得不可思議。我們與螞蟻金服的業務方交流，告訴業務方能同時做到一致性與可用性，不丟一條數據而且做到高可用，業務方覺得不可理解，因為業務方已經習慣了傳統資料庫的方式。」馮柯在回憶OceanBase早期的發展時，還是很興奮當時打破了傳統技術的思維。

改變一個人的思想是非常困難的事情。OceanBase作為資料庫領域的新進入者，優勢在於把分散式系統和資料庫結合起來。「其實OceanBase本身不是一個專業資料庫團隊，OceanBase的創始人本身都不是學資料庫的，而是最早從分散式存儲開始做起，OceanBase到很後面才真正有了SQL的功能。」作為傳統資料庫專家出身的馮柯說，OceanBase最吸引他的地方在於有機會能接觸到影響幾億人的業務。OceanBase對於傳統資料庫也不是一味模仿，而是在分散式架構方面做差異化，「我們今天不是簡單的功能模仿，每一個功能在OceanBase上，由於架構的不同，內涵其實是不一樣的，挑戰也不一樣。其次，今天在OceanBase真正上線一個業務，馬上就能服務到幾億人，這兩點是非常吸引像我這樣背景，包括從Oracle來的技術人員。因為OceanBase有非常好的應用場景。」

作為OceanBase的創始人，陽振坤經常強調資料庫不是被研製出來的，而是被用出來的。今天OceanBase如果推翻重來，或許會有更好的方案，但在發展的初期很多時候要考慮團隊的生存問題、滿足業務和場景的需要，所以當時很多的選擇是面向用戶的選擇，讓更多的業務能夠跑在OceanBase之上，通過這種方式來建立用戶對OceanBase的信任。

「如果大家當時能看見原來七年後OceanBase能長成這樣，我相信七年前的那個環境會好很多。但是這種如果是不存在的，很多時候你要先證明自己。」馮柯說。

楊傳輝介紹說，OceanBase從淘寶轉到支付寶，很大程度上是因為MySQL可以滿足淘寶的多數業務需求。淘寶屬於電子商務類交易型業務，與支付寶的金融交易差別很大。當時淘寶電子商務交易是可以偶爾的丟失數據，採用了傳統資料庫的主備同步來實現高可用，但是主備之間是非同步的，備機與主機的數據之間落後幾毫秒都是有可能的，MySQL主備同步模式已經能夠滿足淘寶電子商務交易。

從2012年底開始，OceanBase開始慢慢支持支付寶的交易，支付寶交易屬於金融系統，不允許有任何一條數據的丟失。淘寶如果數據丟失了一條，還有一個最後的手段，就是可以查支付寶。畢竟丟失數據的概率極低，只有在極端場景下才有可能丟失數據，而且還能向支付寶查詢，支付寶就是最後的防線。2014年，支付寶交易由Oracle切換成OceanBase，實現了一條數據都不丟失，而且保證高可用、強一致。這在傳統資料庫都沒有辦法做到：既保證一條數據也不丟失，又保證數據的高可用。因為對於傳統資料庫來說，這兩個要求是相互矛盾的事情。OceanBase創新地採用了分散式系統里的PAXOS的協議，第一次把這個協議用於傳統資料庫和分散式系統兩個領域的結合，並在2014年雙十一中得到了檢驗，後面的發展就比較順了。

蔣志勇回憶他剛來的時候，當時還是對於支付寶核心業務上OceanBase有很大的爭議。「2014年雙十一的時候，爭論很激烈，最後是CTO當時拍板要上10%。當時在上1%還是上10%這方面大家很糾結，因為畢竟雙十一10%的流量幾乎相當於平時的全量了。當時CTO拍板做10%，並且後面還挺順利。從那個時候開始，在核心業務上，大家就慢慢接受和認可OceanBase了。」

楊傳輝回憶當時為了趕上2014年雙十一的進度，時間非常緊張。上「雙十一」，就意味著在線上不能出一次問題，那時有大約近二十萬行代碼是半年之內一次性新開發的，但是上線不能出一次問題，因此對質量保證提出特別嚴格的要求。上線前做了很多容災測試、代碼檢測、設計檢測等，包括當時涉及到的所有SQL語句都做了全面測試。「即便是這些事情都做了，也還是有一定的運氣成分，最後OceanBase上線沒有出一次故障。因為當時七八月份對核心業務底層系統升級完後就不可能再升級了，後面確實一個問題都沒有出現，最後雙十一成功切了10%的流量。」如果當時出現哪怕一次問題，可能OceanBase將不再存在。

在螞蟻，遇到更好的自己

2014年的時候，OceanBase團隊面臨著當年雙十一的生死大考。而馮柯也是在2014年加入OceanBase團隊的，作為一個傳統技術和商業環境出身的技術人員，馮柯在OceanBase經歷了從傳統企業文化到互聯網公司文化的轉型。

「我那時有很強的思維慣性，剛來OceanBase的時候，覺得看什麼都不爽，OceanBase是別人寫的代碼，總覺得這裡不應該這樣做，那裡不應該那樣做。那個時候特別挑戰，也包括過去是我說了算，今天說了不算，反正是非常痛苦的一個過程。」馮柯來OceanBase前半年基本上處於每天無事可乾的狀態，後來主管就給他布置任務，讓他放下層級的觀念去把OceanBase源代碼看一遍。於是，馮柯當時就用了大概6個月左右的時間，看了將近20萬行、每個月5萬行左右的代碼，報了100多個bug，寫了很多文檔，做了最基礎的事情。

這個過程讓馮柯在從代碼上更了解OceanBase，能夠做更具體的事情，其次也是最重要的就是調整了心態。「我剛加入螞蟻金服的時候覺得很恐懼，覺得阿里是一個價值觀很強的公司，後來發現層級只是對你過去的一個認可，來了阿里之後就要忘了過去，從頭開始。把自己沉下去，再浮上來，你就會更加有力量。」當從代碼上真正認可了OceanBase，把OceanBase當作自己的產品，就能把自己全部投入到OceanBase中。「現在看兩年前的我，確實變化比較大。來了阿里之後，遇見更好的自己。」

之所以說到阿里之後遇見更好的自己，這首先是要放開自己、重新清零，打破思維定勢後就能給團隊帶來非常大的幫助。馮柯發現螞蟻金服的團隊文化不像國企那樣層級就代表決定權，在螞蟻金服必須要做事情、真正拿到結果並獲得大家的認可和信任，才能做更多的事情。「大家並沒有去想你是一個P10或P9，你不應該做這個事，你應該做那個事，這是我特別感觸的一點。螞蟻金服真的是一個非常專註技術、完全內部平等的文化，這跟我在之前的很多公司差別很大。」而這，正是在阿里遇到更好的自己的原因所在。

OceanBase商業化：再創造新時代

「OceanBase是真正想去做一款通用的分散式資料庫產品。產品化這點非常重要，這就要對用戶做高度集成的整體交付，而不是一堆技術拼起來。OceanBase在架構上是真正想去做一款能夠改變目前整個商業資料庫生態或者格局的產品，我不管它未來能不能做到，但當時非常打動我，也是吸引我加入OceanBase的原因。」 馮柯說：「分散式是OceanBase的亮點，但最重要的是OceanBase是按照產品的思維而不是單純解決業務的問題，當時我就看明白了，OceanBase未來肯定是要到外部發展。」

關係資料庫這個領域的理論已經比較早就成型了，多年來也沒有突破性的進展。而OceanBase這些年做的事情，其實是在做一個分散式的關係資料庫產品。在做產品的過程中，最大的問題是要有特別好的場景來檢驗它，從而演變成一個能夠商業化的產品。螞蟻金服最大的優勢是業務場景非常豐富，讓OceanBase在服務外部客戶之前，就在內部得到非常充分的鍛煉，而這些鍛煉很難通過外部用戶去獲得。

蔣志勇強調，資料庫產品化需要時間去歷練，如果抱著非常投機的心態參與就很難實現。「所以從業人員要確實對這個有興趣，並且要願意長時間堅守、慢慢打磨，把OceanBase從幾個人做出來的軟體，變成一個很好用的通用產品。」

從2017年開始，OceanBase跟隨整個螞蟻金服的金融科技開放，開始了向傳統金融賦能的實踐過程。當然，這個過程也不是一帆風順。雖然OceanBase已經取得了很大的技術成就，但在外部用戶應用OceanBase的過程中，往往會被很多具體的小細節所「絆倒」。現在負責OceanBase外部業務的馮柯表示，外部客戶往往沒有螞蟻金服這麼成熟的技術體系，還處於各種傳統技術混搭的局面，在這種情況下如何把OceanBase在外部用戶的業務環境中落地，這都是需要具體解決的問題。

OceanBase終於邁出了商用的一小步：OceanBase在南京銀行正式上線，OceanBase資料庫為南京銀行「鑫雲+」互聯網金融開放平台提供金融級分散式關係資料庫服務。而這主要取決於南京銀行的意願，「南京銀行自身有非常強的意願和情懷，把整個互聯網的核心業務完全架到OceanBase之上。南京銀行就像螞蟻金服內部的業務方一樣，真正與技術團隊站在了一起，包括南京銀行的很多設計都是超前的，即使目前的業務量不需要這樣設計的也會提前布局，後面有一個非常長遠的規劃。南京銀行項目為什麼成功，就是因為這一點。」 馮柯總結南京銀行的成功。「南京銀行當時是陽振坤老師去談的，南京銀行也有競標，也不只螞蟻金服一家。當時南京銀行技術負責人問了陽老師一句話，你們到底有沒有決心替換掉Oracle，這句話撞到陽老師的槍口上了。」

陽振坤回憶OceanBase的整個發展歷程，「首先肯定是要滿足內部的業務需求，如果連自己的需求都滿足不了，就根本談不上做成一個真正的商用資料庫。也許Google吃虧在他們的業務部門比較強勢了，所以做出來的Google Spanner就是一個滿足自己內部需求的產品，所有的都是自定義。而OceanBase走了一條標準化之路，我們支持標準的資料庫介面、標準的資料庫語言，所以能夠產品化。」

從2010年5月調研、6月25日立項開始，OceanBase的目標就是傳統商業關係資料庫的更新換代產品：2012年底支持簡單的SQL；2014年支持比較有限的SQL；2016年基本兼容了MySQL，對SQL的支持開始豐富起來。這是一個由分散式到與資料庫結合的過程。接下來，OceanBase要兼容商業資料庫。再接下來，就是要發展OLAP技術。

與OLTP技術的要求不同，OLAP偏向大型數據分析，對於查詢處理、計劃生成、性能和調度等的要求非常高，對於分散式集群的大型查詢，怎樣通過調度把負載分配到每一個合適的節點，讓整體的吞吐率和響應時間都能達到一個比較好的平衡，都需要大量的工作。

總結OceanBase的成功，可以說是阿里巴巴/螞蟻金服舉全集團之力完成的「壯舉」。用楊傳輝的話說，就是阿里對技術容忍度超乎想像的高。馬雲經常講：我不懂技術，但是我尊重技術。

陽振坤回顧OceanBase的內部創業史，對於資料庫技術來說在螞蟻金服內部創業要遠比在公司外部創業好，因為根本找不到像螞蟻金服這樣願意把自己的內部業務拿出來當「小白鼠」。「我覺得我們這些人正好趕上了一個很好的機會，所以我就跟大家說這是千載難逢的機會，我們一定要做，而且一定能做成。」

原文鏈接

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎

推薦閱讀：