餘額寶技術架構及演進

餘額寶技術架構及演進

原創 2016-07-14 陳雨 高可用架構 高可用架構

高可用架構

微信號 ArchNotes

功能介紹 高可用架構公衆號。

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

陳雨，具備 8 年的軟件研發和技術管理工做經驗，專一於互聯網金融、雲計算、大數據等領域的發展動態和創新，目前在天弘基金負責基金註冊登記系統架構和研發工做。

餘額寶總結起來包括這樣幾個屬性，第一它是一個傳統的貨幣基金，但它把 T + 0 作到極致，另外他管理大量的用戶資產。同時他具有極簡的用戶體驗，符合互聯網精神。咱們在網頁、支付寶 APP 或者其餘途徑能快速方便的進行基金申贖，它的應用渠道也很是多和廣。

能夠說從餘額寶開始，真正的進入一個全民理財的時代，接下來給你們分享一下幾個數字。餘額寶用戶數能夠說達到了接近於 1/4 國人數量，日交易峯值能夠達到兩億筆，最大併發數能夠達到每秒五千筆。截止 2016 年上一季度公開披露信息，規模已經達到六千億以上。

從餘額寶的創新來講能夠從兩個方面去講它，一是業務上的創新，他對 T + 0 發揮到極致，是現金管理工具，是底層賬戶。還有就是嵌入式直銷，把貨幣基金嫁接到支付寶上去。當時來說應該是一個在行業內是具備很是大的一個開創意義的一件事情。

技術上創新是今天重點要說的事情：

1. 基金直銷和 TA 清算的整合。傳統的基金系統直銷和清算是分開。直銷系統天天要把數據以文件形式導入清算系統裏去。這件事情咱們作了很大的改進，這麼大致量數據來講，天天導入導出這個數據不可想象，在這裏作了一個直銷和 TA 融合，後面我會有一個詳細的介紹。

2. 交易的簡化，監管大的框架下，知足監管要求的基礎上，咱們對交易邏輯作了很大的一個簡化。

3. 餘額寶是核心業務在雲上運行的系統。這是餘額寶技術方面的創新。

架構演進歷史

一期 IOE 架構

下面介紹一下一期的架構，很明顯看到就是傳統的 IOE 架構。底層存儲是 EMC 存儲。中間層就是採用小型機，其中 KCXP 和 KCBP 是金證公司的消息中間件和業務中間件。往上前端是前置解析是用的 WebLogic，負載均衡用的硬件負載均衡。

這個架構對它的定位知足需求首先是支持千萬級用戶，傳統基金銷售模式是走代銷機構的方式，投資基金用戶也是以理財爲目的。因此天天可能處理的賬戶的開戶可能也就是幾萬到幾十萬的規模。因爲餘額寶對接是支付寶，支付寶有龐大的用戶羣，在用戶規模上要達到千萬級，這是當時對需求的定位。

第二點就是剛纔提到把直銷系統和 TA 清算系統作了融合，在數據庫層面是共享的，避免數據再作一次導出和導入，對清算也節省了不少時間。

另一點是傳統基金的互聯網化。傳統基金只須要作到系統的 5 × 8 可用性，對接支付寶之後，要作 7 × 24 小時可用性。

2013 年 6 月，一期系統如期上線，業務規模遠遠超出咱們想象。運營和運維人員反饋清算時間太長，基本上要從凌晨開始到早上八點，天天都是這樣，咱們感覺到巨大的壓力。另外當年要參加支付寶這邊的雙 11 活動，以當時的系統處理能力來說，確定是作不到的。

二期雲端架構

基於這些緣由，須要對一期的系統作優化，怎麼優化？二期架構用一個詞歸納就是上雲，充分利用雲計算的計算能力，包括雲計算對存儲的處理能力。

整個架構進行了水平拆分。前面一期架構實際上就是一路的處理，到了二期把它分紅多路。

從數據庫層面分紅多個 RDS（阿里雲一款基於MySQL的關係型數據庫產品）。另一個就是去Oracle，不少利用數據庫存儲過程計算的部分，移到計算單元完成。

第三點是把直銷和 TA 再次在計算資源層面分離。餘額寶系統的數據處理，包括實時處理和批量處理。過去在一期架構的時候發現清算時，數據庫負荷很是高，嚴重影響實時請求體驗。因此在上雲以後，在計算資源這塊再次對它進行了分離，主要目的是提高客戶體驗。上雲以後，固然充分利用了雲計算的優點，其中很主要一個優點就是可擴展性。

