本文根據馮柯老師在2018年5月10日【第九屆中國數據庫技術大會】

正文：

今天想和大家聊聊螞蟻金服和自研技術。說到螞蟻金服，大家很容易聯想到中國新四大發明之一的支付寶，從支付寶的擔保交易到風險識別、智能客服，再到更加基礎的數據庫、中間件以及大數據平臺，這些技術實際上是螞蟻金服在完成自身業務挑戰的基礎上進行的大量創新和發展。

如今，很多行業中的企業都開始考慮發展自研技術，不僅僅是互聯網行業。我希望能夠藉此次機會將螞蟻金服多年來在發展自研技術方面的實踐與思考分享給大家，希望能夠帶給行業一些啟發。

1995年，我第一次加入高校的實驗室，當時選擇的是數據庫方向。之後八年，我一直在做工程數據庫方面研究的工作。

2003年，當時國家給了我們一個很好的機會，我們就在思考是否可以藉此將目前的技術商業化，之後就做了11年。

直到2014年，我加入螞蟻金服。作為國內早期的自研數據庫團隊，我們起初發展得並不是很好。雖然技術一直在發展，但我們始終沒有找到一個真正成熟的商業應用場景。當時國內的市場環境也並沒有給技術迭代足夠的時間與空間。

但就是在那幾年，我們共同見證了商用技術在整個中國的快速興起，直到今天，它們依舊是絕大多數行業的主流。今天數據庫領域常說的IOE其實就是商用技術產品的代表，IOE本質是基於單機視角的集中式架構，在該架構中，硬件主要解決系統可靠性和擴展性問題，而軟件用來提供功能集成。

站在業務視角，這種架構是近乎完美的，最好的產品和最好的服務結合，當然價格也比較昂貴。大概在十年以前，整個互聯網行業進入快速發展期，集中式架構在擴展性和成本方面的問題越來越嚴重，特別是在經歷了雙11大促這樣的場景之後，所有人都可看出集中式模式在互聯網行業基本走到了盡頭。因此，系統從數據和業務兩個層面開始去中心化的過程，高端硬件被普通PC服務器取代，系統的擴展性和可靠性問題交由架構和軟件解決，分佈式中間件在這個時期得到快速發展，並迅速成為互聯網企業的架構核心。

開源技術由於其靈活和可快速定製等能力很快在互聯網行業得到普及。此外，文化也是一個重要影響因素。在多數互聯網企業中，IT技術人員的比例早已超過50%，在這樣一個崇尚自由創新的企業文化的影響下，只要技術可被替代，商用技術就再也沒有生存和發展的土壤。

近幾年，以螞蟻金服為代表，自研技術開始興起。一方面，自研的分佈式中間件經過數年場景沉澱已經完成整個企業從研發到生產的全面覆蓋，進而演化成了具備行業屬性的企業級分佈式架構。另一方面，更加基礎的自研技術，比如分佈式數據庫，也開始誕生並發展。那麼，為什麼會出現這樣的趨勢呢？

首先，經過不斷業務場景挑戰之後，我們已經越來越多地觸碰到已有商用技術和開源技術的天花板，我們需要通過發展自研技術解決這些問題。同時，當企業的產品和服務同數億個體的日常生活緊密關聯時，從企業內部開始誕生對核心技術自主可控的訴求。

今天，我們看到越來越多的平臺型和生態型企業出現，這些企業從過去的關注自身開始更多的關注整個生態，開始思考如何對生態賦能。商業賦能的本質是技術賦能，這就要求技術最終可以變為產品，無論是基於開源技術進行深度定製，還是完全從頭開始的自主研發，在我看來殊途同歸，重要的是自研才是技術走向產品的必經之路。

回顧螞蟻金服整個自研技術多年的發展歷程，我們發現有三個問題是非常重要的，換句話說，今天的企業想要發展自研技術需要先思考這三個問題：

第一個問題是技術的主場在哪裡？

過去的實踐證明技術不只是被研發出來更是被應用出來的，我們需要找到一個相對可控的市場為自研技術的迭代創造足夠的時間與空間，幫助技術團隊渡過早期的產品脆弱期，這一點非常重要。如果沒有這樣的主場，那就意味著技術團隊不得不在技術尚未得到充分驗證之前，就投放到競爭性的市場之中，這樣做的後果只有兩個，要麼你把客戶玩死，要麼你被客戶玩死。最終，技術團隊只能在一些企業的邊緣化應用中不斷試用。國內早期的許多技術團隊都在發展過程中面臨過這樣的問題，只能投入大量的技術力量滿足客戶在邊緣化應用中無休止的功能細節，整個團隊無法從這樣的市場活動中有效獲取資源，無法進行大規模的技術創新，也無法保證核心團隊的穩定。

第二個問題——技術的核心價值是什麼？

