前言

2015年春節最大的特色就是“搖一搖”，微信紅包在春晚搖一搖互動總量超過110億次，峰值達8.1億次/分鐘，有185個國家傳遞微信祝福。支付寶錢包在除夕晚上8點達峰值，首頁被點擊的次數為8.832億次/分鐘。表面上來看“搖一搖”是在送紅包，但從深層次的互聯網思維來看，搖一搖的目的是要創造和凸顯“移動支付”在互聯網金融的價值鏈，甚至一帶一路，將“移動支付”模式的業務，帶出國門推向全球，此舉對金融行業未來的生態影響意義重大。

搖一搖隱含的商業模式不是此篇文章討論重點，在此要強調的是在云計算和大數據時代，任何一個商業模式的創新都需要有最先進的技術配合和支撐。從技術角度來看，這些看似業務邏輯簡單的“搖一搖”在面對高流量和高并發情況下，承載天量的訪問量對系統框架設計師來說是巨大的挑戰。當面臨“有計劃、難預測、暫時性”的巨大訪問量，該如何解決此問題？是花巨資建設系統呢？ 還是將需要“短暫”巨大資源的業務托管在云計算數據中心，讓它們提供快速靈活可調度的資源呢？

本文作者從互聯網收集大量有關12306的信息，首先描述12306系統與大型電商交易系統的主要差異和說明此差異為何需要巨大的計算資源來支撐； 再進一步探討12306混合云設計的考量 - 安全性和系統資源擴展性，并說明為何只將“余票查詢業務”放在阿里云提供服務。最后以論證的方式“推測”12306兩地三中心的混合云架構設計（有關12306混合云的架構和解析是作者個人的推測，有誤解地方請求交流和指正）

在此篇文章，不探討火車運能不足，搶不到車票返鄉引起民怨問題，因為鐵路的基礎建設需要時間解決；以Pivotal Gemfire為例， 是因為2015年12306在兩地三中心部署數百個Gemfire節點，這些應用節點（“異于虛機節點”）可按需以熱部署方式來擴展，體現“云”的伸縮特性和流動性。

一、12306與電商交易系統

很多人喜歡將12306與淘寶網做比較， 認為12306互聯網售票網站從屬性來說是電子商務B2C的一支；用戶必須登錄，瀏覽，選擇商品，下訂單， 訂單確認，支付和物流。如果只看整個交易流程，它們確實是一樣的。 但從深層次的細節探討，12306背后所隱藏的業務邏輯是非常復雜，遠遠超過一般人的想象。

12306網站與電商交易系統業務邏輯的差異

如何解決大型網站所面對的高負載流量和高并發訪問，一直以來都是全世界公認的技術難題。對于任何一個交易系統來說不外乎做兩件事，一是提供查詢，二是數據計算；任何查詢業務都有響應時間的要求，從用戶體驗最好不要超過5秒鐘；而數據計算（實時計算或非實時批量計算）與實際業務邏輯有密切的關系。

對于電子商務網站的交易系統，例如淘寶網，當店家出售一件商品，庫存減一，客戶退貨，庫存加一，當庫存為零，商品下架，有問題線下討論。此類交易系統提供簡單快速的計算。因為不同品牌商品的銷售彼此之間沒有關聯性，不會因為某件品牌商品的出售關聯到其他品牌商品的庫存量，它們的商品庫存是屬于“靜態庫存”；所以電商交易系統的主要設計重點是提供快速響應時間，高可用性（容災和備份）和系統擴展性，避免在高峰交易期間，因為響應時間慢或是系統當機而失去龐大的商機。

12306互聯網售票系統是業務邏輯很復雜的系統，如果將每張可出售的火車票當成一件商品來看，每張票的銷售都會關聯到整條路線每個站點可銷售的余票量,有些站點的余票量會產生變化， 有些站點余票量不會有變化。由另外一個角度來看，當銷售一張票， 改簽，或退票時，整條路線每個站點的余票量都需要重新計算，也就是說每個站點的余票庫存是個“動態變化庫存”的概念。站點與站點之間的余票庫存有巨大的關聯性，此“動態庫存”概念的業務邏輯是12306與電商網站最大的差異。12306的設計重點不但要具有大型電商網站所具備的特性外 （要提供快速響應時間，高可用性（容災和備份）和系統的擴展性），還需要有強大的CPU計算資源來支撐。

12306 系統主要瓶頸 - 余票計算與配票規則

