阿里巴巴與12306關系大曝光：馬云已派阿里云頂尖程序員隊伍入駐12306

【IT時代網、IT時代周刊編者按】1月15日下午，有一位自稱是阿里云的程序員在著名的問答社區知乎上面爆料，12306網站已將車票查詢業務放到阿里云計算平臺上，幫助12306平穩渡過春運購票高峰。該用戶聲稱為阿里程序員，曾參與12306春運項目。據該名程序員透露，2014年初雙方團隊就已開始討論如何將余票查詢系統放到云上。十一黃金周期間進行了測試，效果非常滿意。在春運售票高峰，12306最終將75%的余票查詢業務切換到了阿里云上。

不邀自來，果斷匿名。

利益聲明：阿里云程序員，今年12306春運項目幕后碼農。

僅代表個人，嘗試從技術的角度對12306做一些抽象的歸納，包括12306與云計算的技術相容性，對項目談一些感受。不涉及具體數字和系統架構細節，對鐵路業務運營不做評論。

先亮明基本觀點，不喜請繞路：

1.從技術上看，不是說做好了阿里雙11就能做好12306

2.12306的亮相是慘了點，但這兩年一直在改進

3.12306一直在嘗試引入外部技術力量解決問題，租用公有云算其一吧

=============================

我初次使用12306是到北京旅游，返程票是在12306預定的。當時是拿到一個訂票號碼之后再去西直門付款取票。客觀來說，這兩三年12306的便捷程度已經有很大提升。

每年春運，12306都會被推到風口浪尖上，也不斷有“高人”放出豪言壯語，可以非常迅速而廉價的開發一個新的 12306出來。我記得大約4年前招聘工程師的時候，也經常遇到有人斷言可以3個月內開發一個完整的淘寶系統。對于這種口炮黨，我只能說：呵呵。。。

鐵路運營是一個龐大的社會工程，每年春運，相當于把全國人口“搓一圈麻將”，如果在這個節點去網點排隊買票，相信絕對是一件讓所有人頭疼的事情，這不僅是用戶體驗差的問題，同時也是對社會資源的巨大消耗。

收一下，回到技術層面——

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

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

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

==============================

知乎上很多人拿春運售票和我廠雙11比較，究竟哪個牛逼？

個人感覺兩者同屬于重量級的網站業務，雙11在業務規模上更有挑戰，而12306則在業務復雜度上更高。

火車票跟很多票（包括淘寶天貓的商品、機票、體育場館門票等）有不一樣的屬性。比如，從北京到廣州，沿途有多個站點，理論上乘客可以選擇任意一段區間購票，所以每買一張區間票，可能同時裂變出多張區間票。這個邏輯比大多數電子商務系統要復雜的多。關于這一點，這里有一個更夸張的分析，有興趣請參看：

從嗤之以鼻到“奇跡” 前淘寶工程師詳解12306技術。

購票差異還不僅限與此。假如說要再添加一些更人性化的feature，比如根據訂票者身份證里的年齡優選上下鋪、優選號等，那么查詢和出票邏輯就更復雜了。

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

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

為什么12306查詢量會這么大呢？因為淘寶的秒殺搶不到就算了，運氣不好下次再來過；火車票的購票心理則不同，“求之不得，夢寐思服”，特別是高峰期的票。而買到票的人也不一定滿意現在的車次、時間。總之，就是一個字：刷！刷！刷！

當然各種搶票工具的泛濫，也是讓查詢量猛增的原因之一。不過，從另一個角度看，能讓這些工具都被用戶用起來，這也證明了系統處理能力的大幅提升。

===洗====地===結====束=====

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

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

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

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

同意@xLight 的說法，云計算不是萬能的，12306的業務系統很復雜。目前我們能看到的是，在提升余票查詢能力方面，云計算可以快速部署應用提供服務，通過分鐘級的擴容操作，實現十倍、百倍的服務能力擴展。

==============================

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

最后引述一段12306工程師回顧系統剛上線時說的話：

12306是個互聯網新人，又或者被稱為“富二代“，它長得很丑，也很傻很瓜，身體還很弱…所以第一次露臉它就演砸了，那天全中國互聯網大佬和網民都盯著它看，基本上全中國的網友都涌入它的家。那天它宕機了，同樣是那天罵聲如潮……其實我們知道，他們罵的不是12306，他們罵的是這個時代。

=============================

回答幾個問題：

為什么是余票查詢？

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

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

實施過程可否透露？（隱去部分敏感信息，請理解）：

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

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

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

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

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

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

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

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

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

【IT時代網、IT時代周刊編后】據了解，作為阿里巴巴集團的核心技術平臺，目前阿里云計算運營的“飛天”集群服務器規模已達到了5000臺。據悉，2014年初雙方團隊就已開始討論如何將余票查詢系統放到云上。十一黃金周期間進行了測試，效果非常滿意。在春運售票高峰，12306最終將75%的余票查詢業務切換到了阿里云上。對此，阿里云回應稱，確實已經達成合作，具體細節會適時公布。【責任編輯/李響】

來源：IT時代網

IT時代網(關注微信公眾號ITtime2000，定時推送，互動有福利驚喜)所有原創文章版權所有，未經授權，轉載必究。
創客100創投基金成立于2015年，直通硅谷，專注于TMT領域早期項目投資。LP均來自政府、互聯網IT、傳媒知名企業和個人。創客100創投基金對IT、通信、互聯網、IP等有著自己獨特眼光和豐富的資源。決策快、投資快是創客100基金最顯著的特點。

相關文章

阿里巴巴與12306關系大曝光：馬云已派阿里云頂尖程序員隊伍入駐12306