一年前的現在，在杭州支付寶大樓里有個叫“春秋書院”的閉關室，里面一群緊張而興奮的年輕人在忙碌著。項目室巨大的落地窗前，站著一個面色凝重的人，他就是天弘基金創新事業部技術負責人樊振華，一個在金融IT領域有著豐富經驗的老兵。他看著窗外川流不息的汽車，深深地吸了一口氣。

　　這是一個只有代號但沒有名字的保密項目，內部稱之為“2號項目”，2號項目的旺旺交流群的簽名上寫著“2013支付寶秘密武器”，足可見這個項目的重要性。

　　截止到今天，中國近億人因為這個項目受益，改變了自己的理財習慣。這個神秘的項目，就是余額寶。那么余額寶的初期業務背景是什么呢？由此引發出對IT系統建設的需求又是什么？

　　余額寶業務背景

　　在支付寶上賣基金的想法，在天弘基金電商負責人周曉明心中經過多次的思考和錘煉，已逐漸清晰。他在向阿里小微金服集團國內事業群總裁樊治銘介紹余額寶模式的雛形時，準備了5分鐘內容，但只講1分鐘后，雙方即達成一致意見可以做、快速做，并期望余額寶能在6月上線運營。

　　雙方隨即行動起來，進行了簡單的分工，支付寶負責余額寶在支付寶端的建設工作，而基金公司端負責與支付寶對接的直銷和清算系統的建設重任，就落到了樊振華頭上。

　　這是一個從來沒有人做過，也沒有人知道該如何做的創新業務，面對支付寶巨大的用戶群體，在僅不足3個月的時間內，該如何設計基金的清算和直銷系統，成為了樊振華面臨的頭號難題。

　　2013年3月，樊振華一行與支付寶技術方進行整體架構溝通，這是傳統金融行業建設思路與互聯網技術路線的第一次沖突，雙方在閉關室足足討論了4天，確定下來一期系統的建設目標和要解決的問題。

　　當時主要面臨以下難點。

　　1. 要能支持“千萬級”用戶的系統容量。

　　（1）傳統的基金銷售系統主要是和第三方銷售機構，如銀行理財專柜、網上銀行進行合作銷售。直銷系統能夠處理每天幾萬到幾十萬個用戶的開戶就完全夠用了。但“余額寶”面對的是數以億計的支付寶用戶，用戶的開戶數量和并發量與傳統業務有數量級的差異。

　　（2）傳統基金的TA系統面對的用戶是以理財為目的的申購和贖回，因此每天清算的交易筆數要求也只有幾萬到幾十萬即可滿足。但余額寶的業務模式里，支付寶用戶的每一筆消費，都會轉化為一次基金贖回，又加上海量潛在用戶群，每日清算筆數將會是傳統模式的百倍甚至是千倍。

　　2. 直銷系統和TA系統的融合。

　　傳統的直銷和TA是分別獨立的系統，但對于接入支付寶這種入口交易空前頻繁、數據量極為龐大的需求而言，傳統的分離式文件交互方式不能滿足效率和優化利用資源的要求。因此，項目組提出了功能整合、功能簡化、當前庫和歷史庫分離的技術結構。讓直銷和清算系統使用同一套數據庫，來避免數據拷貝帶來的業務時延。

　　3. 7×24小時的基金直銷系統。

　　由于渠道的原因，傳統基金直銷系統的大多數開戶出現在銀行的工作日。因此系統能做到5×8小時即可滿足大部分客戶的需求。但互聯網的屬性是7×24小時，因此系統也應具備7×24小時不間斷的服務能力。

　　4. 支付寶與天弘基金雙方的數據傳輸與系統交互。

　　余額寶的直銷和清算系統會部署于天弘基金在天津的數據中心，而支付寶的“余額寶”系統部署在杭州，雙方之間的通信協議，遠距離數據傳輸面臨很大的挑戰。

　　這樣，根據早期建設需求，余額寶一期系統的架構和系統容量規劃展開了序幕。

　　一期系統建設

　　距離上線時間只有不足3個月，樊振華和系統開發商金證科技的技術人員進行了緊張的架構工作。經過數次討論，雙方有了初步的統一意見，并形成了建設目標。

