一文讀懂螞蟻金服自研技術的發展和實踐

  本文根據馮柯老師在2018年5月10日【第九屆中國資料庫技術大會】現場演講內容整理而成。

　　講師介紹：

▲馮柯

　　馮柯，螞蟻金服資深總監、OceanBase首席架構師。2014年加入螞蟻金服，入職前在資料庫廠商神舟通用任CTO，浙江大學計算機應用專業博士，十五年資料庫研發和產業化經驗。目前在基礎資料部(OceanBase團隊)任架構師，參與OB 1.0的設計和研發工作，主要研究領域分散式關聯式資料庫、資料儲存、效能診斷和優化。

　　正文：

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

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

　　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%的交易、支付，甚至以及包括上層的賬務、會員在內的更多的核心業務。

　　在支援賬務層面這件事情上，團隊再一次面臨關鍵考驗。熟悉金融系統的嘉賓應該知道，賬務是一個狀態性型業務，同比流水型的交易、支付相比，的資料模型處理邏輯要複雜得多，容災邏輯也要複雜得多。

　　實際上，業務團隊已沒有太多工作可做經不能託底了，剩下的事情必須靠資料庫完成自己去解決。此時，業務團隊選擇相信OceanBase我們，然而我們團隊的壓力空前巨大，如果雙11當天資料庫中的資料出現問題，這會對螞蟻金服產生很嚴重的後果。幸運的是，我們最後扛過來了。

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

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

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

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

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

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

　　如果仔細分析觀察就會發現，該方案存在一些問題。首先，從擴充套件能力看，由於核心業務只能被部署在活躍的資料中心，所以該方案無法解決核心業務跨城市擴充套件問題。換句話說，從業務角度來看，兩地三中心的本質是同城雙活;其次，從成本來看，由於災備中心只在極端容災場景下被啟用，所以整個系統的資源利用率較低，相對應的成本就會升高;最後，從容災影響能力來看，整個系統正常運作時，災備中心始終處於冷備模式，所以系統容災時可用性較低，容災切換風險較高。因此，在兩地三中心的架構下，如果真的發生城市級故障，我們通常也不敢把業務切到災備中心，只能等待故障的資料中心恢復，在這個過程中，系統是無法恢復提供服務的。

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

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

　　單元具備四個重要特性，一是自包含性，比如賬戶充值交易所涉及的所有計算和資料都會被封閉在一個單元;二是鬆耦合性，單元之間只允許進行服務呼叫，不允許直接訪問資料庫或其他儲存，對於必須跨單元的操作，比如位於兩個不同單元之間的使用者轉賬交易，服務呼叫需儘可能少，同時在不影響客戶體驗的情況下，儘可能非同步化。這樣，即便兩個單元相距較遠，整個系統的響應也不會受單元間距離訪問延遲的影響;三是故障獨立性，一個單元的故障不會影響其他單元;四是容災性，單元之間相互備份，每個單元都保證在發生同城或異地故障時有可切接管的單元，單元之間的備份方式是使用自研資料庫提供的多地多中心的一致性方案。

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

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

　　OceanBase的核心是基於Paxos協議的多數派分散式選舉協議，Paxos協議的價值已被業內廣泛認可。該協議保證只要多數成員依然存活，任何少數成員的故障不會影響系統的整體可用性和資料一致性。所以，如果把一個資料叢集部署到三個或三個以上城市時，我們就可以保證任何一個城市的故障，系統都可以實現無損容災，也就是RPO=0都不會對系統造成損壞。此外同時，系統可在30秒以內把資料故障切換到另一城市，故障切換過程在資料庫層面自動完成，對上層業務沒有影響。另一方面，當我們把一個資料庫叢集部署到三個城市時，為了避免任何單機故障導致的業務跨城市訪問問題，可以我們把資料庫叢集中的副本數量從3個增加到5個，這就是我們今天所說的三地五中心，或者嚴格一點，三地五副本五多中心。

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

　　螞蟻金服花了數年時間來演進基於單元化和三地五中心的異地多活和容災架構。今天，螞蟻金服已在多個城市部署了多個資料中心，我們所有的核心交易流量量部署在所有資料中心並可隨時切換調備和調配，通過異地多活，我們實現了流量在全國範圍內的均衡任意擴充套件，極大地提高了資源利用率。最重要的是，我們提升了系統面對城市級故障的能力。螞蟻金服在如此大規模的金融交易系統中實現了這樣的容災能力，這在世界上屬於首創。

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

　　從上個世紀末開始，我們從商業資料庫崇拜、開源資料庫崇拜到今天一路走來，到了今天，我們發現自研技術已經在許多企業紮根。雖然還存在許多不確定性，但是，既然時代發生了轉變已經發展到了今天，那麼總會有一兩顆種子，會破土而出，努力地向上生長並最終成為參天大樹。我們相信，下一個十年，自研技術特別是核心自研技術將會迎來真正的黃金髮展期，這背後將存在深刻的行業背景和成熟的技術企業實踐。

　　在這裡，我們想借DTCC大會的舞臺這個平臺，呼籲所有技術人，呼籲所有志同道合者，包括媒體界的各位朋友，與我們一起去親身經歷這下一個十年時代，共同為自研技術喝彩，為科技自信代言!

　　目前，OceanBase官網已正式上線，更多關於OceanBase產品效能、入門指引，以及測試版下載的資訊，可點選https://oceanbase.alipay.com/ 垂詢。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2154532/，如需轉載，請註明出處，否則將追究法律責任。