水平拆分

接下來詳細介紹一下是怎麼來作水平拆分。

第一點如何來分，以什麼維度來分？最後肯定以用戶維度，這樣最終處理時間與用戶交易的均衡程度有關。肯定以用戶維度進行拆分以後，肯定哪些點來進行拆分，一樣仍是從用戶角度出發，賬戶、交易、份額、份額明細、份額變更等等。對於歷史表直接合到倉庫裏去了，由於每日清算完以後，當日數據直接把它歸檔掉。

拆分以後，涉及到這樣一個問題，TA 系統由於還要與周邊的系統進行交互，交互的接口一樣仍是文件，數據導入須要先把文件拆成多份，再把每一份導入 TA，數據導出時系統要導出多份文件，再合併爲一份。

總控

拆分最大的難點是在總控節點的處理，剛纔說了 worker 節點可以保持鬆耦合，但仍須要經過總控節點進行統一協調，保持事務一致性。

最後數據覈對階段，也是要由總控彙總節點上的數據，按照清算規則對數據進行覈對。還有很重要的收益分配部分，採用兩個階段來作，第一階段由總控節點分配到每一個節點上去。，而後在節點範圍分配到用戶粒度。

下圖是上雲先後指標上的一個對比，上雲前基本上核心清算工做要作八個小時，上雲以後在千秒之內能夠完成。因此二期上雲之後，IT 終於能夠喘口氣。目前來說應對春節、雙十一、國慶長假等場景，系統都能穩定應對這些。

（點擊圖片查看大圖）

這是上雲先後投入產出對比狀況，傳統的 IOE 架構特色成本很高，硬件成本給企業帶來的壓力很是大，雲計算的好處就是在成本上是能夠作到很細的，而且方便按需增長，這是一個很是大的成本上的優點。過去投入四百萬只能支持一千萬的賬戶的量級，如今在投入上可能只是增加一倍，支持用戶數已經遠遠不止一倍了。

數據架構

二期架構能夠知足核心交易以後，還要考慮餘額寶目前這麼大的數據量，怎麼把這個數據用好。

近一年來不少工做都是考慮數據後處理這塊。其中數據來源於業務數據、日誌數據和其餘數據。咱們推動數據倉庫的建設和數據的產出。工具方面咱們有不少自主開發的，同時也採用了阿里採雲間，以及其餘外採工具，具體支撐業務包括生產數據分析、資金預測、數據監控、運營支持，合規風控支持等等。開篇也提到了金融系統數據安全是重中之重，因此這塊咱們也會有相關的數據安全方面的管理。

二期架構的問題

二期架構解決不少問題，但並非盡善盡美，總結一下仍是有幾個能夠提升的點：

• 耦合。首先計算和數據的耦合仍是存在的。這其實是對系統的擴展是不利的。另外，單個計算節點上，在業務上仍是存在耦合，咱們不少業務上的東西仍是存在拆分的可能。

• 數據流轉，咱們如今數據庫層面也是分佈式，因此數據的抽取、同步和流轉會遇到不少現實的問題。

• 運維。在運維方面除了遇到的傳統分佈式系統的運維遇到的一些難題以外，咱們還在業務層面的運維也會遇到一些現實問題。

將來演進思考

對系統將來演進思考，主要分這麼幾個方面。

1. 從大的方面來說是全局通盤考慮。咱們要把核心和輔助系統通盤考慮，下降數據的冗餘，下降數據維護成本。

2. 數據方面要用多不一樣的存儲來解決不一樣場景的需求，還有剛纔提到計算和存儲的完全解耦，作到計算和存儲的獨立可擴展。

3. 計算方面儘可能作到業務上的拆分和輕量化，化繁爲簡，拆分以後把應用服務化。

數據驅動

咱們系統的演進，數據量由單一小量向大量多類轉變，同時應用種類從以交易爲主到交易、分析和挖掘多種類並存。另外實時性要求也有變化，新的業務模式有時候要求實時或者準實時給用戶呈現結果。

對業務來講對不一樣數據應用採用不一樣的存儲。

• 好比對於在線交易，能夠採用通過阿里支付寶驗證過的 OB，專門用於解決金融級的分佈式關係數據庫的解決方案；

• 對於批量結算，能夠繼續沿用多年來在餘額寶已經用的很嫺熟的 RDS 集羣。

