天天看點

餘額寶技術架構及演進

導讀:餘額寶開啟了劃時代的意義,開啟了全民理财時代。上個月微網誌商業産品部聯合天弘基金等金融技術團隊策劃了首屆網際網路金融系統沙龍,圍繞在網際網路金融過程中碰到技術架構問題與業界展開分享及交流。本文是陳雨在沙龍上的演講,授權高可用架構首發。

餘額寶總結起來包括這樣幾個屬性,第一它是一個傳統的貨币基金,但它把 t + 0 做到極緻,另外他管理大量的使用者資産。同時他具備極簡的使用者體驗,符合網際網路精神。我們在網頁、支付寶 app 或者其他途徑能快速友善的進行基金申贖,它的應用管道也非常多和廣。 可以說從餘額寶開始,真正的進入一個全民理财的時代,接下來給大家分享一下幾個數字。餘額寶使用者數可以說達到了接近于 1/4 國人數量,日交易峰值可以達到兩億筆,最大并發數可以達到每秒五千筆。截止 2016 年上一季度公開披露資訊,規模已經達到六千億以上。
餘額寶技術架構及演進
從餘額寶的創新來說可以從兩個方面去講它,一是業務上的創新,他對 t + 0 發揮到極緻,是現金管理工具,是底層帳戶。還有就是嵌入式直銷,把貨币基金嫁接到支付寶上去。當時來講應該是一個在行業内是具有非常大的一個開創意義的一件事情。 技術上創新是今天重點要說的事情: 基金直銷和 ta 清算的整合。傳統的基金系統直銷和清算是分開。直銷系統每天要把資料以檔案形式導入清算系統裡去。這件事情我們做了很大的改進,這麼大體量資料來說,每天導入導出這個資料不可想象,在這裡做了一個直銷和 ta 融合,後面我會有一個詳細的介紹。 交易的簡化,監管大的架構下,滿足監管要求的基礎上,我們對交易邏輯做了很大的一個簡化。 餘額寶是核心業務在雲上運作的系統。這是餘額寶技術方面的創新。 架構演進曆史 一期 ioe 架構 下面介紹一下一期的架構,很明顯看到就是傳統的 ioe 架構。底層存儲是 emc 存儲。中間層就是采用小型機,其中 kcxp 和 kcbp 是金證公司的消息中間件和業務中間件。往上前端是前置解析是用的 weblogic,負載均衡用的硬體負載均衡。
餘額寶技術架構及演進
這個架構對它的定位滿足需求首先是支援千萬級使用者,傳統基金銷售模式是走代銷機構的方式,投資基金使用者也是以理财為目的。是以每天可能處理的帳戶的開戶可能也就是幾萬到幾十萬的規模。由于餘額寶對接是支付寶,支付寶有龐大的使用者群,在使用者規模上要達到千萬級,這是當時對需求的定位。 第二點就是剛才提到把直銷系統和 ta 清算系統做了融合,在資料庫層面是共享的,避免資料再做一次導出和導入,對清算也節省了很多時間。 另外一點是傳統基金的網際網路化。傳統基金隻需要做到系統的 5 × 8 可用性,對接支付寶以後,要做 7 × 24 小時可用性。 2013 年 6 月,一期系統如期上線,業務規模遠遠超出我們想象。營運和運維人員回報清算時間太長,基本上要從淩晨開始到早上八點,每天都是這樣,我們感受到巨大的壓力。另外當年要參加支付寶這邊的雙 11 活動,以當時的系統處理能力來講,肯定是做不到的。 二期雲端架構 基于這些原因,需要對一期的系統做優化,怎麼優化?二期架構用一個詞概括就是上雲,充分利用雲計算的計算能力,包括雲計算對存儲的處理能力。
餘額寶技術架構及演進
整個架構進行了水準拆分。前面一期架構實際上就是一路的處理,到了二期把它分成多路。 從資料庫層面分成多個 rds(阿裡雲一款基于mysql的關系型資料庫産品)。另外一個就是去oracle,很多利用資料庫存儲過程計算的部分,移到計算單元完成。 第三點是把直銷和 ta 再次在計算資源層面分離。餘額寶系統的資料處理,包括實時處理和批量處理。過去在一期架構的時候發現清算時,資料庫負荷非常高,嚴重影響實時請求體驗。是以在上雲之後,在計算資源這塊再次對它進行了分離,主要目的是提升客戶體驗。上雲之後,當然充分利用了雲計算的優勢,其中很主要一個優勢就是可擴充性。 水準拆分 接下來詳細介紹一下是怎麼來做水準拆分。 第一點如何來分,以什麼次元來分?最後确定以使用者次元,這樣最終處理時間與使用者交易的均衡程度有關。确定以使用者次元進行拆分之後,确定哪些點來進行拆分,同樣還是從使用者角度出發,帳戶、交易、份額、份額明細、份額變動等等。對于曆史表直接合到倉庫裡去了,因為每日清算完之後,當日資料直接把它歸檔掉。 拆分之後,涉及到這樣一個問題,ta 系統因為還要與周邊的系統進行互動,互動的接口同樣還是檔案,資料導入需要先把檔案拆成多份,再把每一份導入 ta,資料導出時系統要導出多份檔案,再合并為一份。 總控 拆分最大的難點是在總控節點的處理,剛才說了 worker 節點能夠保持松耦合,但仍需要通過總控節點進行統一協調,保持事務一緻性。 最後資料核對階段,也是要由總控彙總節點上的資料,按照清算規則對資料進行核對。還有很重要的收益配置設定部分,采用兩個階段來做,第一階段由總控節點配置設定到每個節點上去。,然後在節點範圍配置設定到使用者粒度。 下圖是上雲前後名額上的一個對比,上雲前基本上核心清算工作要做八個小時,上雲之後在千秒以内可以完成。是以二期上雲以後,it 終于可以喘口氣。目前來講應對春節、雙11、國慶長假等場景,系統都能穩定應對這些。
餘額寶技術架構及演進
(點選圖檔檢視大圖) 這是上雲前後投入産出對比情況,傳統的 ioe 架構特點成本很高,硬體成本給企業帶來的壓力非常大,雲計算的好處就是在成本上是可以做到很細的,并且友善按需增加,這是一個非常大的成本上的優勢。過去投入四百萬隻能支援一千萬的帳戶的量級,現在在投入上可能隻是增長一倍,支援使用者數已經遠遠不止一倍了。
餘額寶技術架構及演進
資料架構 二期架構可以滿足核心交易之後,還要考慮餘額寶目前這麼大的資料量,怎麼把這個資料用好。 近一年來很多工作都是考慮資料後處理這塊。其中資料來源于業務資料、日志資料和其他資料。我們推進資料倉庫的建設和資料的産出。工具方面我們有很多自主開發的,同時也采用了阿裡采雲間,以及其他外采工具,具體支撐業務包括生産資料分析、資金預測、資料監控、營運支援,合規風控支援等等。開篇也提到了金融系統資料安全是重中之重,是以這塊我們也會有相關的資料安全方面的管理。
餘額寶技術架構及演進
二期架構的問題 二期架構解決很多問題,但并不是盡善盡美,總結一下還是有幾個可以提高的點: 耦合。首先計算和資料的耦合還是存在的。這實際上是對系統的擴充是不利的。另外,單個計算節點上,在業務上還是存在耦合,我們很多業務上的東西還是存在拆分的可能。 資料流轉,我們現在資料庫層面也是分布式,是以資料的抽取、同步和流轉會遇到很多現實的問題。 運維。在運維方面除了遇到的傳統分布式系統的運維遇到的一些難題之外,我們還在業務層面的運維也會遇到一些現實問題。 未來演進思考 對系統未來演進思考,主要分這麼幾個方面。 從大的方面來講是全局通盤考慮。我們要把核心和輔助系統通盤考慮,降低資料的備援,降低資料維護成本。 資料方面要用多不同的存儲來解決不同場景的需求,還有剛才提到計算和存儲的徹底解耦,做到計算和存儲的獨立可擴充。 計算方面盡量做到業務上的拆分和輕量化,化繁為簡,拆分之後把應用服務化。 資料驅動 我們系統的演進,資料量由單一小量向大量多類轉變,同時應用種類從以交易為主到交易、分析和挖掘多種類并存。另外實時性要求也有變化,新的業務模式有時候要求實時或者準實時給使用者呈現結果。
餘額寶技術架構及演進
對業務來說對不同資料應用采用不同的存儲。 比如對于線上交易,可以采用經過阿裡支付寶驗證過的 ob,專門用于解決金融級的分布式關系資料庫的解決方案; 對于批量結算,可以繼續沿用多年來在餘額寶已經用的很娴熟的 rds 叢集。 對于 2t 到 pb 級的小數倉可以用 petadata,解決以年度為機關的資料存儲。 對于大規模的批量計算,資料倉庫這塊,我們直接就用 odps。 對大表存儲可采用 ots。 對于分析型、挖掘類需求可采用列存資料庫。 服務化 關于拆分和服務化治理,後面考慮做的事情是充分利用阿裡雲的 paas 平台技術,把我們大應用拆分為簡單的可橫向擴充的小應用。
餘額寶技術架構及演進
在服務的調用上,每個服務同時是服務提供方也是服務調用方,由 paas 平台的中間件統一管理服務。對我們來說是更多考慮如何基于中間件把業務來做好。服務化改造之後肯定會涉及到服務之間的調用。同步調用,可以直接走服務化的接口。
餘額寶技術架構及演進
異步調用 異步調用主要靠消息中間件。金融系統對消息中間件的可靠性要求非常高,這塊我們還是沿用傳統思路,并不想采用開源解決方案去填那些坑,更多考慮采用成熟金融級消息中間件來做這件事情。
餘額寶技術架構及演進
下面是一個總圖,中間 edas 是統一企業級服務化解決方案,然後通過 dts 解決資料實時同步的問題,采用 cdp 解決離線資料同步的問題。在資料應用上可以滿足很多的需求,比如采集系統或者報表展示或者是使用者短信的推送等等,這就是我們對整個未來的架構演進的思考。
餘額寶技術架構及演進
q&a 提問:都切到雲上,資料安全上怎麼考慮? 陳雨:之前講到金融要求是私有雲,我們是在阿裡金融雲上,并不是在公有雲上,可了解為實體上是隔離的。 提問:接口互動的技術是檔案,檔案的完整性和一緻性如何保證的?你們自己要處理它嗎?為什麼要用檔案的方式? 陳雨:我們對接是支付寶,檔案的正确性和準确性由支付寶保證。我們需要對大檔案按節點數拆分成小檔案,然後并行處理。接口必須用檔案方式,金融行業很多系統對接最後要走檔案接口,檔案是用來對帳的準确性保障,實時不是那麼可靠。 提問:說到計算和資料耦合,輸入輸出解開,具體大體上是怎麼實施它? 陳雨: rds 來是單機資料庫産品,通過分布式中間件 drds 或其他解決方案,以實作計算節點像使用單機資料庫一樣使用資料庫叢集。 提問:咱們有基于使用者緯度拆分,主要是什麼原因導緻我們要這麼拆,基于使用者緯度拆分,有沒有比較坑的地方或者我們怎麼避免它? 陳雨:基于使用者的拆分,一方面簽約協定号是跟支付寶的接口,還有一個考慮是以使用者為次元的查詢需求相對多。當然其他非使用者緯度查詢就費點事了。 提問:我是網際網路金融從業者,剛才您提到我們餘額寶系統,有清算系統是吧。不知道清算是有内部清算和外部清算,我們這邊清算是怎麼做的?比如說内部清算是指交易明細和你的帳戶餘額之間的比對。你外部清算可能是你本地的資料和銀行資料之間的比對。 陳雨:我所說的清算是你所說的第一種。每天做一次内部比對,計算使用者的份額和收益。 提問:之前也用過其他的消息中間件,你剛才提到成熟的消息中間件不是開源,我們其他從業者不能用到是吧? 陳雨:這涉及到一個生态圈的問題,如果進入阿裡雲的生态圈,可充分享用雲計算資源。如果确實是在生态圈之外,可選擇它的對應開源版本。開源版本在版本更替上或者服務方面,跟阿裡雲上存在一定的差别。 作者:陳雨
餘額寶技術架構及演進
陳雨,具有 8 年的軟體研發和技術管理工作經驗,專注于網際網路金融、雲計算、大資料等領域的發展動态和創新,目前在天弘基金負責基金注冊登記系統架構和研發工作。