2008年，王堅從微軟亞洲研究院常務副院長的位置上離職後，於當年9月加入了阿里巴巴集團擔任首席架構師一職，負責集團技術架構以及基礎技術平臺建設。加入阿里沒多久後，王堅就提出了“去IOE”的想法，即擺脫過去IT系統中對IBM小型機、Oracle數據庫以及EMC存儲的過度依賴。
2013年5月，阿里集團最後一臺IBM小機在支付寶下線。2013年7月，淘寶廣告系統使用的Oracle數據庫下線，也是整個淘寶最後一個Oracle數據庫。2014年，OceanBase替換了支付寶交易系統中的Oracle數據庫。2015年，OceanBase替換了支付寶支付系統中的Oracle數據庫。2016年，OceanBase替換了支付寶最核心的賬務系統中的Oracle數據庫。2017年，螞蟻金服全面去IOE。
從2011年開始參戰雙十一到2016年雙十一支付寶支付峰值12萬筆/秒的世界紀錄，再到2017年雙十一支付峰值達到25.6萬筆/秒，再次刷新2016年創下的峰值紀錄，這背後，是一個由OceanBase研發和運維組成的幾十人的團隊。2016年的世界互聯網大會，OceanBase入選世界互聯網領先科技成果，其它獲獎公司還包括特斯拉、IBM、微軟、卡巴斯基等。
在6000多名螞蟻員工中，這幾十個人辨識度很高，因為只有他們的工牌帶是“土豪金”，而其他所有人的工牌帶都是清一色螞蟻藍。“土豪金”工牌帶是螞蟻金服內部最高榮譽——CEO大獎。2016年5月，螞蟻金服董事長彭蕾親自為這幾十位技術明星戴上了“土豪金” 工牌帶，理由是這個小團隊自主研發的OceanBase數據庫，以遠低於傳統數據庫的成本，更高的可用性，扛住了支付寶一次又一次自我刷新的支付峰值世界紀錄，打破了IT核心技術長期被西方壟斷的格局。
從2017年開始，OceanBase跟隨整個螞蟻金服的金融科技開放，開始了向傳統金融賦能的實踐過程。2017年年底，OceanBase在南京銀行正式上線，OceanBase數據庫為南京銀行“鑫雲+”互金開放平臺提供金融級分佈式關係數據庫服務。OceanBase還出口到了印度和美國等地，為當地的支付業務提供數據庫服務。作為螞蟻金服自研的分佈式關係型數據庫，OceanBase從一開始的目標就是傳統商業數據庫的升級換代產品，並堅持走通用關係數據庫產品之路。
經歷了7年坎坷、成立的頭三年一直被邊緣化、多次面臨解散的OceanBase團隊，如今雖然集體戴上了“土豪金”，可是他們都知道OceanBase這樣的中國技術奇蹟，是阿里巴巴/螞蟻金服舉全集團之力所創造出來的成果，這個過程本身也堪稱“奇蹟”。2018年2月初，OceanBase團隊的主幹成員陽振坤、馮柯、陳萌萌、蔣志勇、楊傳輝等與筆者展開了深入的交流，介紹了OceanBase的來龍去脈。
OceanBase：劃時代的數據庫
▲OceanBase 團隊SQL開發方向負責人 陳萌萌
為什麼OceanBase能夠入選世界互聯網領先科技成果，能夠進入IBM、微軟等世界科技巨頭行列？首先，簡要回顧一下基礎軟件歷史。自1975年微軟公司創立、1977年甲骨文公司創立後，逐漸出現了商用操作系統和商用關係型數據庫產品。再加上1995年創立的BEA公司及其代表的商用中間件產品，傳統基礎軟件的核心技術：操作系統、中間件和數據庫，就此誕生。
除了BEA公司於2008年被甲骨文公司收購外，為什麼後來全球再也沒有企業能夠超越微軟和甲骨文公司的操作系統與數據庫及中間件產品呢？這其中的原因很多，除了最早投入、培養了最多的相關技術研發人才和技術積累外，更重要的原因在於作為全球化的商用軟件產品，無論是微軟的操作系統還是甲骨文的數據庫，都是伴隨著全球用戶集體使用、集體反饋、集體推動技術進步而打磨出來的。
實際上，無論是操作系統、數據庫還是中間件，本質上都是軟件和硬件集成在一起的優化技術，其目的就是通過軟硬件集成調優來達到計算效率最大化、成本最優、用戶體驗最佳、兼容性最廣、安全與穩定性最高等結果。以甲骨文公司的Oracle數據庫為例，其廣泛支持並行機、大型主機、小型計算機、工作站、個人電腦等多種計算設備，允許用戶在不同計算設備上使用並遷移Oracle數據庫，1994年的時候Oracle關係型數據庫支持超過100種硬件和操作系統環境，兼容多項國際及國家的數據庫相關標準。
令Oracle數據庫成名的，是OLTP聯機交易處理也稱為面向交易的處理過程，其基本特徵是前臺接收的用戶數據，可以立即傳送到計算中心進行處理並在很短的時間內給出處理結果，針對諸如銀行、證券、民航訂票系統等需要實時響應的關鍵性業務系統等。Oracle數據庫在全球的金融、電信、民航等各類系統和業務場景中得到了廣泛的應用，在應用過程中不斷改進技術，最終出現了一個“強者恆強”的結果。
正因為Oracle數據庫在關鍵性的OLTP交易處理中佔據了牢不可破的市場地位，這讓後來的數據庫廠商很難有機會再重複一遍Oracle數據庫曾經走過的這樣一個反覆實踐、反覆打磨、反覆修正的過程。原因很簡單，不會有企業願意把自己的核心業務拿出來，給新進技術廠商當實驗田。所以在以IOE為代表的傳統IT環境中，除了已經建立起市場地位的主流技術廠商外，其它的後起技術廠商包括開源技術開發商，只能在企業的邊緣業務或當地政府扶持的業務場景下，才有少量的機會。
這種情況一直持續到近十年的雲計算變革。雲計算實際上是由大型互聯網公司發起和主導的技術變革，在最近幾年逐漸從互聯網公司向傳統企業蔓延。雲計算的初衷是大型互聯網公司為了降低自己的IT支出，而從IOE架構向基於廉價PC服務器為主的IT架構進行演變的過程。雲計算最早起源於2006年亞馬遜推出的Amazon Web Service網絡服務，簡稱AWS。而到了2008年王堅成為阿里的首席架構師，負責集團每年的IT規劃與預算，這個時候王堅就意識到了IOE架構對於阿里長期運營成本的影響以及對未來業務發展的制約。
在2008年的時候，阿里的數據庫就已經是全亞洲最大的數據庫，也是Oracle最大的用戶之一，那年阿里還沒有啟動雙十一。從2009年開始的雙十一，每年產生和處理的數據量都在爆發式增長，如果一直採用Oracle數據庫的話，運營成本將是天價。而在另一方面，為傳統IT環境而設計的Oracle數據庫，並沒有考慮到互聯網的大規模、高併發、實時在線、大型網絡優化等新興需求。2008年的時候，Oracle數據庫就已經難以處理阿里的大規模數據量了。
本質上理解，OceanBase與Oracle數據庫一樣都是關係型數據庫，但不同的是OceanBase是面向超大規模互聯網公司的分佈式計算環境而重新開發的關係型數據庫，Oracle數據庫則相應可以理解為針對傳統企業的計算環境而形成的“單機”數據庫。
所謂“單機”數據庫，首先指Oracle數據庫所基於的硬件環境是IBM小型機和EMC企業級存儲所構成的高度穩定共享存儲環境，IBM與EMC的企業級硬件本質上就提供了高度穩定的共享硬件環境。其次，Oracle數據庫以共享存儲為理念，所有的數據庫看到的是同一個數據磁盤、共享數據訪問，因而可以確保所有的數據都可被訪問到，而且底層硬件本身也穩定可靠，所以是“單機”視角。
陳萌萌目前在螞蟻金服基礎數據部（OceanBase團隊）負責SQL相關方向的開發工作。2006年畢業於清華大學、2006年到2008年在歐洲核子研究中心（CERN）負責網格計算調度器的開發工作、2009年5月在美國威斯康辛大學麥迪遜分校獲得計算機碩士學位，陳萌萌先後在Oracle、華為美國研究所從事數據庫的開發和研究，他於2014年6月加入OceanBase團隊。
陳萌萌對於“單機”的視角有一個形象的比喻：就像今天使用PC服務器，要擔心如果突然某臺PC服務器掛掉了、甚至機房本身遭遇地震、火災等極端情況，如何保障數據訪問的穩定性。由於是完全基於PC服務器架構，OceanBase在處理數據訪問的時候，相當於把一臺原來的小型機或存儲設備從縱向“切片”成很多機器，再把數據分佈到這些分散在不同的機器上，數據需要通過網絡才能夠被訪問到。“以前是一個磁盤，現在看到的是幾十個甚至幾百個分佈在不同地方的磁盤，怎麼做查詢優化？這個訪問模式會非常不一樣。”
過去的傳統IT環境是集中在一個地點的高穩定、高可靠、高可用高端企業級設備，現在的雲計算環境是分散在不同地點甚至跨國家區域地理位置的廉價PC服務器機群。OceanBase與Oracle數據庫是基於同樣的數據庫原理，但底層的基礎計算環境發生了根本性的變化，這對於像亞馬遜、阿里巴巴/螞蟻金服和谷歌這樣的互聯網公司來說，有三條出路：一是與甲骨文公司合作，全面開放自己的業務和數據；二是採用MySQL等開源數據庫技術進行改良；三是從頭開始重新設計一個完全自主知識產權的數據庫產品。顯然，亞馬遜、阿里巴巴/螞蟻金服、谷歌都不約而同地走上了自研的道路。
這個原因其實很簡單，如果與甲骨文公司合作，需要全面開放自己的業務和數據不說，更重要的是互聯網公司的快節奏、快響應、快研發、與業務運維並肩開發等特點，已經超越了甲骨文公司等上一代IT公司的企業文化和公司機制。而對於開源技術來說，不同的開源數據庫只適用於特定的業務場景，由不同的開源社區“各自為戰”式主導各自的技術方向，互聯網公司需要針對不同的業務場景拼接不同的開源數據庫到一個大系統中，這無疑也不利於長期發展。而走全面自研的方向，是一種最辛苦、看似最不可能卻最具長期投資價值的選擇。
王堅從2009年開始在阿里搞雲計算，陽振坤從2010年加入阿里後開始搞OceanBase，兩條線幾乎是同時並進。陽振坤回憶，整個OceanBase其實並沒有一個產品經理，根本的原因是OceanBase作為商用關係型數據庫的升級換代產品，在OceanBase立項伊始就參照商用關係數據庫列了一個長達千頁的產品功能列表，隨後的OceanBase開發過程就是根據這個列表，但卻從分佈式計算的角度重新實現每一個功能。“直到2018年初，OceanBase還只是實現了這個列表中的部分核心功能，但足以支撐整個螞蟻金服的業務”，陽振坤錶示。從2017年開始，三年之內，OceanBase要實現商用關係數據庫的絕大部分功能。
能夠與OceanBase類比、可以稱為分佈式數據庫的產品，目前只有谷歌於2017年2月發佈的Spanner數據庫雲服務。陳萌萌認為，Spanner是谷歌從頭開始全部自研的分佈式數據庫，也是針對谷歌的交易業務場景，但總體來說並沒有阿里巴巴及螞蟻金服的交易業務規模大，而AWS推出的Aurora數據庫則更接近於Oracle數據庫的共享磁盤設計。“真正用分佈式架構解決像螞蟻金服這麼大規模事務性需求的分佈式數據庫，目前我們只看到OceanBase這一家”， 陳萌萌表示。
從第一行代碼起步到今天的百萬行代碼級產品、支撐雙十一的十萬筆級每秒支付峰值以及螞蟻金服的全面業務，OceanBase可以說創造了一個劃時代的數據庫產品。OceanBase是中國第一個具有自主知識產權的分佈式關係數據庫，也是全球首個應用在金融核心業務的分佈式關係數據庫。業內人士認為，OceanBase的出現，在高端金融領域打破了傳統商業數據庫的壟斷，為金融科技的國產化進程邁出了重要一步。
OceanBase：劃時代的中國技術
▲OceanBase 團隊架構師 馮柯
現任螞蟻金服基礎數據部（OceanBase團隊）架構師的馮柯，於2014年加入螞蟻金服，目前的技術領域為分佈式關係數據庫、數據存儲、性能診斷和優化。馮柯在入職螞蟻金服前，曾在國內數據庫廠商天津神舟通用數據技術有限公司（以下簡稱：神舟通用）任CTO，是浙江大學計算機應用專業博士，具有15年的數據庫研發和產業化經驗。
作為國內最早一批從事國產數據庫開發者之一，馮柯表示國內早期從事國產數據庫開發的人們，基本都成為先驅了。以前做國產數據庫，更多體現的是國家科研的意志，而不是企業的市場化行為。更為重要的是，自主研發數據庫需要的是行業背景和企業實踐。“數據庫產品是用出來的，不只是被研製出來的。”馮柯強調。專注於國產數據庫的國內的數據庫專業公司，到後來往往發展的不好，就是因為沒有行業屬性、沒有真正能夠找到成熟應用的市場。
“我當時加入螞蟻金服的時候，覺得螞蟻金服自主研發OceanBase這件事其實很另類，覺得非常不可思議。而且阿里巴巴原來是開源文化，為什麼會完全從頭開始做一個數據庫，這直到今天還是一個非常奇妙和神奇的事情。”馮柯回憶說，很多人都會問為什麼不從MySQL開源數據庫入手，“不管是自主研發，還是基於開源產品來做，從技術上面來看，沒有絕對的對和錯，很多時候是理想主義使然。”
正如馬雲所說，阿里巴巴/螞蟻金服對於雲計算和通用數據庫等自研技術的投入，正是理想主義的結果。在2017年9月的阿里巴巴18週年年會上，馬雲說：“讓阿里巴巴堅持18年的是因為我們有理想主義，堅持理想主義使阿里巴巴走到了今天。”“絕大部分人是因為看見而相信，很少部分人是因為相信而看見，”這是馬雲在阿里巴巴18週年年會上引用的話，“過去的18年，阿里是因為相信才有今天。”
蔣志勇現在是螞蟻金服基礎數據部（OceanBase團隊）SQL組負責人，致力於高可用、高性能、高可擴展性併兼具成本優勢的分佈式關係數據庫系統。蔣志勇於2014年加入螞蟻金服，之前在神舟通用負責數據庫開發長達十年之久。蔣志勇在浙江大學完成了計算機專業的本科和研究生學業後，即加入了中國航天科技集團下面的一家研究所，從事國產自研數據庫開發，當時主要為了科研服務的數據庫及存儲系統。蔣志勇在研究生期間就已經參與到該科研項目中，後來就加入了航天科技集團組建的專注於國產數據庫開發的神舟通用公司。
作為國內早期從事國產數據庫開發工作的專業人員，蔣志勇認為螞蟻金服開發自研數據庫與其它專業數據庫公司開發自研數據庫的最大區別在於螞蟻金服自有業務場景。“螞蟻金服不是一家數據庫公司，而是一家金融科技公司。OceanBase在螞蟻金服內部發展的一個基本前提，是能夠為業務不斷創造價值，這是跟傳統數據庫公司的最大差別。”
“之前的困境是開發了很多技術，但是很難找到一個真實的大規模場景去使用這些技術。但在螞蟻金服這邊就不一樣，我們做的技術都是業務部門迫切需要的、確實能解決業務痛點問題的技術，加上螞蟻金服的業務發展非常快，也逼著技術部門把產品做的更好，這是一個正向循環：不斷促進技術開發，同時又能對開發成果提供真實業務場景下的及時反饋。” 蔣志勇介紹說。
作為整個OceanBase的始作俑者，陽振坤的感受最深。“做自研數據庫，這真的是一把手工程，只有真的獲得企業最高層的決策支持才能做成。對於業務部門來說，哪個數據庫最穩定、最好用，就會選用哪個數據庫，因為業務部門的首要目標是發展業務。”為了嘗試自研數據庫技術，螞蟻金服的業務部門需要付出的代價是：修改業務系統，同時支持兩種數據庫，兩邊要能夠隨時切換，以便保證在自研數據庫出問題的情況下，還能夠切換回原有的Oracle數據庫。“所以一開始業務團隊在這件事情上其實並沒有積極的理由。”
來到阿里之後，陽振坤與其它阿里技術人員一樣，需要找到一個合適的業務場景，跟一個業務團隊並負責技術，為自己的技術方向謀一條“生路”，同時隨著業務的發展而壯大自己的技術。淘寶的技術“大牛”，大都是通過這條路徑成長起來的。在加入淘寶之前，陽振坤其實並不懂數據庫，他的本科與碩士都是數學專業，到了博士才轉到了計算機專業，因此陽振坤的長項在於基礎計算科學。
當陽振坤加入淘寶後，最開始選擇自己技術方向的時候，恰好趕上了一個千載難逢的“天時”與“地利”。“天時”就是當時互聯網對數據庫的需求激增。以前金融企業等用的Oracle數據庫，都是事先設計好業務場景，比如固定用於銀行櫃檯和ATM機器、服務於固定的人群，數據庫的併發量也很小，原來數據庫有幾十到幾百個人、最多幾千人的併發量就不得了，到了阿里巴巴雙十一以及支付寶業務的時候，一下就激增到幾十萬、上百萬人甚至是上千萬人的併發訪問，結果就是要原來的IOE投資要放大幾百倍甚至幾千倍，“誰都買不起了”。
而“地利”就是阿里巴巴/螞蟻金服自有龐大的業務和數據庫。“當時來阿里的時候，‘單機’在阿里系統內部就已經走到盡頭了。IOE等‘單機’的性能再好，也有個盡頭；‘單機’的盡頭，就是分佈式系統的開始。” 陽振坤及其團隊恰好是做分佈式系統出身的，而阿里巴巴/螞蟻金服內部有數以萬計的數據庫。雖然數據庫作為IT系統的底層，一旦出現故障就會嚴重影響整個業務系統，特別是支付等關鍵業務系統。但阿里內部總有一些業務，因為數據量和自身業務需求等因素，可以先試用自研技術，從而打磨自研技術。
淘寶收藏夾就是這樣一個業務，有大規模的數據量，其業務需求傳統數據庫又難以滿足。2011年的時候，淘寶用戶已達數千萬級，就算每人收藏十條即達幾億條的數量級。另外，淘寶收藏夾業務還有一個特點，就是數據庫訪問邏輯不太複雜，可以讓OceanBase團隊在短時間內開發出代碼並投產使用。如果選擇非常複雜業務作為目標，那麼可能需要耗費技術團隊幾年的時間才能開發出一個可用的版本，而業務卻不可能等這麼長的時間。
這個項目取名OceanBase，相對於Database而言，寓意要做一個海洋一樣的海量數據庫系統。完成了淘寶收藏夾的挑戰後，很快就難以在淘寶內部找到類似的業務場景，可以讓OceanBase技術團隊繼續生存下去。淘寶的核心業務已經應用了MySQL開源數據庫並且比較穩定，MySQL已經能滿足淘寶的大部分業務需求。到了2012年的時候，OceanBase團隊面臨要解散的危機。這個時候，王堅聯繫了當時的螞蟻金服CEO彭蕾，把OceanBase團隊推薦到了支付寶。而螞蟻金服的CTO程立，又極大地支持了OceanBase的發展。2014年雙十一，程立出面，把交易流量的1%切給OceanBase，但實際的結果卻是切了10%，因為當時的Oracle數據庫系統確實支撐不了洶湧而來的巨大流量。
後來的結果是OceanBase成功支撐了2014年雙十一10%的交易流量。但就在2014年6月份，當OceanBase已經從技術上準備好，需要切到交易業務時，因為業務系統改造的工作量大，導致OceanBase兩個月都無法上線。“到了8月份，我急了，就給魯肅（程立）和Lucy（彭蕾）寫郵件，這個事情後來就推動了。”
除了王堅、彭蕾、程立等阿里巴巴/螞蟻金服等“一把手”對於OceanBase的大力支持外，當時負責阿里巴巴整個後臺系統的劉振飛從第一天起就一直是OceanBase的堅定支持者。劉振飛於2006年加入阿里，曾任淘寶技術保障部總監，後來升至阿里巴巴副總裁負責技術保障部、是阿里巴巴合夥人之一，現任阿里集團首席風險官兼任高德總裁。正是劉振飛的支持，才讓淘寶收藏夾用上了OceanBase。“當時振飛負責整個阿里巴巴的後臺系統，包括數據庫，沒有他的鼎力支持，OceanBase無法在任何業務上線。”陽振坤回憶。
“甲骨文公司有十幾萬人，從事數據庫核心研發的就有2千多人，而OceanBase一開始只有幾個人，到後來也才20多個人，憑什麼讓別人相信我們能做出比Oracle數據庫更好的技術與產品？這個確實聽起來就不靠譜。”陽振坤說，這就是雞生蛋、蛋生雞的問題，好的產品必須要有好的口碑才會有人用，但好的口碑和好的產品卻要在使用中才能打磨出來。數據庫是做出來、更是用出來的，中國有那麼多企業、高校和科研機構做數據庫，真正能夠在生產環境中大批量使用的少之又少。
今天回頭來看，OceanBase是阿里巴巴/螞蟻金服舉全集團之力而開發出來的自有知識產權數據庫，如果沒有阿里巴巴/螞蟻金服內部眾多“一把手”高管的鼎力支持，OceanBase團隊也許早就解散了。
技術成就：劃時代的分佈式數據庫
▲OceanBase 團隊複製數據庫事務開發的研究員 楊傳輝
通過核心業務的不斷上線，螞蟻金服幫助OceanBase渡過了自研基礎軟件產品最艱難的應用關。OceanBase不只是被研發出來的，更是被用出來的，是在生產系統中被磨練出來的。螞蟻金服作為互聯網金融的標杆企業，也通過OceanBase的應用，於2017年真正實現了所有核心業務100%去商業數據庫，這對整個金融體系來說都是具有里程碑意義的事件。
今天的OceanBase已經支持了阿里巴巴/螞蟻金服數百個關鍵業務的執行，其中有很多業務已經穩定的運行了多年。2017年天貓雙十一，支付寶創造了25.6萬筆每秒支付峰值的業界新紀錄，這對於數據庫來說，意味著每秒需要同時運行4200萬條SQL。
市場對關係型數據庫的性能和穩定性要求苛刻，真正的關係型數據庫都是磨礪出來的——OceanBase用了7年多的時間才取代Oracle成為了支付寶的賬務等數據庫。從2010年5月調研、6月25日立項開始，OceanBase的目標就是成為新一代的商用關係型數據庫產品，差異化競爭點在於底層的分佈式技術。全球三大數據庫廠商已存在幾十年，每家公司都擁有數以萬計的員工，而OceanBase之外做分佈式數據庫的全球唯一一個成功案例是谷歌。
OceanBase等後來者反映了以互聯網為代表的新興社會生產力對關係數據庫的新需求：互聯網訪問的用戶數量無法確定，可能在幾天甚至幾小時內增長數倍，傳統數據庫的垂直擴展方式根本無法應對。而全球前三大數據庫甲骨文、IBM、微軟都採用集中式系統的重要原因在於主機系統的穩定性，一臺主機動輒數百萬美元，存儲空間不夠就只能再買一臺，而且新主機系統上線還要數天時間。
楊傳輝總結OceanBase的六大特點：第一高可用、第二強一致、第三易用性、第四高性能、第五可擴展、第六低成本。
OceanBase作為分佈式關係型數據庫，最大的特色在於分佈式架構，而分佈式架構的一個基本特徵是能夠基於普通的PC服務器，構建一個滿足金融級更高的可靠性以及數據一致性要求的業務核心。而PC服務器硬件的不可靠，可以通過架構設計和軟件的可靠性來彌補，螞蟻金服的多年實踐已經非常清楚地向業界證明了這一點。
OceanBase又被稱為原生的分佈式關係型數據庫，即OceanBase是真正把所有與高可用及數據一致性相關的問題在數據庫內核層面就解決掉了，這和現在很多互聯網公司採用的中間層+單機數據庫的分層設計方式有很大的差別。從技術複雜度上看，選擇走原生分佈式數據庫這條路，無疑是非常艱難和痛苦的，這意味著在這樣的一個複雜的分佈式內核上，哪怕是實現一個簡單的功能，也需要付出比單機數據庫大得多的代價，但正是這樣的選擇，使得OceanBase真正具備了商業數據庫最重要的特徵：高度集成、整體交付，對業務無侵入；同時也真正解決了分層設計中無法同時實現的水平擴展及跨庫查詢等缺陷。
OceanBase的一個基礎設計思想是把每一份數據存放在三臺不同的機器上，那麼一臺PC服務器出故障的概率為千分之一的話，兩臺同時壞的概率可能就是百萬分之一，三臺同時壞的概率則是十億分之一。這樣做的成本雖然下來了，但如何保證三臺機器上數據的強一致性，這對於金融業務來說至關重要。
OceanBase高可靠的核心是基於PAXOS協議。PAXOS協議原來為分佈式理論上的算法，OceanBase在分佈式數據庫中實現了這一協議。PAXOS協議本質是少數服從多數的協議，具體實現：在n個(n>=3)個數據庫中，其中一個為主庫，其餘為備庫，每一筆事務不是同步到所有備庫，而是同步到超過半數的庫（包括主庫自身），比如3個庫中的2個、5個庫中的3個等等。一旦主庫故障，只要存活的庫超過半數，就可以自動選舉出新的主庫，並且恢復所有已經提交的事務（超過半數庫或者保證了每一筆提交的事務至少在一個庫上存在），這樣就允許少數的庫故障而不丟失數據、不中斷業務。基於PAXOS協議，OceanBase能夠實現單機/機房/城市級別，真正的無損容災；在少數庫故障的時候，RPO（恢復目標）為零，即沒有數據因為故障而損壞或丟失；同時基於完全自動的主備切換，能把RTO（恢復時間）縮短到30秒以內。
在強一致性方面，OceanBase還做了大量優化工作。比如對於事務消息改造為異步消息機制：事務開始時把消息投入消息系統，當交易全部完成後才通知消息系統投遞消息，而這個是一個非常關鍵性的改造，解決了高併發支撐同時的一致性問題。
所謂事務（transaction），這是面向OLTP交易型關係數據庫的一個關鍵流程。對於交易來說，數據庫的事務必須是“原子”的，典型的是銀行轉賬：這邊扣了100塊錢，另一邊就必須加上100塊錢，而不能這邊扣了那邊卻沒有加上。
為了保證數據庫的高可用，OceanBase實現了三地五中心容災架構在核心業務的落地，即使一個城市的所有數據中心都完全不可用，整個系統在數據層面仍然會做到不丟一行數據並繼續提供服務。例如支付寶的會員ID採用了OceanBase的三地五中心部署方案，即使其中一個城市故障，剩下的兩個城市至少還有3個活著的庫，仍然能夠自動選舉出新的主庫、立即恢復數據，並繼續提供服務。
在易用性方面，OceanBase作為後來者，必須要考慮到已有數據庫用戶的習慣，必須要兼容已經有的技術與產品，特別是在做數據庫遷移的時候，最好是原有的軟件代碼不需要改動一行也能直接遷移到OceanBase上，這就是易用性。
在可擴展性方面，每一個城市裡面的機房可以想象為一個可分片的大型數據庫，可作為數據拆分的基礎，例如把全中國的所有用戶分成一百份，那麼一份放在第一個機房，依此類推使得整體伸縮能力可達到機房級。理論上只要增加機房，就能無限增加伸縮能力。不論跨越多少個機房、多少個城市，所有參與部署的數據庫服務器在邏輯上是一個OceanBase集群的一部分，這就是所謂“原生”的概念，無論從應用視角還是運維視角，都是整體交付。
通過原生的分佈式數據庫設計，OceanBase實現了高可用、強一致、易用性、高性能和可擴展，這樣帶來的好處就是OceanBase性價比能做到傳統數據庫的10倍甚至更高，原先一臺高端服務器動輒幾十萬、幾百萬，而OceanBase僅用幾千元至多幾萬元的PC服務器即可，這從根本上來說就不是一個量級，諸如大型銀行使用的大型機可能以幾千萬、幾億元來計算。陽振坤錶示，OceanBase的性價比已經達到了現有商業數據庫的5倍~6倍以上，未來還將達到更高。
OceanBase的開發分為兩條線：一條線是從2010年開始開發的0.1、0.2、0.3、0.4、0.5這一系列的版本，主要是早期為了服務當時已有的阿里系業務；另一條線是從2012年開始構想的、完全從雲時代架構重新設計的分佈式數據庫OceanBase 1.0系列，2013年開始整體設計、2014年中旬抽出資源正式投入開發、2015年底開發完成，後又經歷了1.0、1.1、1.2、1.3到現在的1.4版本。
2016年雙十一的時候，有些支付寶業務還是基於0.5版本，有些業務已經升級到1.1版本，少量業務升級到1.2版本。而2014年雙十一，10%的交易數據鏈搬到了OceanBase上；2015年雙十一，100%交易數據鏈和支付數據鏈都搬過來了；2016年雙十一，整個賬務庫都搬過來了，這一核心數據庫被稱為“金融系統數據庫皇冠上的明珠”。
研發故事：軟件、硬件、業務一體優化
▲OceanBase 團隊SQL組負責人 蔣志勇
對於OceanBase這樣一個劃時代的分佈式數據庫，自然有寫也寫不完的研發故事，以下僅摘取幾例以體現OceanBase的研發之難。
陳萌萌介紹說，以前數據庫技術更多偏向軟件層的，硬件層有專業人員、專業技術和專業的公司來解決硬件本身的穩定性或容災等問題。但是在螞蟻金服這邊更多是軟硬結合的方案，OceanBase軟件從設計之初就考慮了硬件層面不穩定、分佈式系統的特徵，從而去做以前數據庫不會做的優化工作。以前的數據庫優化根本不會考慮到底層的硬件損壞、機器宕掉、網絡斷網、天災人禍不確定性問題，而今天OceanBase無時無刻不在考慮這些問題。“以前做軟件開發，先假設底層的硬件沒有問題，而只需要把上層軟件邏輯做好就行了，現在我們是整體的軟硬件考慮。”
以數據庫的查詢優化技術來講，比如傳統的銀行櫃檯，通過人工窗口提供服務，用戶的主要時間花在與人工窗口打交道等方面，對於數據庫的快慢體會不那麼敏感，但是螞蟻金服是互聯網應用，數據庫隨時的一個抖動或查詢執行時間變慢了一點，用戶馬上就能直接感受到。這與傳統應用場景差異很大，如果數據庫的一個查詢從一毫秒變到了五毫秒，傳統數據庫不會認為這是件大事，但是互聯網應用下，多出來的四毫秒可能被放大成為幾百毫秒甚至一兩秒，一旦出現這樣的時延，用戶體驗馬上就變差了。“我們每天都在做特別精細的事情，生怕一毫秒變成五毫秒這種事情出現，因此做了很多精確防禦。”
楊傳輝進一步解釋。數據庫查詢優化器本身是近似解，基本上不存在最優解，優化的目標就是逼近最理想的情況。在傳統應用場景下可以允許優化結果差幾個毫秒甚至更多，但是在互聯網場景下就很難接受這麼大的差異，所有的優化效果都要精確到幾個毫秒以內。
比如每一次在支付寶付款，點擊一下支付寶的付款按鈕，背後的數據庫可能要執行一兩百次數據庫的SQL查詢，優化器要為每一個查詢生成一個需要做的優化執行計劃，如果優化器在某一個場景下犯了一個錯誤，每個查詢多出了5毫秒，那麼整個鏈路就會多500毫秒，用戶在按下付款按鈕的時候發現有可能變慢了。如果再加上可能不止做支付，比如買商品後下單再要支付，這幾個鏈路加在一起就有可能慢幾百毫秒甚至上到秒級，這對用戶來說就已經不能接受了。
還有一個場景是地鐵的刷臉或者刷支付寶進站，如果用戶站在閘機前面半天刷不出來，那就不光是體驗問題了，有可能會引來連鎖麻煩，後面人也會被堵起長龍，這些現實的挑戰都要求OceanBase反應精確、迅速。楊傳輝介紹說，從關鍵業務系統的數據鏈路梳理上來看，一兩百條SQL是最普通的一次交易了，如果涉及到支付渠道不一樣，SQL執行的次數就會更多。
因為螞蟻金服本身是分佈式的系統，分佈式系統一個很大挑戰是對底層的基礎組件包括網絡要求非常高。如果網絡出現了問題，就會對整個服務產生影響。因此OceanBase不僅要對數據庫層做優化，還對網絡、磁盤、操作系統等軟硬件層都要做很精確的優化。
那麼OceanBase是怎麼解決的呢？OceanBase團隊從業務的開始階段就會介入到業務的設計當中，業務怎麼用數據庫、怎麼用最合理等等，從一開始就會參與整體設計，與業務方和整個架構一起演進。
蔣志勇所從事的SQL引擎和優化器工作，為OceanBase從無到有的建立了自己的SQL引擎，特別是讓原先的MySQL應用不改動任何代碼就能遷移過來。在數據庫的兼容性方面，OceanBase做到了對MySQL的兼容，螞蟻金服的內部業務從MySQL數據庫遷到OceanBase，不需要任何改動。
在優化器方面，涉及到的系統統計信息收集，是與螞蟻金服的業務體系架構結合起來，設計了一個動靜分離的架構：白天把統計信息都存儲到內存中，每天到業務低谷的時候再從內存寫到磁盤上。而不是像其他數據庫那樣直接寫到磁盤上，導致收集系統統計信息慢且不全面；也不像內存數據庫那樣全採用高成本的內存來存儲統計信息。OceanBase的這種準內存數據庫設計方式，既滿足了SQL查詢需要實時收集更全面系統統計信息的需求，也讓整體的信息收集成本沒有額外開銷。
OceanBase還在SQL語句搜索優化方面進行了精細化的調節。由於是完全自研的數據庫，對於Join連接查詢算法可以靈活適配多種算法，而在其他數據庫中則由於已經限制可選範圍而無法做到更精細的優化。“我們在搜索條件的改寫上面做了巧妙的設計，結果就是有更廣的可選擇範圍，而其他數據庫則只能在一個很窄的範圍內選擇最優策略，因此OceanBase的搜索結果更優。”蔣志勇說。
因為要兼容MySQL，OceanBase團隊也精研了MySQL，對MySQL進行了大量調優工作。在這個過程中，OceanBase團隊發現了MySQL的幾百個問題，向MySQL開源社區彙報後得到了確認。諸如MySQL對不同路徑執行出來的結果都不一樣、MySQL的語義不是非常完整等等，都是OceanBase團隊在使用MySQL中發現的問題。特別是由於阿里巴巴和螞蟻金服的業務規模日益擴大，經常會踩到各種技術的極限門檻，OceanBase團隊就曾經在開發MySQL接口驅動程序的時候，通過業務排查發現某個事務已經回滾但數據還是被提交進入了數據庫，導致會出現轉賬已經取消但錢還是被轉走了的現象，團隊排查了很久後終於發現是由於MySQL客戶端的一個變量設置本身有問題，但這種問題只有在極限條件下才有可能出現，屬於小概率事件。OceanBase團隊就是這樣逐一排除小概率事件，最終走向了通用型產品的道路。
通用型產品與場景化產品最大的區別在於通用型產品能夠適配絕大多數場景，而場景化產品則只能適配單一的場景。馮柯表示，這就是商業數據庫最強的地方，因為能夠匹配絕大多數的場景。也許商業數據庫的技術不是最強的，但價格那麼貴還有用戶買，就說明商業數據庫的總體擁有成本更低，一個產品就能適配大多數場景。而能夠適配絕大多數場景，就說明把已經能踩的坑兒都全部踩過了，今天的OceanBase也在經歷同樣的過程。
OceanBase踩過的另一個坑兒，也是在極限情況下才會出現的Linux系統bug。OceanBase本身是在Linux和C語言基礎上開發的分佈式數據庫系統，2010年到2011年OceanBase團隊在支持淘寶收藏夾業務，2011年雙十一的時候遇到了穩定性的問題。當時的Linux有一個直接訪問IO的特性，這個特性出現了bug，而且是在極限條件下才會被觸發的bug。
楊傳輝回憶當時距離2014年雙十一還有不到一個月的時間，是一個週五出現的問題，導致淘寶收藏夾一天之內連續宕機三次、每次一個小時左右，每次宕機後恢復收藏夾的流量，一旦訪問量超過一定量就又觸發了Linux內核的bug導致再次宕機，直到週五晚上8、9點後淘寶訪問用戶變少後才恢復了運轉。由於當時的開發團隊主要集中在北京，因此第二天的週六早上所有團隊成員搭第一班飛機從北京飛到杭州來解決問題。“當時的氣氛很緊張，如果這個問題解決不了，OceanBase團隊當時就會解散。”楊傳輝回憶當時的情況，而且在解決問題的時候，負責寫代碼的程序員的壓力也很大，後面有兩三個在盯著到底怎麼寫代碼。“當時也並不確定這麼做就一定能解決問題，只是覺得有70%-80%的概率能解決問題，後來還真解決了這個問題。”
“阿里巴巴/螞蟻金服的系統發展太快、一直在變，OceanBase也一直在開發新功能，又要支持線上業務，而雙十一的爆發可能會是平常流量的十倍，而像Linux內核bug這樣的問題，如果只是平常流量的一兩倍，是根本不會觸發的，它只有在爆發十倍的時候才會出現。所以我們特別緊張，也沒有時間讓我們仔細去分析，慢吞吞地解決問題。當問題來的時候，所有人加班解決，就是這樣。”楊傳輝說。
馮柯回憶說，他加入OceanBase後的第一件事是做診斷監控，當時沒有人願意做這件事，因為最主要是要到系統中埋點，大家都認可這件事很重要，但是沒有人願意去做，因為它涉及到所有的模塊，是一件非常吃力不討好的事情。而自己當時選擇做的原因，是因為這對業務來說非常重要，是必須要做的事情，當時也碰到了很多的挫折，出了很多問題。例如OceanBase診斷監控功能剛上線的時候，有N個人去看監控，會得出各種不同的結論來，“大家覺得這個功能完全不能用，覺得做得很爛，所以當時參加的同學很沮喪，覺得沒有被承認”。馮柯當時鼓勵團隊，最困難的時候反而是團隊進步最快的時候，“別人對你的批評最多的時候，其實是你進步最快的時候，你的產品能夠獲得更多資源，能夠被更多的人認識到，這其實是非常好的，那個時候的觸動確實很大。”
OceanBase是一個一邊在業務中“討生活”，一邊尋找機會發展壯大自己的過程。在“討生活”的過程中，OceanBase也會不得已做出妥協。楊傳輝回憶2010年的OceanBase版本有一個比較大的缺陷，就是設計了單點寫入。當時，把所有寫入數據全放在一臺機器上，這個版本可擴展能力比較差，本質上只能做垂直擴展而沒有辦法做水平擴展。另外，因為每個寫入都要經過那個節點，最後整個性能也相對更差，數據庫的功能也受限。這主要是OceanBase早期的版本，當時團隊的數據庫經驗沒有那麼豐富，也沒有時間做長期的開發，直到2015年重新設計開發的1.0版本才是真正面向雲時代的分佈式數據庫。這個期間，OceanBase團隊也從各個渠道引進數據庫人才，最終實現了數據庫的重構。
OceanBase經歷的失敗還有很多。楊傳輝回憶，OceanBase在2012年11月份轉到螞蟻金服到2014年實現了交易系統，這之間的2013年其實在從事淘寶的庫存項目而不是交易系統。當時，OceanBase團隊看到庫存的數據庫問題也是一大挑戰，這就像賣火車票系統的挑戰本質上也是減庫存問題——如果有兩人同時併發減庫存，就會亂掉。當時，淘寶的MySQL團隊也在做這個事情，最終業務部門選擇了MySQL的方案，就是因為業務團隊當時覺得用MySQL更放心，“就這一個原因，也沒有其他的點，最後沒有選擇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的內部創業史，對於數據庫技術來說在螞蟻金服內部創業要遠比在公司外部創業好，因為根本找不到像螞蟻金服這樣願意把自己的內部業務拿出來當“小白鼠”。“我覺得我們這些人正好趕上了一個很好的機會，所以我就跟大家說這是千載難逢的機會，我們一定要做，而且一定能做成。
閱讀更多 螞蟻金服科技 的文章
