(轉)探討12306兩地三中心混合雲架構

前言

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

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

本文做者從互聯網收集大量有關12306的信息，首先描述12306系統與大型電商交易系統的主要差別和說明此差別爲什麼須要巨大的計算資源來支撐； 再進一步探討12306混合雲設計的考量 - 安全性和系統資源擴展性，並說明爲什麼只將「餘票查詢業務」放在阿里雲提供服務。最後以論證的方式「推測」12306兩地三中心的混合雲架構設計（有關12306混合雲的架構和解析是做者我的的推測，有誤解地方請求交流和指正）

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

1、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計算資源，同時必須快速反應餘票查詢的結果給用戶。在春運售票高峯期間，每分鐘都有數萬張車票的銷售，假如餘票查詢的響應時間緩慢，這些信息就失去價值，會發生看獲得票，但實際上買不到票的狀況發生。

2、12306 混合雲考慮因素和規劃

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

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

混合雲託管考慮因素

由上面的定義，混合雲服務模式應該是12306最佳的選項，能夠將「有計劃，難預測，暫時性」須要巨大資源的業務放在公有云提供服務。若是12306採用混合雲的服務模式，有哪些重要因素須要考慮？

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

混合雲的規劃——按需彈性擴展改造

，要解決12306面對「高流量，高併發「的難題是須要從軟件平臺和應用系統層面出發，要實現「可擴展的應用雲平臺架構」，靈活和快速熱部署的機制，纔是真正解決高併發訪問的根本。 12306承建單位-鐵科院在此方面作不少改進，使用Pivotal Gemfire內存數據管理平臺，從新設計和改造核心子系統，從用戶登陸，餘票計算，票價計算，實名身份認證，到訂單查詢；這些改造後的業務子系統都能支持「按需彈性擴展」， 再也不受限於原來關係型數據庫沒法作分佈式擴展的問題。這些一連串的改造，打通各個環節，實現「質」的大躍進， 也爲將來使用混合雲服務模式的架構打下良好的基礎。

信息安全和業務子系統託管的選擇原則

下列進一步探討如何選擇「業務子系統」放在公有云提供服務，主要有兩點考慮因素，一爲我的信息保護， 二爲須要「短暫」且強大計算機資源支持的子系統業務。

1. 購票流程和我的信息：

• 登陸：含我的信息
• 餘票查詢/計算：不含我的信息
• 訂單確認和訂單查詢：含購票人信息和身份確認
• 付款：含我的的支付信息

2. 主要服務器集羣和我的信息：

• Web服務器 - 不含我的信息
• 應用服務器緩存服務器 - 不含我的信息
• 登陸服務器 - 含我的信息
• 餘票查詢/計算服務器- 不含我的信息
• 訂單確認和訂單查詢服務器 - 含我的信息
• 實名制身份確認服務器 - 含我的信息
• …

3. 最耗用網絡資源

• Web服務器
• 應用服務器緩存服務器
• 餘票查詢/計算服務器

4. 最耗用服務器資源

• Web服務器集羣 
• 應用服務器緩存集羣
• 餘票查詢/計算集羣

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

• Web服務器
• 應用緩存服務器
• 餘票查詢/計算服務器

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

3、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 兩地三中心 混合雲架構

4、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. 大膽採用「軟件定義數據中心」的技術，能夠作更靈活更快速數據中心的遷移/複製，爲未來多數據中心混合雲的部署和服務（分散網絡流量）或異地容災設計打基礎。