　　1. 基于傳統的IOE基礎架構。

　　在如此短的時間內，有很多功能優化、業務流程更改等開發工作，再配合相關的測試，控制改動的范圍。因此基礎架構決定采用傳統的HP/IBM/Oracle/EMC方案，靠使用高端硬件設備的方式，提高一期系統的整體容量和性能。

　　2. 直銷和TA的系統整合。

　　（1）為減少直銷系統和TA的數據傳輸延遲，決定兩個系統使用同一套數據庫架構。

　　（2）為避免單點故障引起的業務中斷，應用層的直銷和TA平均分布在每臺服務器上，確保每個應用服務器的角色具備可替代性。

　　3. 跨省的MSTP專線鏈路。

　　天弘基金清算和交易中心在天津數據機房，通過架設兩條4M的MSTP專線，連接到支付寶杭州數據機房。兩條專線之間互為備份，確保通信鏈路安全。

　　一期系統的架構如圖1所示。從中可見，支付寶實時開戶、申購和贖回等實時請求，與每天的離線對賬文件，都通過MSTP專線與一期系統進行通信。其中實時請求通過RADWARE硬件負載均衡分發到兩臺前置機，前置機在做完報文解析后，將請求發送到XP的消息隊列。然后由BP以主動負載均衡的機制，從XP中取出相應請求進行處理，處理結果保存到后端數據庫中。

圖1  一期系統構架圖

　　幸福的煩惱

　　然而，在一期系統上線以后，面對業務量暴增的情況，系統遇到了瓶頸同時也出現了新的問題。

　　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）、彈性伸縮能力和安全穩定等特性，使用水平拆分算法將應用系統水平拆分為數十組甚至上百組平行運行的小系統，這些小系統組合起來可以支撐起海量的請求和超高的性能。

　　此時已進入到2013年7月中旬。按照對一期系統運行狀況趨勢的評估，一期系統的容量在沒有任何運營推廣活動的情況下，只能支撐到9月份便會面臨瓶頸。在理清楚二期系統的性能和容量設計目標時，樊振華又接到了新的壓力：天弘基金和支付寶管理層已決定余額寶要參加阿里“雙十一”購物狂歡節，這對于支撐后臺的技術人員來講，絕對是一場惡戰。很快，傳來了支付寶對天弘提出的雙十一支撐要求：

1. 實時請求的響應要超過1000筆每秒；
2. 清算系統要支持單日3億筆交易清算，清算時間不得超過150分鐘；
3. 2013年10月份支付寶會展開相關運營活動，系統必須在10月份前上線。

　　面對這樣嚴酷的要求，且只有兩個月的系統改造時間，項目組遇到了巨大的困難。

　　1. 如何進行系統水平拆分？

　　按照“蟻群戰術”，需要將原有系統的業務邏輯水平拆分成多組小系統。而如何才能保證拆分盡可能平均和拆分后的擴展性是繞不過去的難點。水平拆分依據哪個字段來拆分，需要根據業務特性慎重考慮。一個細節考慮不到會導致全盤皆輸。

　　2. 將Oracle替換為MySQL。

　　無論是單機性能還是功能，MySQL都無法與單機的Oracle匹敵。使用MySQL代替Oracle，原有的存儲過程該怎么辦呢？一些涉及多表join的操作在MySQL下執行效率較低該如何解決？工作量有多大？沒人清楚這一系列問題的答案。

　　3. 數據遷移工程浩大，難度極高。

　　一期系統部署在天弘基金在天津的數據中心，而二期系統卻部署在阿里云在杭州的節點，如何做到無縫割接？并且考慮到互聯網用戶的用戶體驗，一期系統和二期系統在上線期間，不允許出現業務中斷，項目組必須在大數據量、異構環境、遠程遷移等復雜環境下，實現無縫遷移。做到上線過程最終客戶無感知。

　　4. 直銷和TA系統的資源爭搶問題。

