余額寶總結起來包括這樣幾個屬性，第一它是一個傳統的貨幣基金，但它把 T + 0 做到極致，另外他管理大量的用戶資產。同時他具備極簡的用戶體驗，符合互聯網精神。我們在網頁、支付寶 APP 或者其他途徑能快速方便的進行基金申贖，它的應用渠道也非常多和廣。
可以說從余額寶開始，真正的進入一個全民理財的時代，接下來給大家分享一下幾個數字。余額寶用戶數可以說達到了接近于 1/4 國人數量，日交易峰值可以達到兩億筆，最大并發數可以達到每秒五千筆。歡迎加入大數據學習交流分享群： 658558542? ?一起吹水交流學習
從余額寶的創新來說可以從兩個方面去講它，一是業務上的創新，他對 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 解決離線數據同步的問題。在數據應用上可以滿足很多的需求，比如采集系統或者報表展示或者是用戶短信的推送等等，這就是我們對整個未來的架構演進的思考。
結語
感謝您的觀看，如有不足之處，歡迎批評指正。
如果有對大數據感興趣的小伙伴或者是從事大數據的老司機可以加群：
658558542? ??
里面整理了一大份學習資料，全都是些干貨，包括大數據技術入門，海量數據高級分析語言，海量數據存儲分布式存儲，以及海量數據分析分布式計算等部分，送給每一位大數據小伙伴，這里不止是小白聚集地，還有大牛在線解答！歡迎初學和進階中的小伙伴一起進群學習交流，共同進步！
最后祝福所有遇到瓶頸的大數據程序員們突破自己，祝福大家在往后的工作與面試中一切順利。
