前言

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採用混合雲的服務模式，有哪些重要因素需要考慮？

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

混合雲的規劃——按需彈性擴充套件改造

在 前面一篇文章提到，要解決12306面對“高流量，高併發“的難題是需要從軟體平臺和應用系統層面出發，要實現“可擴充套件的應用雲平臺架構”，靈活和快速熱部署的機制，才是真正解決高併發訪問的根本。 12306承建單位-鐵科院在此方面做很多改進，使用Pivotal Gemfire記憶體資料管理平臺，重新設計和改造核心子系統，從使用者登入，餘票計算，票價計算，實名身份認證，到訂單查詢；這些改造後的業務子系統都能支援“按需彈性擴充套件”， 不再受限於原來關係型資料庫無法做分散式擴充套件的問題。這些一連串的改造，打通各個環節，實現“質”的大躍進， 也為未來使用混合雲服務模式的架構打下良好的基礎。

資訊保安和業務子系統託管的選擇原則

下列進一步探討如何選擇“業務子系統”放在公有云提供服務，主要有兩點考慮因素，一為個人資訊保護， 二為需要“短暫”且強大計算機資源支援的子系統業務。

1. 購票流程和個人資訊：

• 登入：含個人資訊
• 餘票查詢/計算：不含個人資訊
• 訂單確認和訂單查詢：含購票人資訊和身份確認
• 付款：含個人的支付資訊

2. 主要伺服器叢集和個人資訊：

• Web伺服器 - 不含個人資訊
• 應用伺服器快取伺服器 - 不含個人資訊
• 登入伺服器 - 含個人資訊
• 餘票查詢/計算伺服器- 不含個人資訊
• 訂單確認和訂單查詢伺服器 - 含個人資訊
• 實名制身份確認伺服器 - 含個人資訊
• …

3. 最耗用網路資源

• Web伺服器
• 應用伺服器快取伺服器
• 餘票查詢/計算伺服器

4. 最耗用伺服器資源

• Web伺服器叢集 
• 應用伺服器快取叢集
• 餘票查詢/計算叢集

5.售票高峰期訪問量振幅最大業務

• Web伺服器
• 應用快取伺服器
• 餘票查詢/計算伺服器

綜合以上的分析，餘票查詢/計算業務符合安全性考慮和售票高峰期訪問量振幅最大，最耗系統資源；其他適合放在公有云提供服務有三大伺服器叢集，Web伺服器叢集， 應用伺服器快取叢集， 和餘票查詢/計算叢集。

三、12306混合雲架構推測和解析

網際網路有一篇關於2015年春運12306使用者體驗報導，在此篇採訪提到12306網站採取5項措施，制定多套應急預案，以應對突發情況，來提高使用者體驗。

12306使用者體驗有改善，“為了保障春運期間正常訂票，12306網站建設了兩個生產中心。在中國鐵路總公司又增加了一套裝置。這樣就增加了一倍的網路內部處理能力……多建中心的同時，也增加了網路的頻寬，頻寬從5G擴容至12G。增加頻寬就等於我們多開了幾個門，能讓更多的使用者同時進來……還不只這些，我們在春運高峰期租了個”雲”……在網路高峰期間，12306網站的查詢量最大，佔到整個網站的85%，就把75%的查詢業務都放在租來的“雲”上…“春運高峰期的點選量、瀏覽量是平時的幾倍，甚至十幾倍。從經濟角度考慮，一個網站不太可能以最高峰值的承受力為標準來建設。我們只能在滿足日常需求與高峰期售票需求之間尋求一個最佳點，合理進行硬體配置。”現在雲技術成熟，高峰期租個雲用幾天，價格合理，安全也有保障。

有這些新裝置、新技術，今年的使用者體驗大為改善。據測算，今年12306網站的點選速度和頁面開啟速度比去年縮短了一半。

由上面對話透露的資訊，再以專業IT經驗來分析並推測12306 混合雲的架構設計。

1. 兩個生產中心和租了個“雲”：

兩個生產中心應該是指鐵路總公司資料中心和鐵科院資料中心，“雲”是指阿里雲

2. 75%的查詢業務都放在租來的“雲”上：

意謂著12306只將75%流量的查詢業務交給阿里雲託管，阿里雲只提供租賃查詢服務，不涉及任何系統功能的改造。

3. 兩地三中心 高可用性和容災設計：