　　一期方案將直銷和TA進行了融合，來解決數據交互問題。但由于傳統的TA與實時請求在不同時段運行，所以采用了主動爭搶機制的負載均衡及貪婪式的CPU占用，以保證充分利用硬件資源完成業務清算。這在傳統模式下沒有問題，但一期系統進行合并以后，TA和實時請求的應用系統部署在同一組服務器上，每次TA系統啟動清算的時間段，會嚴重影響實時請求的響應時間，甚至造成響應失敗。

　　5. 整個架構保持兩年以上系統擴容能力。

　　上云后的系統必須能夠滿足業務量飛速高漲的情況下，可以根據業務量的大小做到無縫升級。兩年之內，不能因為擴容而改變系統架構。在保證擴容性的前提下，經濟和投入必須控制在合理范圍內。

　　這些問題，不管是樊振華，還是金證科技，在分布式系統和云計算這個領域，雖然了解很多，但真正動刀槍，還是第一次。即使阿里云和支付寶的技術人員，在這么短的時間內，要解決這么多難題，也都不禁捏一把汗。

　　走投無路，背水一戰

　　樊振華清楚自己已沒有退路，只有往前走才是出路。他召集阿里云、天弘基金、金證科技和支付寶的技術人員在閉關室進行封閉式開發，一場艱苦的戰役就此打響。

　　“管不了那么多，這些問題只能一個一個解決。”樊振華每次面對棘手的困難時總會說這么一句。最終困難都被解決了。

　　1. 系統水平拆分。系統水平拆分的基本原理很簡單，就是按一個業務字段，如支付寶協議號作為拆分依據。對字段取哈希值以后根據拆分虛節點的個數進行求模。這樣就可以簡單地將所有請求拆分成多份。

　　在二期系統的拆分過程中，經過測算，需要使用50組業務節點，但在拆分時，考慮到擴展性，并未簡單地拆分成50份，而是拆分成1000份，然后每個節點處理20份數據。這樣做的好處是將來如果系統遇到瓶頸，需要擴容時，不需要對拆分算法進行修改，而且數據平均遷移時只需要以庫為級別進行，從而避免了拆表。

　　2. 去Oracle。首先是將存儲過程等MySQL不支持或支持不好的數據庫邏輯上移到應用中。

　　其次要將復雜度比較高的SQL語句進行拆分，變成多條簡單的SQL語句，從而提高MySQL的執行效率。

　　阿里云的RDS提供的慢SQL查詢功能，可以將整個系統執行效率比較慢的SQL呈現給用戶，幫助用戶優化SQL語句。

　　3. 數據遷移。數據遷移是這個項目的重頭戲，遷移過程中使用全量+增量+數據訂正+并行運行檢查等幾個階段完成。

　　二期系統在生產環境部署完成后，將在天津的一期系統的全量數據打包，按照指定拆分算法拆成1000份以后，通過專線導入到二期系統中。導入以后，將天津的一期系統前置機轉發服務打開，將所有實時請求轉發到二期系統，這樣兩個系統同時處理請求。然后，在交易日之后，以一期系統為準，將二期系統中的數據進行訂正和補全。這些所有的操作必須在24小時內完成是遷移成功的必要條件。

　　數據遷移成功之后，兩個系統實際上在并行運行。需要使用腳本每天對比兩個系統中的數據，連續2周數據對比無誤以后，由支付寶將請求地址從一期系統切換到二期系統，整個遷移才算完成。

　　4. 直銷和TA的再次分離。借助云計算快速靈活的機制，將直銷系統和TA系統的應用邏輯層進行完全分開，分開后的直銷和TA系統分別運行在一組ECS中，兩套系統后端連接同一套的RDS數據庫服務。這樣既能保證TA和直銷系統在應用性能上不會發生爭搶，又不會發生數據傳遞問題。

　　5. 擴容性保證。除了在水平拆分算法時就采用雙重映射的機制來保證架構本身的擴容性，還充分利用了阿里云云服務可以無縫升級的特性，來進行容量保證。

　　以RDS數據庫為例，阿里云提供了新1型到新7型等7個型號，性能逐漸增強。最終選擇了新5型作為數據庫服務器，并沒有一步到位采用最高型號。這樣當系統出現瓶頸時，就可以通過將所有RDS從新5型升級到更高型號來將系統容量翻倍。

圖2  二期系統構架圖