• 對於 2T 到 PB 級的小數倉能夠用 PetaData，解決以年度爲單位的數據存儲。

• 對於大規模的批量計算，數據倉庫這塊，咱們直接就用 ODPS。

• 對大表存儲可採用 OTS。

• 對於分析型、挖掘類需求可採用列存數據庫。

服務化

關於拆分和服務化治理，後面考慮作的事情是充分利用阿里雲的 PaaS 平臺技術，把咱們大應用拆分爲簡單的可橫向擴展的小應用。

在服務的調用上，每一個服務同時是服務提供方也是服務調用方，由 PaaS 平臺的中間件統一管理服務。對咱們來講是更多考慮如何基於中間件把業務來作好。服務化改造以後確定會涉及到服務之間的調用。同步調用，能夠直接走服務化的接口。

異步調用

異步調用主要靠消息中間件。金融系統對消息中間件的可靠性要求很是高，這塊咱們仍是沿用傳統思路，並不想採用開源解決方案去填那些坑，更多考慮採用成熟金融級消息中間件來作這件事情。

下面是一個總圖，中間 EDAS 是統一企業級服務化解決方案，而後經過 DTS 解決數據實時同步的問題，採用 CDP 解決離線數據同步的問題。在數據應用上能夠知足不少的需求，好比採集系統或者報表展現或者是用戶短信的推送等等，這就是咱們對整個將來的架構演進的思考。

Q&A

提問：都切到雲上，數據安全上怎麼考慮？

陳雨：以前講到金融要求是私有云，咱們是在阿里金融雲上，並非在公有云上，可理解爲物理上是隔離的。

提問：接口交互的技術是文件，文件的完整性和一致性如何保證的？大家本身要處理它嗎？爲何要用文件的方式？

陳雨：咱們對接是支付寶，文件的正確性和準確性由支付寶保證。咱們須要對大文件按節點數拆分紅小文件，而後並行處理。接口必須用文件方式，金融行業不少系統對接最後要走文件接口，文件是用來對賬的準確性保障，實時不是那麼可靠。

提問：說到計算和數據耦合，輸入輸出解開，具體大致上是怎麼實施它？

陳雨： RDS 來是單機數據庫產品，經過分佈式中間件 DRDS 或其餘解決方案，以實現計算節點像使用單機數據庫同樣使用數據庫集羣。

提問：我們有基於用戶緯度拆分，主要是什麼緣由致使咱們要這麼拆，基於用戶緯度拆分，有沒有比較坑的地方或者咱們怎麼避免它？

陳雨：基於用戶的拆分，一方面簽約協議號是跟支付寶的接口，還有一個考慮是以用戶爲維度的查詢需求相對多。固然其餘非用戶緯度查詢就費點事了。

提問：我是互聯網金融從業者，剛纔您提到咱們餘額寶系統，有清算系統是吧。不知道清算是有內部清算和外部清算，咱們這邊清算是怎麼作的？好比說內部清算是指交易明細和你的賬戶餘額之間的比對。你外部清算多是你本地的數據和銀行數據之間的比對。

陳雨：我所說的清算是你所說的第一種。天天作一次內部比對，計算用戶的份額和收益。

提問：以前也用過其餘的消息中間件，你剛纔提到成熟的消息中間件不是開源，咱們其餘從業者不能用到是吧？

陳雨：這涉及到一個生態圈的問題，若是進入阿里雲的生態圈，可充分享用雲計算資源。若是確實是在生態圈以外，可選擇它的對應開源版本。開源版本在版本更替上或者服務方面，跟阿里雲上存在必定的差異。

相關閱讀

點擊連接閱讀相關文章

• 互聯網金融系統技術沙龍:微博衆籌架構設計

• 互聯網金融系統技術沙龍:小米風控實踐

想更多瞭解本期互聯網金融系統沙龍內容，請關注「ArchNotes」微信公衆號以閱讀後續文章。轉載請註明來自高可用架構及包含如下二維碼。

高可用架構

改變互聯網的構建方式

長按二維碼 關注「高可用架構」公衆號

閱讀

投訴

精選留言

該文章做者已設置需關注才能夠留言

寫留言

該文章做者已設置需關注才能夠留言

寫留言

加載中

以上留言由公衆號篩選後顯示

瞭解留言功能詳情

微信掃一掃
關注該公衆號

null