以下文章來源于金融級分布式架構(gòu) ，作者程立
金融級分布式架構(gòu)
致力于打造一流的分布式技術(shù)在金融場景應(yīng)用實踐的技術(shù)交流平臺，專注于交流金融科技行業(yè)內(nèi)最前沿、可供參考的技術(shù)方案與實施路線。
本文公眾號首發(fā)于金融級分布式架構(gòu)，經(jīng)授權(quán)轉(zhuǎn)載
移動互聯(lián)網(wǎng)、大數(shù)據(jù)與云計算作為新的基礎(chǔ)設(shè)施，催生了新的互聯(lián)網(wǎng)經(jīng)濟(jì)，也正在推動各行各業(yè)的升級。在過去十多年中，金融服務(wù)飛速發(fā)展，移動支付支撐了零售業(yè)線上線下的變革，基于大數(shù)據(jù)的信貸服務(wù)支持了無數(shù)小微企業(yè)的創(chuàng)業(yè)創(chuàng)新，老百姓可以隨時隨地享受曾經(jīng)高門檻的理財、保險等金融服務(wù)。以普惠服務(wù)為目標(biāo)、數(shù)據(jù)與技術(shù)驅(qū)動、新型信用體系為基礎(chǔ)的新金融已經(jīng)成為新經(jīng)濟(jì)的基石。
伴隨著螞蟻金服在新金融領(lǐng)域的探索，螞蟻金服技術(shù)團(tuán)隊也在金融技術(shù)與架構(gòu)領(lǐng)域不斷開拓。從 2005 年每秒處理 1 筆交易到 2015 年雙十一每秒處理 8.59 萬筆交易，從單一的支付到覆蓋微貸、理財、保險、信用、銀行等，通過十多年的探索與實踐，我們形成了一套包含金融級分布式交易、分布式大數(shù)據(jù)分析與決策等在內(nèi)的完整架構(gòu)與技術(shù)體系。
在本文中，我們將與大家交流金融級分布式交易相關(guān)的實踐與體會。
金融級系統(tǒng)的關(guān)鍵目標(biāo)
如果將建造系統(tǒng)比作蓋樓的話，建一個常規(guī)的系統(tǒng)要先立穩(wěn)四根柱子：高可用、安全、性能、成本。但要建一個移動互聯(lián)網(wǎng)時代的金融級大廈，除了上述四根柱子需要更加牢固，還需要加上兩根柱子：資金安全與數(shù)據(jù)質(zhì)量。這六根柱子，是我們在架構(gòu)螞蟻金服的每一個系統(tǒng)時的首要目標(biāo)。
具體來說，我們對一個金融級系統(tǒng)有以下關(guān)鍵目標(biāo)：
高可用：具備 99.99% 以上的高可用性。系統(tǒng)能夠容忍各種軟硬件設(shè)施的故障，可以在服務(wù)不中斷的情況下進(jìn)行升級，在嚴(yán)苛的應(yīng)用場景下保證承諾的服務(wù)質(zhì)量，容忍各種人為失誤。對于關(guān)鍵系統(tǒng)，還需要具備異地容災(zāi)能力。
安全：具備多層次檢測、感知與防御各類安全攻擊的能力。系統(tǒng)有能力實時、精細(xì)地分析系統(tǒng)行為與數(shù)據(jù)流發(fā)現(xiàn)異常，必要時可以快速調(diào)集資源阻斷大規(guī)模、有組織的攻擊。
性能：對于實時交易業(yè)務(wù)，要求極快的響應(yīng)時間與極高并發(fā)能力。對于批量業(yè)務(wù)，要求極大的吞吐量。尤其重要的是，系統(tǒng)必須具備很強的可伸縮性與彈性，在需要時可以快速調(diào)集資源應(yīng)對突發(fā)的業(yè)務(wù)量。
成本：在滿足高可用、安全與性能的前提下，成本是一個重要約束。我們將單筆交易的平均處理成本（月交易總筆數(shù)/月成本）、以及峰值交易的處理成本（每提升 1000 交易 TPS 需要追加的成本）作為兩個關(guān)鍵指標(biāo)去持續(xù)優(yōu)化。除了必須在基礎(chǔ)軟硬件與系統(tǒng)關(guān)鍵鏈路上做極致的優(yōu)化外，靈活的資源調(diào)度與按需伸縮能力是優(yōu)化成本的關(guān)鍵。
資金安全：這是金融級系統(tǒng)與常規(guī)系統(tǒng)的一個關(guān)鍵差異。要做到資金處理絕對不出差錯，需要交易與數(shù)據(jù)具備強一致性，需要在任何故障場景數(shù)據(jù)不丟不錯，需要具備準(zhǔn)實時的交易資金核對能力，需要在異常場景下有精細(xì)化熔斷與快速恢復(fù)能力。
數(shù)據(jù)質(zhì)量：數(shù)據(jù)質(zhì)量是金融服務(wù)質(zhì)量的基礎(chǔ)。數(shù)據(jù)從采集、生成、流轉(zhuǎn)、存儲、計算、使用需要經(jīng)歷很多環(huán)節(jié)，要確保經(jīng)過這么多環(huán)節(jié)后，數(shù)據(jù)依然是準(zhǔn)確、完整和及時的，需要系統(tǒng)具備全鏈路的數(shù)據(jù)質(zhì)量管控與治理能力。
金融交易系統(tǒng)是否可以走分布式路線？如何基于分布式的思想與技術(shù)達(dá)到以上 6 個關(guān)鍵目標(biāo)？接下來，我們就以螞蟻金服的實踐為基礎(chǔ)，分享對這個問題的觀點。
分布式金融交易架構(gòu)與技術(shù)
1
強一致的微服務(wù)：微交易架構(gòu)
微服務(wù)是一種廣泛應(yīng)用的分布式架構(gòu)。通過將系統(tǒng)分解為單一職責(zé)、高內(nèi)聚、松耦合、獨立部署、自主運行的“微“服務(wù)，可以極大提升系統(tǒng)的靈活性與擴展能力。但由于每一個微服務(wù)是自包含的數(shù)據(jù)與計算單元，當(dāng)一個有嚴(yán)格一致性要求的交易，被分布在很多節(jié)點上執(zhí)行時，如何保證數(shù)據(jù)與服務(wù)處理達(dá)到金融級的強一致性，成為一個難題。盡管可以用支持分布式事務(wù)的數(shù)據(jù)庫或數(shù)據(jù)中間件來保證數(shù)據(jù)分布時的一致性，但解決不了當(dāng)服務(wù)分布時的一致性問題。由于分布式事務(wù)對資源加鎖的時間長、粒度大，也制約了系統(tǒng)的可伸縮性與高可用性。
為了解決這個難題，我們提出一種使微服務(wù)具備強一致性的微交易架構(gòu)。在這種架構(gòu)中，涉及到交易操作的微服務(wù)具備事務(wù)屬性。一個微交易提供三種操作TCC（Try-Confirm-Cancel），其中 Try 操作負(fù)責(zé)業(yè)務(wù)檢查與資源預(yù)留，Confirm 操作負(fù)責(zé)實際操作，Cancel 操作負(fù)責(zé)釋放預(yù)留的資源。一次完整的交易由一系列微交易的 Try 操作組成，如果所有的 Try 操作都成功，最終由微交易框架來統(tǒng)一Confirm，否則統(tǒng)一 Cancel，從而實現(xiàn)了類似經(jīng)典兩階段提交協(xié)議（2PC）的強一致性。但不同于 2PC，微交易架構(gòu)力求高效與可伸縮。TCC 三個操作都是基于本地事務(wù)的短事務(wù)，Try 操作只預(yù)留必須的業(yè)務(wù)資源，比如一筆交易涉及10元錢，僅預(yù)留賬戶中的 10 元錢，而不是鎖定整個賬戶，TCC 協(xié)議在提交時，也沒有單獨的 Prepare 階段，將提交協(xié)議的成本降到最低。
從 2008 年初上線至今，微交易架構(gòu)已經(jīng)應(yīng)用到螞蟻金服的各種金融業(yè)務(wù)場景，經(jīng)歷過歷次大促高峰考驗，證明這套架構(gòu)與技術(shù)的可行性。
2
請金融級分布式數(shù)據(jù)庫: OceanBase
目前，主要商業(yè)數(shù)據(jù)庫本質(zhì)上是單機系統(tǒng)，其容量、性能和可靠性均依賴于單個或少量高性能服務(wù)器與高可靠存儲的組合，成本高昂且擴展困難。盡管通過運用微交易架構(gòu)，可以將對數(shù)據(jù)操作的壓力分拆多個數(shù)據(jù)庫，解決了水平可擴展的問題，但數(shù)據(jù)庫本身的性能、成本與可靠性依然是一個難點。因此，阿里巴巴與螞蟻金服從 2010 年起，開始研發(fā)專門的金融級分布式數(shù)據(jù)庫 OceanBase。
OceanBase 在以下幾個方面，對傳統(tǒng)數(shù)據(jù)庫架構(gòu)進(jìn)行了突破：
高性能：數(shù)據(jù)庫的一個顯著特征是總數(shù)量比較大，但每天變化(增刪改)的數(shù)據(jù)只是總數(shù)據(jù)量的很小一部分。因此 OceanBase 將數(shù)據(jù)劃分為基線數(shù)據(jù)和修改增量。基線數(shù)據(jù)即數(shù)據(jù)庫在某個時間點的一個快照，存放在每臺 OceanBase 服務(wù)器的硬盤中，修改增量即快照點之后的增刪改數(shù)據(jù)，相對比較小，通常存放在每臺 OceanBase 服務(wù)器的內(nèi)存中。通過這種方式，使得增刪改操作基本都在內(nèi)存中進(jìn)行，從而獲得接近內(nèi)存數(shù)據(jù)庫的事務(wù)處理性能；
強一致：經(jīng)典的主庫+備庫方式的數(shù)據(jù)庫，很難兼具高可用與強一致能力。為了解決這個問題，OceanBase 使用多數(shù)據(jù)副本（>=3）投票協(xié)議，對于每個寫事務(wù)，OceanBase 只有在事務(wù)日志（redo log）到達(dá)超過半數(shù)服務(wù)器后，才應(yīng)答客戶。這樣當(dāng)少數(shù)服務(wù)器（例如 3 臺中的 1 臺，或者 5 臺中的 2 臺）異常時，剩下的服務(wù)器至少有一臺有事務(wù)日志，保證了數(shù)據(jù)庫不因為少數(shù)服務(wù)器故障而導(dǎo)致數(shù)據(jù)丟失；
高可用：關(guān)鍵業(yè)務(wù)的數(shù)據(jù)庫必須達(dá)到 99.999% 的可用性，服務(wù)器故障、機房或網(wǎng)絡(luò)故障都不能導(dǎo)致數(shù)據(jù)庫不可用。OceanBase 通常由分布于多個機房（3 個或以上）的機群組成，每個機群有完整數(shù)據(jù)，其中一個機群作為主庫對外提供讀寫服務(wù)，其余機群作為備庫，接收主庫的事務(wù)日志和回放日志。當(dāng)主庫故障時，剩下的機群會立刻自動發(fā)起投票選舉，選出新的主庫，新主庫從其他機群獲得可能存在的最新事務(wù)日志并回放，完成后對外提供服務(wù)。
目前 OceanBase 已經(jīng)穩(wěn)定支撐了支付寶的核心交易、支付與賬務(wù)，支撐了網(wǎng)商銀行的核心系統(tǒng)，經(jīng)歷了多次“雙十一”的考驗，形成了跨機房、跨區(qū)域部署的高可用架構(gòu)，并在日常運行、應(yīng)急演練和容災(zāi)切換中發(fā)揮了重要作用。
3
異地多活與容災(zāi): 單元化架構(gòu)
“兩地三中心”是一種在金融系統(tǒng)中廣泛應(yīng)用的跨數(shù)據(jù)中心擴展與跨地區(qū)容災(zāi)部署模式，但也存在一些問題：在擴展能力上，由于跨地區(qū)的備份中心不承載核心業(yè)務(wù)，不能解決核心業(yè)務(wù)跨地區(qū)擴展的問題；在成本上，災(zāi)備系統(tǒng)僅在容災(zāi)時使用，資源利用率低，成本較高；在容災(zāi)能力上，由于災(zāi)備系統(tǒng)冷備等待，容災(zāi)時可用性低，切換風(fēng)險較大。
因此，螞蟻金服沒有選擇“兩地三中心”部署模式，而是實現(xiàn)了異地多活與容災(zāi)模式。異地多活與容災(zāi)架構(gòu)的基礎(chǔ)是對系統(tǒng)進(jìn)行單元化。每一個單元可以認(rèn)為是一個縮小規(guī)模的、包含從接入網(wǎng)關(guān)、應(yīng)用服務(wù)到數(shù)據(jù)存儲的全功能系統(tǒng)。每個單元負(fù)責(zé)一定比例的數(shù)據(jù)與用戶訪問。單元有以下關(guān)鍵特性：
自包含性：比如用戶的一次賬戶充值交易，涉及到的所有計算與數(shù)據(jù)都在一個單元內(nèi)完成；
松耦合性：跨單元之間只能進(jìn)行服務(wù)調(diào)用，不能直接訪問數(shù)據(jù)庫或其它存儲。對于一些必須跨單元的交易處理，比如分屬于兩個不同單元的用戶之間的轉(zhuǎn)賬交易，跨單元的服務(wù)調(diào)用次數(shù)盡可能少，在業(yè)務(wù)與用戶體驗允許的情況下盡量異步處理。這樣，即使兩個單元之間相距上千公里，也可以容忍跨單元的訪問時延；
故障獨立性：一個單元內(nèi)的故障，不會傳播到其它單元；
容災(zāi)性：單元之間相互備份，確保每個單元在同城和異地都有可在故障期間進(jìn)行接管的單元。數(shù)據(jù)在單元間的備份方式，我們以 OceanBase 提供的多地多中心強一致方案為主。
通過單元化架構(gòu)，能夠?qū)⒁粋€大規(guī)模系統(tǒng)分拆成許多個相對獨立的小規(guī)模系統(tǒng)，每一個單元系統(tǒng)可以部署到任何地區(qū)的數(shù)據(jù)中心，從而實現(xiàn)了靈活的異地多數(shù)據(jù)中心部署模式。系統(tǒng)的主要伸縮模式變成單元的增減，但一個單元內(nèi)部的規(guī)模與復(fù)雜性不變，降低了系統(tǒng)的復(fù)雜性。單元之間的故障隔離，降低了軟硬件故障的影響面。“活”的單元和跨單元的快速切換能力，使同城異地的容災(zāi)處理更為簡單高效。
目前，螞蟻金服的核心系統(tǒng)已經(jīng)分布在上海、深圳、杭州等多個城市的多個數(shù)據(jù)中心，核心交易流量分布在各個數(shù)據(jù)中心，并且可以進(jìn)行調(diào)度與切換。通過異地多活，系統(tǒng)可以在全國范圍內(nèi)任意擴展，服務(wù)器資源得到了充分利用，提升了系統(tǒng)應(yīng)對地區(qū)級災(zāi)難的能力。
4
按需伸縮：彈性混合云架構(gòu)
每年，支付寶系統(tǒng)都要應(yīng)對雙十一、新春紅包等活動的極高交易量。盡管單元化架構(gòu)讓我們具備應(yīng)對峰值的能力，但要降低高峰期的資源投入，系統(tǒng)還需要具備按需伸縮的能力。
我們解決這個問題的方法是，活動前，在云計算平臺上快速申請資源，構(gòu)建新的單元，部署應(yīng)用與數(shù)據(jù)庫。然后將流量與數(shù)據(jù)“彈出”到新的單元，快速提升系統(tǒng)容量。當(dāng)活動結(jié)束后，再將流量與數(shù)據(jù)“彈回”，釋放云計算平臺上的資源。通過這種方式，可以大大降低資源采購與運行成本。
彈性操作，需要在流量、數(shù)據(jù)與資源之間協(xié)調(diào)一致地操作，尤其是有狀態(tài)的數(shù)據(jù)的彈性操作是最困難的，需要不中斷業(yè)務(wù)，也需要保證數(shù)據(jù)的一致性。這些操作如果依靠運維人員人工執(zhí)行會十分復(fù)雜低效，需要架構(gòu)、中間件與管控系統(tǒng)的支持。
彈性混合云架構(gòu)與技術(shù)在實踐中有以下一些關(guān)鍵點：
1. 通過統(tǒng)一資源調(diào)度，靈活地申請與分配計算、存儲與網(wǎng)絡(luò)資源，創(chuàng)建單元，快速部署數(shù)據(jù)庫、中間件與應(yīng)用；
2. 通過中間件，將應(yīng)用與基礎(chǔ)設(shè)施充分解耦，無論流量、數(shù)據(jù)與資源如何分布，應(yīng)用系統(tǒng)不需要改變；
3. 通過分布式架構(gòu)與數(shù)據(jù)規(guī)范，以及中間件支持，保證所有請求、服務(wù)、數(shù)據(jù)、消息等都有全局唯一的 ID 和一致的 ID 編碼規(guī)則。根據(jù) ID，從接入網(wǎng)關(guān)、服務(wù)中間件、消息中間件、數(shù)據(jù)中間件等都能夠正確地路由服務(wù)請求與數(shù)據(jù)訪問；
4. 通過統(tǒng)一管控平臺，將高層的彈性操作，翻譯成各個組件的部署與配置指令，并且統(tǒng)一調(diào)度執(zhí)行，使操作協(xié)調(diào)一致、精準(zhǔn)高效。
基于彈性混合云架構(gòu)，2015 年雙十一，支付寶有 10% 的支付流量運行在阿里云計算平臺上。2016 年雙十一，我們計劃將 50% 的高峰期支付流量運行在阿里云計算平臺上，帶來成本的極大優(yōu)化。
未來展望與期待
螞蟻金服的實踐證明了在金融級中間件、數(shù)據(jù)庫和云計算平臺的支持下，分布式架構(gòu)可以完全勝任復(fù)雜、高要求的金融級交易，并且給出了一種可供參考的技術(shù)架構(gòu)與實施路線。
未來，螞蟻金服依然會在金融級分布式架構(gòu)與技術(shù)方面深耕與拓荒。在這一領(lǐng)域，我們給自己提出兩個新的重大命題：
1. 如何處理每秒 1 億筆交易：萬物互聯(lián)時代，無處不在的交易終端和無數(shù)新的交易場景，會繼續(xù)帶來金融交易量的指數(shù)型增長。什么樣的架構(gòu)與技術(shù)，可以處理萬物互聯(lián)時代的天量交易，是需要未雨綢繆去攻堅與突破的；
2. 將金融級分布式架構(gòu)與技術(shù)變成“普惠”的云計算服務(wù)，為千千萬萬金融服務(wù)機構(gòu)服務(wù)。為了實現(xiàn)這個目標(biāo)，螞蟻金服和阿里云共同提出了“螞云計劃”，共建新一代的金融云平臺，未來服務(wù)全球 5 萬家金融機構(gòu)，共創(chuàng)全球化的普惠金融。