十年以前，我們覺得做技術尤其是數據庫這樣的基礎技術，必須要由專業的公司來做。如今，這個邊界變得越來越模糊。因為，在一個商業生態非常成熟、競爭已經非常充分、以存量為主的市場中，所有新進的技術必須有自己的核心價值，必須有差異化的地方，所以，技術創新非常重要。技術創新從哪裡來？只可能從行業實踐中來。今天，我們發展自研技術不能只是為了滿足自主可控，如果只是一味的追逐模仿商用技術，或者簡單的基於開源技術的拿來主義，技術團隊本身很難從這樣的研發過程中持續獲得正向價值激勵，企業也很難基於這樣的技術和產品打造良性健康的生態模式。

第三個問題——技術如何變為產品？

企業發展自研技術的目的是什麼？只是為了解決自己的問題？還是將來有可能解決更多人的問題？在整個自研技術發展早期，技術團隊通常沒有太多精力思考這類問題，但是技術團隊的領導者需要在一開始就想清楚這些問題並制訂相應的技術路線。首先是自己要堅信不疑，該技術路線會在今後很長一段時間給技術團隊帶來持續影響。即便是像數據庫這樣已經高度標準化的技術，在過去幾年的發展中，我們也經常面臨過在如何支持業務快速上線和如何保持技術的通用性之間的選擇。如今，我們很難說過去做的每一個選擇都是正確的，但是，不管如何選擇，技術團隊要有一顆產品的心。

如何找到自研技術的主場？當然是企業的自有業務，這是一個非常自然的邏輯。如果我們發展的自研技術連自己都不敢用，我們很難說服其他人使用。但是，企業光有自有業務是不夠的，企業發展自研技術需要考慮三個方面條件：

一是有想法：發展自研技術，企業是主體，企業自己有這樣的訴求是自研技術長期發展的根本動力。一方面，對於發展自研技術要解決的問題必須要有明確定義，要有現實存在的業務痛點，否則，技術團隊很難獲得足夠的動力和壓力；另一方面，對於要解決的問題必須要有明確的技術路徑。如果只有問題，沒有路徑，那就變成了單純的提需求。

二是有能力：我們既需要具備足夠的技術力量保證技術從路徑到實現，又必須有完整的技術保障體系控制自研技術在應用過程中的風險。自研技術的應用始終是一項高危工作，自研技術的最終的目的是應用到生產環境，風險控制是自研技術發展過程中非常關鍵的問題。如果無法控制風險，甚至導致企業生產運營面臨嚴重威脅，那麼，企業發展自研技術就是一個偽命題。

三是有擔當：決策者的擔當，即使技術能力具備，風險也可有效控制，我們仍然無法知道真正把自研技術用於核心生產的一剎那究竟會發生什麼，我們的團隊在過去幾年碰到過這種困境，一步天堂、一步地獄，決策者的擔當此時將發揮關鍵性作用。因此，我們建議企業發展自研技術必須是一把手工程。如果決策者沒有足夠的擔當並對可能的結果負責，單單依靠技術團隊自己，最後的結果很可能是技術團隊由於無法創造足夠的業務價值而逐漸消亡。

OceanBase這幾年在螞蟻金服的發展過程是一個非常典型的自研技術在企業內部落地的過程。OceanBase最早於2010年誕生於當時的淘寶，整個團隊發展的頭幾年，我們一直處於尋找穩定應用場景的過程。雖然我們支持了類似收藏夾這樣的項目，但當時整個團隊很多情況下實際上是處於一個邊緣化的生存狀態。

之後，我們加入螞蟻金服，也就是當時的支付寶。加入螞蟻金服之後，我們很快遇到了一個很好的機會。當時，螞蟻金服的核心業務大量使用商業數據庫，技術團隊需要回答的問題就是當商業數據庫許可到期以後，應該怎麼辦？是購買更多的許可？還是尋找合適的替代品？基於這個大背景，由決策者出面，將螞蟻金服10%的交易流量切換到OceanBase，這也是我們團隊第一次有機會承接螞蟻金服的核心業務。

當時螞蟻金服的分佈式架構已相對成熟，我們有一整套完整的產品灰度發佈體系，能夠控制住新產品上線的風險，甚至在業務層面進行了大量改造來對整個系統進行託底。即便如此，依然沒有人可以保證，當雙11流量迅速攀升時，OceanBase可以頂住。與此同時，內部質疑從未停止。當時的螞蟻金服已經使用了大量開源數據庫，既然有了可靠的開源數據庫，為什麼還要冒險使用OceanBase呢？此時，想法和能力都不管用，決策者的擔當再一次發揮了關鍵作用。

瞭解OceanBase發展史的朋友應該都知道，我們團隊在歷史上幾次面臨關鍵時刻都得到了貴人相助，而這些貴人就是當時在關鍵位置上的決策者。如果沒有決策者的擔當，那麼螞蟻金服的自研數據庫團隊早就不復存在。