由上面所述，每張火車票的銷售狀態變化（買票，退票，改簽），都會影響到整條路線火車站點可銷售的余票量；例如，某條火車路線有100個車次，每個車次可承載1000人，有100個一等座， 900個2等座，另外還有50個火車停靠站，這有多少個排列組合？ 從理論上來說，余票計算是在解答數學模型的難題。

在整個客票系統里，有數十條行車路線，有3000多個車次（G,D,K,Z,C,..），5000多個火車站點，有不同的席次（硬座，硬臥， 軟座， 軟臥，無座），座位等級(商務， 一等， 二等)，和車票等級（一般，軍人， 學生，殘障，小孩）等因素，將這些參數放在數學模型上，至少有數千億條的排列組合。而目前的客車運量有限，每天不超過1000萬名旅客。 如何將1000萬張車票分配到數千億條的排列組合里面呢？并且還要考慮公正，公平的合理分配。

如果將整條路線的所有車票都放在起始站出售的話，乘車距離最遠的先購票，創造的利潤最大，但是下游站點就買不到票，失去公正和公平的分配原則。所以，每個站點的余票計算并不是簡單的兩站之間算好的票數，做加加減減的計算。

鐵路運輸為民眾提供便捷的出行， 如何將有限資源公正公平的合理分配，讓大眾滿意是需要靠智慧解決的。 參考國內外的售票原則，運輸部門一定要制定一套復雜的分配規則，這些規則是與車次，路線，加班車，席次，座位等級，車票等級，乘車區間，x天預售期和搭乘時間等都有密切關系。 每一個特定的余票查詢，都會觸發余票計算，每班車次的余票計算都有上萬條規則需要匹配，所有經過“乘車區間”的車次都需要做余票計算；全國有3000多個車次，5000多個站點，這些分配規則總數可能達千萬條級別。例如，以滬寧線為例，在春運尖峰期間，經過“上海到南京”區間的車次達300多班次，每次查詢需要計算300多班車次的余票量。

這意味著余票查詢/計算需要使用大量的CPU計算資源，同時必須快速反應余票查詢的結果給用戶。在春運售票高峰期間，每分鐘都有數萬張車票的銷售，假如余票查詢的響應時間緩慢，這些信息就失去價值，會發生看得到票，但實際上買不到票的情況發生。

二、12306 混合云考慮因素和規劃

一般的商業活動都有季節性的旺季和淡季之分，在旺季時煩惱是否有足夠的庫存，以免失在商機，在淡季時就要想辦法促銷，降低庫存。 使成本最小化，利潤最大化，是市場經濟的商業法則。 12306互聯網售票系統，也面臨節假日和非節假日高高低低的需求，12306在春運售票高峰期間的訪問流量（PV值）和平時訪問流量高達上千倍的差異；如果按原來的系統架構，要解決春運時高流量高并發的問題，可能需要擴充“數十倍”或數百部的Unix服務器才能滿足需求。 如果12306自建系統，但在春運以后，又該如何處理服務器過剩的問題，才不會造成資源浪費呢？

根據百度百科對混合云的定義，“混合云是融合公有云和私有云，是近年來云計算的主要模式和發展方向。企業用戶出于安全考慮，更愿意將數據存放在私有云中，但是同時又希望可以獲得公有云的計算資源，在這種情況下混合云被越來越多的采用，它將公有云和私有云進行混合和匹配，以獲得最佳的效果，這種個性化的解決方案，達到既省錢又安全的目的”。

混合云托管考慮因素

由上面的定義，混合云服務模式應該是12306最佳的選項，可以將“有計劃，難預測，暫時性”需要巨大資源的業務放在公有云提供服務。如果12306采用混合云的服務模式，有哪些重要因素需要考慮？

• 托管方式：整個業務托管還是部分業務托管？
• 安全性的考量：敏感性資料該如何存放和保護呢？如何規避風險？
• 業務子系統的獨立性：如果是部分業務托管，被指定托管業務的子系統是否能獨立剝離原先系統的業務流程？
• 協同合作：在公有云的業務子系統的數據又如何回流與私有云的原來系統在業務上配合，協同合作呢？
• 數據源的傳輸和復制/同步：如何復制/同步私有云和公有云的數據？
• 資源的彈性擴展：遷移到公有云的業務子系統是否能實現按需彈性擴展，利用云計算數據中心的網絡和服務器資源來提供服務？