余額寶技術架構及演進
阿新 • • 發佈：2017-07-19
discuss ever hidden 網頁 ace btn led 事務 系統架構
導讀：余額寶開啟了劃時代的意義，開啟了全民理財時代。上個月微博商業產品部聯合天弘基金等金融技術團隊策劃了首屆互聯網金融系統沙龍，圍繞在互聯網金融過程中碰到技術架構問題與業界展開分享及交流。本文是陳雨在沙龍上的演講，授權高可用架構首發。
陳雨，具有 8 年的軟件研發和技術管理工作經驗，專註於互聯網金融、雲計算、大數據等領域的發展動態和創新，目前在天弘基金負責基金註冊登記系統架構和研發工作。
余額寶總結起來包括這樣幾個屬性，第一它是一個傳統的貨幣基金，但它把 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 或其他解決方案，以實現計算節點像使用單機數據庫一樣使用數據庫集群。
提問：咱們有基於用戶緯度拆分，主要是什麽原因導致我們要這麽拆，基於用戶緯度拆分，有沒有比較坑的地方或者我們怎麽避免它？
陳雨：基於用戶的拆分，一方面簽約協議號是跟支付寶的接口，還有一個考慮是以用戶為維度的查詢需求相對多。當然其他非用戶緯度查詢就費點事了。
提問：我是互聯網金融從業者，剛才您提到我們余額寶系統，有清算系統是吧。不知道清算是有內部清算和外部清算，我們這邊清算是怎麽做的？比如說內部清算是指交易明細和你的帳戶余額之間的比對。你外部清算可能是你本地的數據和銀行數據之間的比對。
陳雨：我所說的清算是你所說的第一種。每天做一次內部比對，計算用戶的份額和收益。
提問：之前也用過其他的消息中間件，你剛才提到成熟的消息中間件不是開源，我們其他從業者不能用到是吧？
陳雨：這涉及到一個生態圈的問題，如果進入阿裏雲的生態圈，可充分享用雲計算資源。如果確實是在生態圈之外，可選擇它的對應開源版本。開源版本在版本更替上或者服務方面，跟阿裏雲上存在一定的差別。
相關閱讀
點擊鏈接閱讀相關文章
互聯網金融系統技術沙龍:微博眾籌架構設計
互聯網金融系統技術沙龍:小米風控實踐
想更多了解本期互聯網金融系統沙龍內容，請關註「ArchNotes」微信公眾號以閱讀後續文章。轉載請註明來自高可用架構及包含以下二維碼。
高可用架構
改變互聯網的構建方式
長按二維碼 關註「高可用架構」公眾號
加載中
以上留言由公眾號篩選後顯示
微信掃一掃
關註該公眾號
余額寶技術架構及演進
