餘額寶業務架構 收藏備用
阿新 • • 發佈：2018-12-31
“餘額寶”經過不到一年的發展，已獲得大量使用者的認可。本文將以故事的形式講述“餘額寶”背後那些鮮為人知的艱辛歷程——如何從傳統架構演變為雲端計算架構。
一年前的現在，在杭州支付寶大樓裡有個叫“春秋書院”的閉關室，裡面一群緊張而興奮的年輕人在忙碌著。專案室巨大的落地窗前，站著一個面色凝重的人，他就是天弘基金創新事業部技術負責人樊振華，一個在金融IT領域有著豐富經驗的老兵。他看著窗外川流不息的汽車，深深地吸了一口氣。
這是一個只有代號但沒有名字的保密專案，內部稱之為“2號專案”，2號專案的旺旺交流群的簽名上寫著“2013支付寶祕密武器”，足可見這個專案的重要性。
截止到今天，中國近億人因為這個專案受益，改變了自己的理財習慣。這個神祕的專案，就是餘額寶。那麼餘額寶的初期業務背景是什麼呢
餘額寶業務背景
在支付寶上賣基金的想法，在天弘基金電商負責人周曉明心中經過多次的思考和錘鍊，已逐漸清晰。他在向阿里小微金服集團國內事業群總裁樊治銘介紹餘額寶模式的雛形時，準備了5分鐘的內容，但只講1分鐘後，雙方即達成一致意見可以做、快速做，並期望餘額寶能在6月份上線運營。
雙方隨即行動起來，進行了簡單的分工，支付寶負責餘額寶在支付寶端的建設工作，而基金公司端負責與支付寶對接的直銷和清算系統的建設重任，就落到了樊振華頭上。
這是一個從來沒有人做過，也沒有人知道該如何做的創新業務，面對支付巨大的使用者群體，在僅不足3個月的時間內，該如何設計基金的清算和直銷系統，成為了樊振華面臨的頭號難題。2013年3月，樊振華一行與支付寶技術方進行整體架構溝通，這是傳統金融行業建設思路與網際網路技術路線的第一次衝突，雙方團隊在閉關室足足討論了4天，確定下來一期系統的建設目標和要解決的問題。
當時主要面臨以下難點。
1、要能夠支援“千萬級”使用者的系統容量。
a)傳統的基金銷售系統主要是和第三方銷售機構，如銀行理財專櫃、網上銀行進行合作銷售。直銷系統能夠處理每天幾萬到幾十萬個使用者的開戶就完全夠用了。但“餘額寶”面對的是數以億計的支付寶使用者，使用者的開戶數量和併發量與傳統業務有數量級的差異。
b)傳統基金的TA系統面對的使用者是以理財為目的的申購和贖回，因此每天清算的交易筆數要求也只有幾萬到幾十萬即可滿足。但“餘額寶”的業務模式裡，支付寶使用者的每一筆消費，都會轉化為一次基金的贖回，又加上海量的潛在使用者群，每日清算筆數將會是傳統模式的百倍甚至是千倍。
2、直銷系統和TA系統的融合。
a)傳統的直銷和TA是分別獨立的系統，但對於接入支付寶這種入口交易空前頻繁、資料量極為龐大的需求而言，傳統的分離式檔案互動方式不能滿足效率和優化利用資源的要求。因此，專案組提出了功能整合、功能簡化、當前庫和歷史庫分離的技術結構。讓直銷和清算系統使用同一套資料庫，來避免資料拷貝帶來的業務時延。
3、7×24小時的基金直銷系統。
a)由於渠道的原因，傳統基金直銷系統的大多數開戶出現在銀行的工作日。因此係統能夠做到5×8小時即可滿足大部分客戶的需求。但網際網路的屬性是7×24小時，因此係統也應該具備7×24小時不間斷的服務能力。
4、支付寶與天弘基金雙方的資料傳輸與系統互動。
a)餘額寶的直銷和清算系統會部署於天弘基金在天津的資料中心，而支付寶的“餘額寶”系統部署在杭州，雙方之間的通訊協議，遠距離資料傳輸面臨很大的挑戰。
這樣，根據早期的建設需求，餘額寶一期系統的架構和系統容量規劃工作展開了序幕。
一期系統建設
距離上線時間只有不足3個月，樊振華和系統開發商金證科技的技術人員進行了緊張的架構工作。經過數次討論，雙方有了初步的統一意見，並形成了建設目標。
1、基於KCBP/KCXP的叢集技術,
a)系統第一要素是要滿足創新業務的技術支撐要求，經雙方討論後，決定走較成熟的傳統金融技術路線。決定選用金證科技的KCBP/KCXP做叢集。金證股份核心業務平臺KCBP（Kingdom Core Business Platform）是專門為證券基金交易系統設計的外層交易中介軟體，同時具有普通交易中介軟體的特徵和功能，KCBP同時也支援跨平臺服務的開發與部署。為後續的可能出現的架構調整留下預留空間。
b)金證通訊交換平KCXP（Kingdom Communication eXchange Platform）中介軟體技術在券商行業有大量應用案例，具有很高的可靠性和可用性。並在資料傳輸效率、安全性和容錯性、負載均衡以及擴充套件性方面進行了優化，已經足夠成熟。
2、基於傳統的IOE的基礎架構。
a)在如此短時間內，有很多的功能優化，業務流程更改等開發工作，再配合相關的測試，必須控制改動的範圍。因此基礎架構決定採用傳統的HP/IBM/Oracle/EMC的方案，靠使用高階硬體裝置的方式，提高一期系統的整體容量和效能。
3、直銷和TA的系統整合。
a)為了減少直銷系統和TA的資料傳輸延遲，決定兩個系統使用同一套資料庫架構。
b)為了避免單點故障引起的業務中斷，應用層的直銷和TA平均分佈在每臺伺服器上。確保每個應用伺服器的角色具備可替代性。
4、跨省的MSTP專線鏈路
a)天弘基金清算和交易中心在天津資料機房，通過架設兩條4M的MSTP專線，連線到支付寶杭州資料機房。兩條專線之間互為備份，確保通訊鏈路安全。
一期系統的架構圖如下：
架構解讀：支付寶實時開戶，申購，贖回等實時請求，和每天的離線對賬檔案，都通過MSTP專線與一期系統進行通訊。其中實時請求通過RADWARE硬體負載均衡分發到兩臺前置機，前置機在做完報文解析以後，將請求傳送到XP的訊息佇列。然後由BP以主動負載均衡的機制，從XP中取出相應請求進行處理，處理結果保持到後端資料庫中。
幸福的煩惱
然而，在一期系統上線以後，面對業務量暴增的情況，系統遇到了瓶頸同時也出現了新的問題。
2013年6月13日，一期系統如期上線，業務量遠超預期，給系統來了一個“下馬威”。上線後數分鐘內就達到了18萬的使用者。在2013年6月18日晚上，餘額寶的使用者量已突破了100萬。2013年6月30日，餘額寶使用者數達到251.56萬。
在如此高速的業務增長壓力之下，一期系統開始面對前所未有的直銷和清算壓力的衝擊。這個新建的系統，是否能夠支撐起如此大的容量衝擊？什麼時候系統會達到瓶頸？這些問題，懸而未解讓樊振華陷入了深深的危機感中。在經過了數個失眠之夜後，他還沒找到解決問題的辦法，但他清楚地知道，再這樣下去，一期系統將會很快面臨瓶頸，成為業務增長的絆腳石。
樊振華的擔憂很快變成了現實，隨著使用者量的暴增，資料庫的負荷越來越高，實時請求的響應時間開始變緩。清算時間由最初的半個小時慢慢地變成一個小時、兩個小時、四個小時……清算系統每天會在凌晨收到支付寶最後一筆確認檔案開始清算，天弘基金的後臺運營人員會等候清算出結果以後，傳送給監管行和支付寶。隨著這些人回家的時間越來越晚，抱怨聲開始出現，樊振華的壓力也隨之增大。
系統的擴容勢在必行。然而，當樊振華收到金證科技發來報價表，開啟第一頁時，他驚呆了。如果依然使用IBM/Oracle/EMC的傳統架構進行擴容，要達到預定目標，僅僅硬體裝置採購及中介軟體的Licence費用就達到了數千萬元人民幣。這個數字對於樊振華來講，甚至對於天弘基金這家公司來講，是一個天文數字，超過了這家公以往所有對於IT投資的總和。並且裝置採購到貨就要一個月以上，想在一期系統瓶頸出現前完成擴容幾乎不可能實現。
傳統的路線走不通，就要找新的方法。當他得知阿里雲計算作為一家雲端計算服務提供商，使用雲端計算支撐了海量的網際網路企業及阿里集團自身業務時，樊振華開始和阿里雲端計算進行接觸。2013年7月，樊振華組織阿里雲、支付寶、金證科技的人一起探求解決方案。最終經過慎重思考，樊振華心一橫，說了句：“不要再討論了，上雲，上阿里雲！”
上雲吧，騰飛
上雲之路，困難重重，舉步維艱。
上雲並非一句話那麼簡單，使用雲端計算支撐當時國內最大的基金直銷和清算系統，前無古人，但開弓沒有回頭箭。樊振華召集了支付寶、阿里雲、金證科技的人一起，啟動將直銷和清算系統整體遷移到雲端計算架構，簡稱二期系統。
阿里金融云為二期系統提供了一下雲端計算服務ECS（彈性計算服務），RDS（關係型資料庫服務），SLB（負載均衡服務）。這三個服務分別對應於一期系統中的HP和IBM伺服器，Oracle資料庫，硬體負載均衡裝置。但這三種服務的單個例項的效能和容量，都比相應的物理裝置小上一大截。如何用單機效能更小的雲端計算服務來支撐那些單機效能更強都難以支撐的系統呢？經過深入的瞭解，樊振華在心中已經有了答案：“蟻群戰術”。
俗話說“三個臭皮匠，頂個諸葛亮”，“蟻群戰術”就是要充分利用雲端計算服務的快速部署能力（5分鐘內可以建立數百臺ECS），彈性伸縮能力，安全穩定，的特性，使用水平拆分演算法，將應用系統水平拆分為數十組甚至上百組平行執行的小系統，這些小系統組合起來，就可以支撐起海量的請求和超高的效能。
此時已經進入到7月中旬。按照對一期系統執行狀況趨勢的評估，一期系統的容量在沒有任何運營推廣活動的情況下，只能支撐到9月份便會面臨瓶頸。樊振華還為理清楚二期的效能和容量設計目標時，又接到了新的壓力：天弘基金和支付寶管理層已經決定餘額寶要參加阿里雙十一，雙十一是網民們年度的購物狂歡節，但對於後臺支撐的技術人眼來講，絕對是一場惡戰。很快，傳來了支付寶對天弘提出的雙十一支撐要求：
1、實時請求的相應要超過1000筆每秒。
2、清算系統要支援單日3億筆交易清算，清算時間不得超過150分鐘。
3、10月份支付寶會展開相關運營活動，必須在10月份前上線。
面對這樣幾近變態的要求，只有2兩個月的系統改造時間，專案組遇到了巨大的困難：
1、如何進行系統水平拆分：
a)按照“蟻群戰術”，將原有系統的業務邏輯水平拆分成多組小系統。如何才能保證拆分儘可能平均和拆分後的擴充套件性是一個繞不過去的難點。水平拆分依據那個欄位來做拆分，需要根據業務特性慎重考慮。一個細節考慮不到，會導致全盤皆輸。
2、將Oracle替換為mysql。
a)Mysql無論是單機效能和功能，都遠遠與單機的oracle無法匹敵。使用mysql代替oracle，原有的儲存過程怎麼辦？一些涉及多表join的操作在mysql下執行效率較低還如何解決。工作量有多大，沒人清楚。
3、資料遷移工程浩大，難度極高。
a)一期系統部署在天弘基金在天津的資料中心，而二期系統卻部署在阿里雲在杭州的節點，如何做到無縫割接？並且考慮到網際網路使用者的使用者體驗，一期系統和二期系統在上線期間，不允許出現業務中斷，專案組必須在大資料量，異構環境，遠端遷移等複雜環境下，實現無縫遷移。做到上線過程最終客戶無感知。
4、直銷和TA系統的資源爭搶問題
a)一期方案將直銷和TA進行了融合，來解決資料互動問題。但由於傳統的TA與實時請求在不同時段執行，所以採用了主動爭搶機制的負載均衡，及貪婪式的CPU佔用。以保證充分利用硬體資源完成業務清算。才傳統模式下沒有問題，但一期系統進行合併以後，TA和實時請求的應用系統部署同一組伺服器上，每次TA系統啟動清算的時間段，會嚴重影響實時請求的相應時間，甚至造成響應失敗。
5、整個架構保持2年以上的系統擴容能力
a)上雲後的系統必須能夠滿足業務量飛速高漲的情況下，可以根據業務量的大小做到無縫升級。2年之內，不能因為擴容而改變系統架構。在保證擴容性的前提下，經濟和投入必須控制在合理範圍。
這些問題，不管是樊振華，還是金證科技，在分散式系統和雲端計算這個領域，雖然瞭解很多，但真正動刀槍，還是第一次。即使阿里雲和支付寶的技術人員，在這麼短的時間內，要解決這麼多難題，也都不禁捏一把汗。
走投無路，背水一戰。
樊振華清楚他已經沒有退路，只有往前走才是出路。他召集阿里雲，天弘基金，金證科技，支付寶四方的技術人員在閉關室全部進行封閉式開發，一場艱苦的戰役就此打響。
“管不了那麼多，這些只能一個一個解決，不然怎麼辦？”樊振華每次面對棘手的困難的時候總會說這麼一句。但困難都是終究會被解決：
1、系統水平拆分
a)系統拆分的基本原理很簡單，就是按照一個業務欄位，比如支付寶協議號作為拆分依據。對欄位取雜湊值以後根據拆分虛節點的個數進行求模。這樣就可以簡單的將所有的請求拆分成多份。
b)在二期系統的拆分過程中，經過測算，需要使用50組業務節點，但在拆分的時候，考慮到擴充套件性。並未簡單的拆分成50份。而是拆分成1000份，然後每個節點處理20份的資料。這樣做的好處就是將來如果系統遇到瓶頸，需要擴容的時候，不需要對拆分演算法進行修改，而且資料平均遷移的時候只需要以庫為級別進行，從而避免了拆表。
2、去oracle
a)去oracle其實並無捷徑，都需要紮紮實實的一點點完成。首先是將儲存過程等mysql不支援或支援不好的資料庫邏輯上移到應用中。
b)其次要將複雜度比較高的sql語句進行拆分，變成多條簡單的sql語句。從而提高mysql的執行效率。
c)阿里雲的RDS提供的慢sql查詢功能，可以將整個系統執行效率比較慢的sql呈現給使用者，幫助使用者優化SQL語句。
3、資料遷移。
a)資料遷移是這個專案的重頭戲，遷移過程中使用全量+增量+資料訂正+並行執行檢查等幾個階段完成。
b)二期系統在生產環境部署完成後，將在天津的一期系統的全量資料打包，按照指定拆分演算法拆成1000份以後，通過專線匯入到二期系統中。匯入以後，將天津的一期系統前置機轉發服務開啟，將所有實時請求轉發到二期系統，這樣兩個系統同時處理請求。然後在交易日之後，以一期系統為準，將二期系統中的資料進行訂正，補全。這些所有的操作必須在24小時內完成是遷移成功的必要條件。
c)資料遷移成功之後，兩個系統實際上在並行執行。需要使用指令碼每天對比兩個系統中的資料，連續2週數據對比無誤以後，由支付寶將請求地址從一期系統切換到二期系統，整個遷移才算完成。
4、直銷和TA的再次分離
a)藉助雲端計算快速靈活的機制，將直銷系統和TA系統的應用邏輯層進行完全分開，分開後的直銷和TA系統分別執行在一組ECS中，兩套系統後端連線同一套的RDS資料庫服務。這樣既能保證TA和直銷系統在應用效能上不會發生爭搶，而且又不會發生資料傳遞問題。
5、擴容性保證
a)除了在水平拆分演算法的時候就採用雙重對映的機制來保證架構本身的擴容性，還充分利用了阿里雲雲服務可以無縫升級的特性，來進行容量保證。
b)拿RDS資料庫來講，阿里雲提供了新1型到新7型等7個型號，效能逐漸增強。最終選擇了新5型做為資料庫伺服器，並沒有一步到位採用最高型號。這樣當系統出現瓶頸的時候，就可以通過將所有RDS從新5性升級到更高型號來將系統容量翻倍。
架構解讀
將清算和直銷的叢集分為兩組獨立的叢集,但使用相同的RDS資料庫服務.這樣既避免了在應用層面的資源爭搶,又可以做到資料的共享.其中實時請求會先到達4個互為冗餘備份的SLB(負載均衡),避免SLB單點故障.SLB將請求轉發給5臺前置機,前置機會按照拆分演算法,將該請求路由到相應的節點進行處理,該節點處理完畢後,資料儲存到改組對應的RDS資料庫.而每日的對賬檔案則通過檔案伺服器進行拆分,然後清算系統的每個節點主動取出自己處理的檔案進行清算處理,然後儲存到資料庫。
歷盡磨難，涅槃重生
經過2個多月的封閉式開發，在上線之前，二期系統進行了嚴格的壓力測試，測試結果讓樊振華懸著的心終於放下了。
TA系統完成3億筆訂單的清算，可以在6400秒內清算完成返回給支付寶，完全符合專案150分鐘。對開戶的實時請求，專案目標要求達到1000筆每秒。壓測的資料輕鬆達到5000筆每秒。並且具備11000筆每秒的儲備能力隨時可放開。 二期系統終於在2013年9月26日上午正式上線成功。在上線的前一天，一期系統每天完成清算需要8個小時，而上線後的那天，二期系統完成了她第一次的清算，只用了不到30分鐘。這個結果讓那些經歷多個不眠之夜的後臺運營人員眉開眼笑，終於可以在晚上回家睡覺了。實時請求的響應時間老系統為180ms，上雲以後，平均130ms。效果明顯。如下圖：
萬事具備，只欠東風，只有經過“雙十一”海量交易量的摧殘，才能驗證系統是符合設計要求的。2013年11月11日 餘額寶首次參加”雙十一”大促,完成1679萬筆贖回，1288萬筆申購的清算工作，成功為639萬用戶正確分配收益。當天處理了61.25億元的消費贖回，119.97億元的轉入申購。完成這些所有的清算工作，系統只用了46分鐘！
雲端計算是萬能的嗎？
總結在上雲以後至今的業務發展狀況,資料暴增以後,面臨的新問題,丟擲面臨的資料問題,引發思考
這一路走來，就像直銷和TA系統經歷了分開，合併，再分開的演進路線，讓樊振華想起一句話“天下之勢，分久必合，合久必分”。過去這麼多年，以IOE為主的集中式計算已經告一段落，在這個網際網路的時代，雲端計算和分散式的結合代替集中式計算已經深深植入他的腦海之中。
此時的樊振華，已經和一年前的他截然不同，一年前，他還在為各種硬體選型，採購流程而忙碌。但一年後，他更喜歡在人們面前談起的是雲端計算，大資料，分散式，使用者體驗，網際網路的IT架構等名詞。
具備強大水平擴容能力的二期系統，足以讓這個飽經歷練的老兵高枕無憂，休息一陣子，再也不用擔心繫統容量和高併發的問題。但有一顆種子，在樊振華的心目中開始發芽：他清晰的知道，如今這個二期系統已經不是簡單的直銷和清算系統，每天沉澱在50個數據庫裡的海量使用者和交易的資料量在暴漲，如何儲存這些資料？如何使用這些資料？該如何才能產生最大的價值？
未來如何發展
有了這顆種子，樊振華休了個短假，他又開始了新的征程，投入了大資料的懷抱，這一次，他選擇了阿里雲提供的ODPS（開放資料處理服務）來作為自己的大資料平臺。ODPS目前是阿里集團進行離線資料處理的平臺，其支撐了阿里金融，淘寶等多家Bu的大資料業務。有了這個平臺作為後盾，樊振華清晰了很多，他腦海中復現了一幅畫面：在不久的將來，通過對目前沉澱的海量資料的分析，可以把握成千上億的使用者的理財需求及不同的風險接受能力。而天弘基金，根據這些客戶的情況，提供更多更豐富的理財產品。或許到那一天，讓天下所有的人享受到符合自己的理財服務真不是夢想了。
一年前的現在，在杭州支付寶大樓裡有個叫“春秋書院”的閉關室，裡面一群緊張而興奮的年輕人在忙碌著。專案室巨大的落地窗前，站著一個面色凝重的人，他就是天弘基金創新事業部技術負責人樊振華，一個在金融IT領域有著豐富經驗的老兵。他看著窗外川流不息的汽車，深深地吸了一口氣。
這是一個只有代號但沒有名字的保密專案，內部稱之為“2號專案”，2號專案的旺旺交流群的簽名上寫著“2013支付寶祕密武器”，足可見這個專案的重要性。
截止到今天，中國近億人因為這個專案受益，改變了自己的理財習慣。這個神祕的專案，就是餘額寶。那麼餘額寶的初期業務背景是什麼呢
餘額寶業務背景
在支付寶上賣基金的想法，在天弘基金電商負責人周曉明心中經過多次的思考和錘鍊，已逐漸清晰。他在向阿里小微金服集團國內事業群總裁樊治銘介紹餘額寶模式的雛形時，準備了5分鐘的內容，但只講1分鐘後，雙方即達成一致意見可以做、快速做，並期望餘額寶能在6月份上線運營。
雙方隨即行動起來，進行了簡單的分工，支付寶負責餘額寶在支付寶端的建設工作，而基金公司端負責與支付寶對接的直銷和清算系統的建設重任，就落到了樊振華頭上。
這是一個從來沒有人做過，也沒有人知道該如何做的創新業務，面對支付巨大的使用者群體，在僅不足3個月的時間內，該如何設計基金的清算和直銷系統，成為了樊振華面臨的頭號難題。2013年3月，樊振華一行與支付寶技術方進行整體架構溝通，這是傳統金融行業建設思路與網際網路技術路線的第一次衝突，雙方團隊在閉關室足足討論了4天，確定下來一期系統的建設目標和要解決的問題。
當時主要面臨以下難點。
1、要能夠支援“千萬級”使用者的系統容量。
a)傳統的基金銷售系統主要是和第三方銷售機構，如銀行理財專櫃、網上銀行進行合作銷售。直銷系統能夠處理每天幾萬到幾十萬個使用者的開戶就完全夠用了。但“餘額寶”面對的是數以億計的支付寶使用者，使用者的開戶數量和併發量與傳統業務有數量級的差異。
b)傳統基金的TA系統面對的使用者是以理財為目的的申購和贖回，因此每天清算的交易筆數要求也只有幾萬到幾十萬即可滿足。但“餘額寶”的業務模式裡，支付寶使用者的每一筆消費，都會轉化為一次基金的贖回，又加上海量的潛在使用者群，每日清算筆數將會是傳統模式的百倍甚至是千倍。
2、直銷系統和TA系統的融合。
a)傳統的直銷和TA是分別獨立的系統，但對於接入支付寶這種入口交易空前頻繁、資料量極為龐大的需求而言，傳統的分離式檔案互動方式不能滿足效率和優化利用資源的要求。因此，專案組提出了功能整合、功能簡化、當前庫和歷史庫分離的技術結構。讓直銷和清算系統使用同一套資料庫，來避免資料拷貝帶來的業務時延。
3、7×24小時的基金直銷系統。
a)由於渠道的原因，傳統基金直銷系統的大多數開戶出現在銀行的工作日。因此係統能夠做到5×8小時即可滿足大部分客戶的需求。但網際網路的屬性是7×24小時，因此係統也應該具備7×24小時不間斷的服務能力。
4、支付寶與天弘基金雙方的資料傳輸與系統互動。
a)餘額寶的直銷和清算系統會部署於天弘基金在天津的資料中心，而支付寶的“餘額寶”系統部署在杭州，雙方之間的通訊協議，遠距離資料傳輸面臨很大的挑戰。
這樣，根據早期的建設需求，餘額寶一期系統的架構和系統容量規劃工作展開了序幕。
一期系統建設
距離上線時間只有不足3個月，樊振華和系統開發商金證科技的技術人員進行了緊張的架構工作。經過數次討論，雙方有了初步的統一意見，並形成了建設目標。
1、基於KCBP/KCXP的叢集技術,
a)系統第一要素是要滿足創新業務的技術支撐要求，經雙方討論後，決定走較成熟的傳統金融技術路線。決定選用金證科技的KCBP/KCXP做叢集。金證股份核心業務平臺KCBP（Kingdom Core Business Platform）是專門為證券基金交易系統設計的外層交易中介軟體，同時具有普通交易中介軟體的特徵和功能，KCBP同時也支援跨平臺服務的開發與部署。為後續的可能出現的架構調整留下預留空間。
b)金證通訊交換平KCXP（Kingdom Communication eXchange Platform）中介軟體技術在券商行業有大量應用案例，具有很高的可靠性和可用性。並在資料傳輸效率、安全性和容錯性、負載均衡以及擴充套件性方面進行了優化，已經足夠成熟。
2、基於傳統的IOE的基礎架構。
a)在如此短時間內，有很多的功能優化，業務流程更改等開發工作，再配合相關的測試，必須控制改動的範圍。因此基礎架構決定採用傳統的HP/IBM/Oracle/EMC的方案，靠使用高階硬體裝置的方式，提高一期系統的整體容量和效能。
3、直銷和TA的系統整合。
a)為了減少直銷系統和TA的資料傳輸延遲，決定兩個系統使用同一套資料庫架構。
b)為了避免單點故障引起的業務中斷，應用層的直銷和TA平均分佈在每臺伺服器上。確保每個應用伺服器的角色具備可替代性。
4、跨省的MSTP專線鏈路
a)天弘基金清算和交易中心在天津資料機房，通過架設兩條4M的MSTP專線，連線到支付寶杭州資料機房。兩條專線之間互為備份，確保通訊鏈路安全。
一期系統的架構圖如下：
架構解讀：支付寶實時開戶，申購，贖回等實時請求，和每天的離線對賬檔案，都通過MSTP專線與一期系統進行通訊。其中實時請求通過RADWARE硬體負載均衡分發到兩臺前置機，前置機在做完報文解析以後，將請求傳送到XP的訊息佇列。然後由BP以主動負載均衡的機制，從XP中取出相應請求進行處理，處理結果保持到後端資料庫中。
幸福的煩惱
然而，在一期系統上線以後，面對業務量暴增的情況，系統遇到了瓶頸同時也出現了新的問題。
2013年6月13日，一期系統如期上線，業務量遠超預期，給系統來了一個“下馬威”。上線後數分鐘內就達到了18萬的使用者。在2013年6月18日晚上，餘額寶的使用者量已突破了100萬。2013年6月30日，餘額寶使用者數達到251.56萬。
在如此高速的業務增長壓力之下，一期系統開始面對前所未有的直銷和清算壓力的衝擊。這個新建的系統，是否能夠支撐起如此大的容量衝擊？什麼時候系統會達到瓶頸？這些問題，懸而未解讓樊振華陷入了深深的危機感中。在經過了數個失眠之夜後，他還沒找到解決問題的辦法，但他清楚地知道，再這樣下去，一期系統將會很快面臨瓶頸，成為業務增長的絆腳石。
樊振華的擔憂很快變成了現實，隨著使用者量的暴增，資料庫的負荷越來越高，實時請求的響應時間開始變緩。清算時間由最初的半個小時慢慢地變成一個小時、兩個小時、四個小時……清算系統每天會在凌晨收到支付寶最後一筆確認檔案開始清算，天弘基金的後臺運營人員會等候清算出結果以後，傳送給監管行和支付寶。隨著這些人回家的時間越來越晚，抱怨聲開始出現，樊振華的壓力也隨之增大。
系統的擴容勢在必行。然而，當樊振華收到金證科技發來報價表，開啟第一頁時，他驚呆了。如果依然使用IBM/Oracle/EMC的傳統架構進行擴容，要達到預定目標，僅僅硬體裝置採購及中介軟體的Licence費用就達到了數千萬元人民幣。這個數字對於樊振華來講，甚至對於天弘基金這家公司來講，是一個天文數字，超過了這家公以往所有對於IT投資的總和。並且裝置採購到貨就要一個月以上，想在一期系統瓶頸出現前完成擴容幾乎不可能實現。
傳統的路線走不通，就要找新的方法。當他得知阿里雲計算作為一家雲端計算服務提供商，使用雲端計算支撐了海量的網際網路企業及阿里集團自身業務時，樊振華開始和阿里雲端計算進行接觸。2013年7月，樊振華組織阿里雲、支付寶、金證科技的人一起探求解決方案。最終經過慎重思考，樊振華心一橫，說了句：“不要再討論了，上雲，上阿里雲！”
上雲吧，騰飛
上雲之路，困難重重，舉步維艱。
上雲並非一句話那麼簡單，使用雲端計算支撐當時國內最大的基金直銷和清算系統，前無古人，但開弓沒有回頭箭。樊振華召集了支付寶、阿里雲、金證科技的人一起，啟動將直銷和清算系統整體遷移到雲端計算架構，簡稱二期系統。
阿里金融云為二期系統提供了一下雲端計算服務ECS（彈性計算服務），RDS（關係型資料庫服務），SLB（負載均衡服務）。這三個服務分別對應於一期系統中的HP和IBM伺服器，Oracle資料庫，硬體負載均衡裝置。但這三種服務的單個例項的效能和容量，都比相應的物理裝置小上一大截。如何用單機效能更小的雲端計算服務來支撐那些單機效能更強都難以支撐的系統呢？經過深入的瞭解，樊振華在心中已經有了答案：“蟻群戰術”。
俗話說“三個臭皮匠，頂個諸葛亮”，“蟻群戰術”就是要充分利用雲端計算服務的快速部署能力（5分鐘內可以建立數百臺ECS），彈性伸縮能力，安全穩定，的特性，使用水平拆分演算法，將應用系統水平拆分為數十組甚至上百組平行執行的小系統，這些小系統組合起來，就可以支撐起海量的請求和超高的效能。
此時已經進入到7月中旬。按照對一期系統執行狀況趨勢的評估，一期系統的容量在沒有任何運營推廣活動的情況下，只能支撐到9月份便會面臨瓶頸。樊振華還為理清楚二期的效能和容量設計目標時，又接到了新的壓力：天弘基金和支付寶管理層已經決定餘額寶要參加阿里雙十一，雙十一是網民們年度的購物狂歡節，但對於後臺支撐的技術人眼來講，絕對是一場惡戰。很快，傳來了支付寶對天弘提出的雙十一支撐要求：
1、實時請求的相應要超過1000筆每秒。
2、清算系統要支援單日3億筆交易清算，清算時間不得超過150分鐘。
3、10月份支付寶會展開相關運營活動，必須在10月份前上線。
面對這樣幾近變態的要求，只有2兩個月的系統改造時間，專案組遇到了巨大的困難：
1、如何進行系統水平拆分：
a)按照“蟻群戰術”，將原有系統的業務邏輯水平拆分成多組小系統。如何才能保證拆分儘可能平均和拆分後的擴充套件性是一個繞不過去的難點。水平拆分依據那個欄位來做拆分，需要根據業務特性慎重考慮。一個細節考慮不到，會導致全盤皆輸。
2、將Oracle替換為mysql。
a)Mysql無論是單機效能和功能，都遠遠與單機的oracle無法匹敵。使用mysql代替oracle，原有的儲存過程怎麼辦？一些涉及多表join的操作在mysql下執行效率較低還如何解決。工作量有多大，沒人清楚。
3、資料遷移工程浩大，難度極高。
a)一期系統部署在天弘基金在天津的資料中心，而二期系統卻部署在阿里雲在杭州的節點，如何做到無縫割接？並且考慮到網際網路使用者的使用者體驗，一期系統和二期系統在上線期間，不允許出現業務中斷，專案組必須在大資料量，異構環境，遠端遷移等複雜環境下，實現無縫遷移。做到上線過程最終客戶無感知。
4、直銷和TA系統的資源爭搶問題
a)一期方案將直銷和TA進行了融合，來解決資料互動問題。但由於傳統的TA與實時請求在不同時段執行，所以採用了主動爭搶機制的負載均衡，及貪婪式的CPU佔用。以保證充分利用硬體資源完成業務清算。才傳統模式下沒有問題，但一期系統進行合併以後，TA和實時請求的應用系統部署同一組伺服器上，每次TA系統啟動清算的時間段，會嚴重影響實時請求的相應時間，甚至造成響應失敗。
5、整個架構保持2年以上的系統擴容能力
a)上雲後的系統必須能夠滿足業務量飛速高漲的情況下，可以根據業務量的大小做到無縫升級。2年之內，不能因為擴容而改變系統架構。在保證擴容性的前提下，經濟和投入必須控制在合理範圍。
這些問題，不管是樊振華，還是金證科技，在分散式系統和雲端計算這個領域，雖然瞭解很多，但真正動刀槍，還是第一次。即使阿里雲和支付寶的技術人員，在這麼短的時間內，要解決這麼多難題，也都不禁捏一把汗。
走投無路，背水一戰。
樊振華清楚他已經沒有退路，只有往前走才是出路。他召集阿里雲，天弘基金，金證科技，支付寶四方的技術人員在閉關室全部進行封閉式開發，一場艱苦的戰役就此打響。
“管不了那麼多，這些只能一個一個解決，不然怎麼辦？”樊振華每次面對棘手的困難的時候總會說這麼一句。但困難都是終究會被解決：
1、系統水平拆分
a)系統拆分的基本原理很簡單，就是按照一個業務欄位，比如支付寶協議號作為拆分依據。對欄位取雜湊值以後根據拆分虛節點的個數進行求模。這樣就可以簡單的將所有的請求拆分成多份。
b)在二期系統的拆分過程中，經過測算，需要使用50組業務節點，但在拆分的時候，考慮到擴充套件性。並未簡單的拆分成50份。而是拆分成1000份，然後每個節點處理20份的資料。這樣做的好處就是將來如果系統遇到瓶頸，需要擴容的時候，不需要對拆分演算法進行修改，而且資料平均遷移的時候只需要以庫為級別進行，從而避免了拆表。
2、去oracle
a)去oracle其實並無捷徑，都需要紮紮實實的一點點完成。首先是將儲存過程等mysql不支援或支援不好的資料庫邏輯上移到應用中。
b)其次要將複雜度比較高的sql語句進行拆分，變成多條簡單的sql語句。從而提高mysql的執行效率。
c)阿里雲的RDS提供的慢sql查詢功能，可以將整個系統執行效率比較慢的sql呈現給使用者，幫助使用者優化SQL語句。
3、資料遷移。
a)資料遷移是這個專案的重頭戲，遷移過程中使用全量+增量+資料訂正+並行執行檢查等幾個階段完成。
b)二期系統在生產環境部署完成後，將在天津的一期系統的全量資料打包，按照指定拆分演算法拆成1000份以後，通過專線匯入到二期系統中。匯入以後，將天津的一期系統前置機轉發服務開啟，將所有實時請求轉發到二期系統，這樣兩個系統同時處理請求。然後在交易日之後，以一期系統為準，將二期系統中的資料進行訂正，補全。這些所有的操作必須在24小時內完成是遷移成功的必要條件。
c)資料遷移成功之後，兩個系統實際上在並行執行。需要使用指令碼每天對比兩個系統中的資料，連續2週數據對比無誤以後，由支付寶將請求地址從一期系統切換到二期系統，整個遷移才算完成。
4、直銷和TA的再次分離
a)藉助雲端計算快速靈活的機制，將直銷系統和TA系統的應用邏輯層進行完全分開，分開後的直銷和TA系統分別執行在一組ECS中，兩套系統後端連線同一套的RDS資料庫服務。這樣既能保證TA和直銷系統在應用效能上不會發生爭搶，而且又不會發生資料傳遞問題。
5、擴容性保證
a)除了在水平拆分演算法的時候就採用雙重對映的機制來保證架構本身的擴容性，還充分利用了阿里雲雲服務可以無縫升級的特性，來進行容量保證。
b)拿RDS資料庫來講，阿里雲提供了新1型到新7型等7個型號，效能逐漸增強。最終選擇了新5型做為資料庫伺服器，並沒有一步到位採用最高型號。這樣當系統出現瓶頸的時候，就可以通過將所有RDS從新5性升級到更高型號來將系統容量翻倍。
架構解讀
將清算和直銷的叢集分為兩組獨立的叢集,但使用相同的RDS資料庫服務.這樣既避免了在應用層面的資源爭搶,又可以做到資料的共享.其中實時請求會先到達4個互為冗餘備份的SLB(負載均衡),避免SLB單點故障.SLB將請求轉發給5臺前置機,前置機會按照拆分演算法,將該請求路由到相應的節點進行處理,該節點處理完畢後,資料儲存到改組對應的RDS資料庫.而每日的對賬檔案則通過檔案伺服器進行拆分,然後清算系統的每個節點主動取出自己處理的檔案進行清算處理,然後儲存到資料庫。
歷盡磨難，涅槃重生
經過2個多月的封閉式開發，在上線之前，二期系統進行了嚴格的壓力測試，測試結果讓樊振華懸著的心終於放下了。
TA系統完成3億筆訂單的清算，可以在6400秒內清算完成返回給支付寶，完全符合專案150分鐘。對開戶的實時請求，專案目標要求達到1000筆每秒。壓測的資料輕鬆達到5000筆每秒。並且具備11000筆每秒的儲備能力隨時可放開。 二期系統終於在2013年9月26日上午正式上線成功。在上線的前一天，一期系統每天完成清算需要8個小時，而上線後的那天，二期系統完成了她第一次的清算，只用了不到30分鐘。這個結果讓那些經歷多個不眠之夜的後臺運營人員眉開眼笑，終於可以在晚上回家睡覺了。實時請求的響應時間老系統為180ms，上雲以後，平均130ms。效果明顯。如下圖：
萬事具備，只欠東風，只有經過“雙十一”海量交易量的摧殘，才能驗證系統是符合設計要求的。2013年11月11日 餘額寶首次參加”雙十一”大促,完成1679萬筆贖回，1288萬筆申購的清算工作，成功為639萬用戶正確分配收益。當天處理了61.25億元的消費贖回，119.97億元的轉入申購。完成這些所有的清算工作，系統只用了46分鐘！
雲端計算是萬能的嗎？
總結在上雲以後至今的業務發展狀況,資料暴增以後,面臨的新問題,丟擲面臨的資料問題,引發思考
這一路走來，就像直銷和TA系統經歷了分開，合併，再分開的演進路線，讓樊振華想起一句話“天下之勢，分久必合，合久必分”。過去這麼多年，以IOE為主的集中式計算已經告一段落，在這個網際網路的時代，雲端計算和分散式的結合代替集中式計算已經深深植入他的腦海之中。
此時的樊振華，已經和一年前的他截然不同，一年前，他還在為各種硬體選型，採購流程而忙碌。但一年後，他更喜歡在人們面前談起的是雲端計算，大資料，分散式，使用者體驗，網際網路的IT架構等名詞。
具備強大水平擴容能力的二期系統，足以讓這個飽經歷練的老兵高枕無憂，休息一陣子，再也不用擔心繫統容量和高併發的問題。但有一顆種子，在樊振華的心目中開始發芽：他清晰的知道，如今這個二期系統已經不是簡單的直銷和清算系統，每天沉澱在50個數據庫裡的海量使用者和交易的資料量在暴漲，如何儲存這些資料？如何使用這些資料？該如何才能產生最大的價值？
未來如何發展
有了這顆種子，樊振華休了個短假，他又開始了新的征程，投入了大資料的懷抱，這一次，他選擇了阿里雲提供的ODPS（開放資料處理服務）來作為自己的大資料平臺。ODPS目前是阿里集團進行離線資料處理的平臺，其支撐了阿里金融，淘寶等多家Bu的大資料業務。有了這個平臺作為後盾，樊振華清晰了很多，他腦海中復現了一幅畫面：在不久的將來，通過對目前沉澱的海量資料的分析，可以把握成千上億的使用者的理財需求及不同的風險接受能力。而天弘基金，根據這些客戶的情況，提供更多更豐富的理財產品。或許到那一天，讓天下所有的人享受到符合自己的理財服務真不是夢想了。