2014年，OceanBase支持了螞蟻金服10%的交易流量，整個自研團隊邁出了重要一步。2015年，OceanBase支持了100%的交易和50%的支付，交易成為第一個完整支持的核心業務。2016年，OceanBase支持了100%的交易、支付，以及包括賬務、會員在內的更多的核心業務。

在支持賬務這件事情上，團隊再一次面臨關鍵考驗。熟悉金融系統的嘉賓應該知道，賬務是一個狀態型業務，同流水型的交易、支付相比，處理邏輯要複雜得多，容災邏輯也要複雜得多。實際上，業務團隊已經不能託底了，剩下的事情必須靠數據庫自己去解決。

此時，業務團隊選擇相信我們，然而我們團隊的壓力空前巨大，如果雙11當天數據庫中的數據出現問題，這會對螞蟻金服產生很嚴重的後果。幸運的是，我們最後扛過來了。

2017年，OceanBase終於迎來了重要的里程碑，我們把螞蟻金服所有核心業務中的商業數據庫都去掉了。也就是說，螞蟻金服通過發展自研技術，用了將近4年的時間，實現了對於核心數據庫的自主可控。開句玩笑，在今天的中國，即便商業數據庫被禁售，開源數據庫被閉源，我們也不怕。

自研技術在企業內部的落地，尤其是在核心業務的落地，是一件長期而艱難的工作。儘管如此，我們還是要回答一個問題——如何打造自研技術的核心價值。螞蟻金服對這個問題的答案非常簡單，就是用業務場景驅動，持續給技術團隊巨大壓力，跟得上就繼續發展，跟不上就被淘汰。螞蟻金服本身從不缺這樣的業務場景，今天我們遇到的很多技術挑戰，在整個行業乃至世界範圍內都是前所未有的。這裡，我只列舉三點：

一是極致的擴展能力：在過去八年的雙11大促中，螞蟻金服支撐的交易峰值提高了500多倍，數據庫處理峰值已超過每秒4000萬次。沒有人可以預測這個峰值未來會漲到什麼程度。對螞蟻金服的所有技術團隊來說，重要的是不讓技術和產品成為阻礙業務發展的瓶頸。

二是極致的容災能力：我的手機經常會收到一些推送消息，比如，系統將在今晚11點到明早8點之間進行維護升級，在此期間，某某服務將暫停使用。我相信大家和我一樣經常收到這樣的消息。試想一下，如果支付寶暫停服務幾小時會怎麼樣，以螞蟻金服今天所承載的交易量來看，不要說幾小時就是幾分鐘都會迅速演變成巨大的社會性問題。因此，保持業務極致的連續性的要求是懸在所有技術團隊頭頂的一把劍。

三是極致的成本：我們今天所面臨的線下支付場景，比如共享單車、地鐵公交，如果不能把單筆交易的成本控制在極低的水平，那麼普惠金融對我們來說就永遠只能是個夢想。對螞蟻金服而言，所有的使命和願景最終都會轉化為技術能力。

如何應對這些金融級的技術挑戰，架構是非常關鍵的。目前，我們在業內可以參考到的方案只有兩地三中心。兩地三中心是在一個城市部署兩個活躍的數據中心，在另一個城市部署一個災備中心，這是目前絕大多數金融機構廣泛使用的跨數據中心的擴展性和跨城市的容災方案。

如果仔細分析就會發現，該方案存在一些問題。

首先，從擴展能力看，由於核心業務只能被部署在活躍的數據中心，所以該方案無法解決核心業務跨城市擴展問題。換句話說，從業務角度來看，兩地三中心的本質是同城雙活；

其次，從成本來看，由於災備中心只在極端容災場景下被啟用，所以整個系統的資源利用率較低，相對應的成本就會升高；

最後，從容災能力來看，整個系統正常運作時，災備中心始終處於冷備模式，所以系統容災時可用性較低，容災切換風險較高。

因此，在兩地三中心的架構下，如果真的發生城市級故障，我們通常也不敢把業務切到災備中心，只能等待故障的數據中心恢復，在這個過程中，系統是無法提供服務的。

兩地三中心的本質是同一城市內跨數據中心的擴展性和可用性方案。對螞蟻金服來說，支撐億級的交易規模和保證99.99%的可用率都需要對現有架構進行升級，從同城雙活變為異地多活，從跨數據中心變為跨城市。由此，螞蟻金服開始了對單元化架構的技術探索。

單元化最初是支付寶用來解決業務和數據拆分後數據庫連接數過多的問題，通過更多的場景沉澱，單元化架構今天已經成為螞蟻金服異地多活和容災架構的基礎，單元化架構也是螞蟻金服自研的金融級分佈式架構SOFA的核心能力。單元化架構的本質是將系統進行水平拆分後的邏輯隔離，單元化中的每一個單元都具備更小的規模，但擁有完整的功能，從接入網關到應用服務器再到數據庫，每個單元依據規則支撐一定的流量和數據。

