1月16日，網絡問答社區知乎上一名阿里云工程師爆料，12306網站已將車票查詢業務放到阿里云上。該工程師表示其曾參與過12306春運項目，認為雙11在業務規模上更有挑戰，而12306則在業務復雜度上更高。

文中詳細介紹了12306使用云計算的一些技術細節。內容如下，部分有刪減：

鐵路運營是一個龐大的社會工程，每年春運，相當于把全國人口“搓一圈麻將”。事實上，在互聯網售票之前，網點售票已經實施多年。換句話說，鐵路售票實際上一直有一個相當龐大且復雜的、跨多個路局的信息系統在支撐，而且可以追溯到80或90年代，維護至今。這個系統也許不僅支持了售票，可能還包括調度等核心業務。那這里就有一個問題：在做互聯網售票的時候，是否要重構一下原有的系統呢?

這個問題值得反復掂量。大家應該知道，徹底重構一個運行數十年的系統的開銷和風險吧，粗略一想涉及到各種業務邏輯、軟硬件供應商、版本與維護協議等等。

絕大多數的互聯網技術同僚應該會傾向于在現有系統上做web前端，先讓系統“用起來”，然后再集中技術力量逐步優化整套系統架構。這也是當時12306的選擇，這就導致有很多歷史的包袱，還要考慮線下售票系統。

知乎上很多人拿春運售票和我廠(阿里)雙11比較，究竟哪個牛逼?個人感覺兩者同屬于重量級的網站業務，雙11在業務規模上更有挑戰，而12306則在業務復雜度上更高。

火車票跟很多票(包括淘寶天貓的商品、機票、體育場館門票等)有不一樣的屬性。比如，從北京到廣州，沿途有多個站點，理論上乘客可以選擇任意 一段區間購票，所以每買一張區間票，可能同時裂變出多張區間票。這個邏輯比大多數電子商務系統要復雜的多。假如說要再添加一些更人性化的feature，比如根據訂票者身份證里的年齡優選上下鋪、優選號等，那么查詢和出票邏輯就更復雜了。

在一個后端上，setup一個web前端(包括入口、安全、緩存和邏輯，非指web頁)，這個挑戰也是巨大的。因為這個前端很容易瞬間脹大， 甚至被撐爆。“撐爆”的概念不難理解，奧運會的訂票高峰，中美海底光纜擁塞，包括杰克遜去世后瞬Google癱瘓，或者DDoS拒絕服務攻擊，都是這種現象。

根據官方公布的數字，有人統計了一下：需要數千個pv，才能出一張票。這個說法并不能得出“出票效率低”的結論，但是恰恰很形象的說明了查詢量的巨大。

天量的火車票查詢是影響12306性能的重要原因之一，大概占了90%以上的訪問流量。更棘手的是：峰谷的查詢有天壤之別，幾乎沒有辦法在成本和并發能力之間做一個好的平衡。以往的一個做法是從幾個關鍵入口流量控制，保障系統可用性，但是會影響用戶體驗。

淘寶/天貓大促的時候，也會增加服務器，阿里的業務盤子大，這些新增的機器很快會被其他業務(包括阿里云)消化掉，可能還不夠。但是對于 12306來說，就比較難做到這一點。

這成為今年12306與阿里云合作的一個契機：通過云的彈性和“按量付費”的計量方式，來支持巨量的查詢業務，把架構中比較“重”(高消耗、低周轉)的部分 放在云上。這是一個充分利用云計算彈性的絕好實例，也是在系統架構上做“輕重分離”的一個典型case，把小而精的核心業務系統保持不動，把 “傻大笨粗”(非貶義)的系統遷移到云計算上。

今年初我們和12306的技術團隊開始討論如何將余票查詢系統放到云上，十一黃金周做了測試效果不錯，到春運12306決定將75%的余票查詢業務放到云上。

做這個項目一晃有小半年了，感觸很多。大家知道雙11對阿里技術團隊是一個不小的挑戰，我參加了4年，其中有兩年過的尤為艱苦。當時技術團隊經常被業務方指責，就像現在大家對待12306的態度一樣。但客觀說，雙11大促推動了阿里的技術成熟，春運也推動了12306采用更多面向未來的技術。

為什么是余票查詢?

1. 訪問量巨大，占12306整個網站流量的90%以上，業務高峰期并發請求密集，性能要求是整個業務系統中最為重要的一環;

2. 與其他業務在邏輯上相對獨立，使用云計算的話不需要對整個網站的業務架構做改造。

實施過程可否透露?(隱去部分敏感信息，請理解)：

1. 把余票查詢模塊和12306現有系統做分離，具備獨立部署的能力;

2. 在云上獨立部署一套余票查詢系統。這樣子12306和云上都有了一套余票查詢系統，，調度更為靈活;

3. 一些安全措施,吧啦吧啦吧啦……

根據運行情況，云上的余票查詢與12306原來的余票查詢可以互相補位，根據實時的負載情況，來調配不同的訪問比例，充分利用云的彈性。

云計算跟“堆硬件”有什么區別?

這里主要是"春運 vs 平時"、"業務量 vs 成本"的問題：

1. 傳統IT方案，為應對春運的業務壓力，需要按照峰值采購大量硬件設備，從規劃、建設到投產、服務整個供應鏈條長成本高，capex和opex上的投入都比較大，很難精確把控，而春運后大量設備會處于空閑狀態，利用率低，造成巨大的浪費。

2. 還有至關重要一點是，假如按照傳統方案，在實際業務峰值超出了初始評估量時，服務將面臨無法完全承載而癱瘓，因為為大規模服務器的采購、交付、部署到應用上線所耗費時間以月計，根本無法在業務量激增時"即插即用"。

3. 云本身就比自己買硬件要便宜，另外所有資源都是“按量計費”，從十一黃金周到春運的過程里，12306在云上做了兩次大型擴容，每次擴容的資源交付都是在分鐘級就完成。業務高峰結束后，可以釋放掉不必要的資源，回收成本。