以專業的IT來看，12306提供全國的網上售票服務，在系統設計上一定有高可用性和容災的設計。

Gemfire平臺已具備高可用性的設計， 所以，兩個生產中心一定執行整套業務流程服務，彼此作為異地容災備份的準備，而阿里雲只提供部分業務查詢的服務。

4. 業務連續性，應用不中斷，操作可持續的設計：

在2012年12月24號下午，由於空調裝置故障，12306中斷服務數小時。這可以看出12306是單資料中心的設計， 沒有考慮容災的設計。

為了吸取以前的經驗，假設12306已經考慮業務連續性，應用不中斷，操作可持續的設計，這意味著雙生產中心是需要並行作業提供服務；萬一有一個生產中心繫統出故障，可以在瞬間將流量導至執行良好的資料中心，保持服務的連續性。

5. 資料來源的傳輸和資料庫的複製：

過去資料來源的傳輸和資料庫的複製機制已經證明此技術是穩定和成熟的，所以會沿用以前的設計。

6. 阿里雲的餘票查詢業務託管：

在前一節已經詳述，考慮個人資料的敏感度和安全性，12306不會將這些資料放在阿里雲，但會將需要耗費巨大資源的餘票查詢業務放在阿里雲提供服務。另外符合此條件的有3大伺服器叢集，Web伺服器叢集， 應用伺服器快取叢集， 和餘票查詢/計算叢集。

綜合上述的分析，推測和描繪12306混合雲的架構如下圖：

12306 兩地三中心 混合雲架構

四、12306兩地三中心混合雲探討

12306兩地三中心的混合雲架構是目前國內規模最大，業務系統最複雜的混合雲服務。在12306承辦單位 - 鐵科院的領導下，經過精心的設計，部署和試執行，在2015年春運上線，它的表現是很令人矚目的。此混合雲設計的特點歸納如下：

1. 業務託管：

從整個購票流程來說，12306只是將部分流程的環節-“餘票查詢”業務交由阿里雲提供服務，並不是“整個系統”按需擴容的託管，這與一般企業的業務託管有最大的差異。如何將“業務子系統“剝離整個系統獨立作業， 再將資料結果傳回系統，協同作業，這需要從應用系統框架設計著手。

2. 敏感資料的存放和安全性：

12306是公共服務平臺，敏感性資料的保護和安全性是首要考慮因素。在混合雲設計上，12306將這些資料存放在私有云的資料中心， 確保資料安全無慮。

3. 業務連續性，應用不中斷的容災設計：

雙資料中心並行作業，不但可以分擔高負載執行，而且可以相互備份， 保證操作不間斷。

4. 資源動態擴充套件：

將“難預測，暫時性”的巨大訪問量-餘票查詢業務放在阿里雲，阿里雲可以按需動態調整網路頻寬和“虛機“資源，保證12306的服務品質，並解決網路傳輸瓶頸問題。

5. 關係型資料庫（SQL） 和非關係型資料庫（NoSQL）混合應用：

12306將熱點資料放在NoSQL的Gemfire平臺，提供快速查詢和計算；將關鍵資料持久化到關係型資料庫。

總體而言，目前12306混合雲架構是很合理的設計，求穩，求安全，又省錢。如果追求技術的完美性來說，有如下四點建議：

1. 提供同個車次不同車廂的聯程票 （例如，在同個車次， 北京到上海沒票， 但北京到天津， 天津到南京， 南京到上海有票），和 不同車次的聯程票 （中途站點換車），使旅客出行訂票更方便；
2. 思考“資料大集中”的模式，摒除路局和12306資料中心的資料交換，提高處理效率，且易於整個售票系統的維護；
3. 整合12306售票網站和線下作業系統（視窗購票，電話訂票，代售點），提供更快速的服務；
4. 大膽採用“軟體定義資料中心”的技術，可以做更靈活更快速資料中心的遷移/複製，為將來多資料中心混合雲的部署和服務（分散網路流量）或異地容災設計打基礎。

作者：劉雲程 （YC），技術總監，任職於資拓巨集宇（上海）公司，主要負責提供客戶應用系統升級, 遷移到高效能和高擴充套件性的“雲應用平臺”。 劉雲程畢業於臺灣清華大學，在美國拿計算機博士學位，於1994年由IBM外派到北京。他在IT行業有近30年工作經驗，曾任職於IBM中國研究中心負責電子商務和移 動網際網路方面的研究。