單元具備四個重要特性。

一是自包含性：比如賬戶充值交易所涉及的所有計算和數據都會被封閉在一個單元；

二是松耦合性：單元之間只允許進行服務調用，不允許直接訪問數據庫或其他存儲，對於必須跨單元的操作，比如位於兩個不同單元之間的用戶轉賬交易，服務調用需儘可能少，同時在不影響客戶體驗的情況下，儘可能異步化。這樣，即便兩個單元相距較遠，整個系統的響應也不會受單元間訪問延遲的影響；

三是故障獨立性：一個單元的故障不會影響其他單元；

四是容災性：單元之間相互備份，每個單元都保證在發生同城或異地故障時有可接管的單元，單元之間的備份方式是使用自研數據庫提供的多地多中心的一致性方案。

通過單元化架構，首先，系統的伸縮問題變成了單元的增減問題，而在此過程中，整個單元的規模和內部複雜性是相對穩定的，這就降低了系統整體伸縮的複雜度；其次，單元的故障獨立性使得我們能夠控制軟硬件故障的影響面；最後，單元之間可快速切換，這就使得我們處理同城和異地容災時可以更加簡單高效。

單元化解決了業務和服務層面的擴展性和容災問題，但數據層面的容災問題並沒有得到解決。如果發生城市級故障，我們仍然不敢把核心業務流量切換到另一城市，那我們實際上仍然停留在原地。但這個問題不管是商業數據庫還是開源數據庫都是無解的，我們可以通過各種技術手段儘可能降低故障切換時間，減少故障影響的客戶範圍，但無法避免資損的發生。這個問題，在我們有了自己的數據庫OceanBase之後，被徹底解決了。

OceanBase的核心是基於Paxos協議的多數派分佈式選舉協議，Paxos協議的價值已被業內廣泛認可。該協議保證只要多數成員依然存活，任何少數成員的故障不會影響系統的整體可用性和數據一致性。所以，如果把一個數據集群部署到三個或三個以上城市時，我們就可以保證任何一個城市的故障，系統都可以實現無損容災，也就是RPO=0。同時，系統可在30秒以內把故障切換到另一城市，故障切換過程在數據庫層面自動完成，對上層業務沒有影響。

另一方面，當我們把一個數據庫集群部署到三個城市時，為了避免任何單機故障導致的業務跨城市訪問問題，我們把數據庫集群中的副本數量從3個增加到5個，這就是我們今天所說的三地五中心，或者嚴格一點，三地五副本多中心。

從兩地三中心到三地五中心，我們解決了一個基礎又非常重要的問題，即便發生城市級故障，整個城市都不可用，數據庫層面仍然可以做到，系統不丟數據，不停服務。

螞蟻金服花了數年時間來演進基於單元化和三地五中心的異地多活和容災架構。今天，螞蟻金服已在多個城市部署了多個數據中心，我們所有的核心交易流量部署在所有數據中心並可隨時切換和調配，通過異地多活，我們實現了流量在全國範圍內的任意擴展，極大地提高了資源利用率。

最重要的是，我們提升了系統面對城市級故障的能力。螞蟻金服在如此大規模的金融交易系統中實現了這樣的容災能力，這在世界上屬於首創。

今天的螞蟻金服已經是一家成熟的生態型企業，作為全球金融科技創新的領導者，螞蟻金服已經開始面向生態中所有的合作伙伴全面開放和賦能，賦能是全方位的，從技術、產品、數據、平臺、業務、運營，這與過去單一的IT賦能存在本質不同。在過去幾年，技術和產品如何匹配業務和生態發展速度，對於這個問題的思考，一直是激勵我們團隊前進的動力，未來仍將如此。我們希望，有螞蟻的地方就有螞蟻金服，有螞蟻的地方就有我們的自研技術。

從上個世紀末開始，我們從商業崇拜、開源崇拜一路走來，到了今天，我們發現自研技術已經在許多企業紮根。雖然還存在許多不確定性，但是，既然時代已經發展到了今天，那麼總會有一兩顆種子，會破土而出，努力地向上生長並最終成為參天大樹。

我們相信，下一個十年，自研技術特別是核心自研技術將會迎來真正的黃金髮展期，這背後存在深刻的行業背景和成熟的企業實踐。

目前，OceanBase官網已正式上線，更多關於OceanBase產品性能、入門指引，以及測試版下載的信息，可點擊：https://oceanbase.alipay.com/ （請將網址複製至瀏覽器中打開即可查看）垂詢。

閱讀更多 螞蟻金服科技 的文章

關鍵字: 黃金 大數據 螞蟻金服