　　這種架構（圖2）將清算和直銷的集群分為兩組獨立的集群，但使用相同的RDS數據庫服務，既避免了在應用層面的資源爭搶，又可以做到數據的共享。其中，實時請求會先到達4個互為冗余備份的SLB（負載均衡），避免SLB單點故障。SLB將請求轉發給5臺前置機，前置機會按照拆分算法，將該請求路由到相應的節點進行處理，該節點處理完畢后，數據保存到改組對應的RDS數據庫。而每天的對賬文件則通過文件服務器進行拆分，然后清算系統的每個節點主動取出自己處理的文件進行清算處理，再保存到數據庫。

　　歷盡磨難，涅槃重生

　　經過兩個多月的封閉式開發，在上線之前，二期系統進行了嚴格的壓力測試，測試結果讓樊振華懸著的心終于放下了。

　　TA系統，可以在6400秒內完成3億筆訂單的清算并將清算結果返回給支付寶，完全符合清算時間不得超過150分鐘的要求。對開戶的實時請求，項目目標要求達到1000筆/秒。壓測的數據輕松達到5000筆/秒，并且具備11000筆/秒的儲備能力隨時可放開。

　　二期系統終于在2013年9月26日上午正式上線成功。在上線的前一天，一期系統每天完成清算需要8個小時，而上線當天，二期系統完成了第一次清算，只用了不到30分鐘。這個結果讓那些經歷多個不眠之夜的后臺運營人員眉開眼笑，終于可以晚上回家睡覺了。

圖3  實時請求的響應時間

　　實時請求的響應時間老系統為180ms，上云以后，平均130ms，效果十分明顯，如圖3所示。

　　萬事俱備，只欠東風，只有經過“雙十一”海量交易量的摧殘，才能驗證系統是符合設計要求的。

　　2013年11月11日，余額寶首次參加“雙十一”大促，完成1679萬筆贖回，1288萬筆申購的清算工作，成功為639萬用戶正確分配收益。當天處理了61.25億元的消費贖回，119.97億元的轉入申購。完成這些所有的清算工作，系統只用了46分鐘。

　　云計算是萬能的嗎？

　　這一路走來，直銷和TA系統經歷了分開、合并、再分開的演進路線，讓樊振華想起一句話“天下之勢，分久必合，合久必分”。過去這么多年，以IOE為主的集中式計算已告一段落，在這個互聯網的時代，云計算和分布式的結合代替集中式計算已深深植入他的腦海之中。

　　此時的樊振華，已和一年前的他截然不同——一年前，他還在為各種硬件選型、采購流程而忙碌。但一年后，他更喜歡在人們面前談起的是云計算、大數據、分布式、用戶體驗、互聯網的IT架構等名詞。

　　具備強大水平擴容能力的二期系統，足以讓這個飽經歷練的老兵高枕無憂，休息一陣子，再也不用擔心系統容量和高并發的問題。但有一顆種子，在樊振華的心目中開始發芽：如今這個二期系統已不是簡單的直銷和清算系統，每天沉淀在50個數據庫里的海量用戶和交易的數據量在暴漲，如何存儲這些數據？如何使用這些數據？該如何才能產生最大的價值？

　　未來如何發展

　　有了這顆種子，樊振華休了個短假，他又開始了新的征程，投入了大數據的懷抱，這一次，他選擇了阿里云提供的ODPS（開放數據處理服務）來作為自己的大數據平臺。ODPS目前是阿里集團進行離線數據處理的平臺，支撐了阿里金融、淘寶等多家BU的大數據業務。有了這個平臺作為后盾，樊振華清晰了很多，他腦海中復現了一幅畫面：在不久的將來，通過對目前沉淀的海量數據的分析，可以把握上億用戶的理財需求及不同的風險接受能力。而天弘基金，根據這些客戶的情況，提供更多更豐富的理財產品。或許到那一天，讓天下所有的人享受到符合自己的理財服務真不是夢想了。

　　作者白培新，阿里金融云服務業務架構師，負責金融云總體架構設計與規劃。先后供職于電信、公有云服務、金融云服務等領域，“余額寶”上云過程的阿里云側負責人。