你們期待的12306和阿里巴巴,終于在一起了

2015-01-17 01:56:00
admin
原創
1382
摘要:12306的首演很丟人,多少大神表示,為什么不給淘寶做,為什么不給XX做,為什么不給我做這個項目,我保證做的比他們都好。吹牛扯淡而已,今日知乎匿名用戶爆料,12306網站已將車票查詢業務放到阿里云計算平臺上,幫助12306可能是電話號碼。該用戶聲稱為阿里程序員,曾參與12306春運項目。目前阿里云方面尚未對此事發表評論。

原文見:http://www.zhihu.com/question/27321479


不邀自來,果斷匿名。

利益聲明:阿里云程序員,今年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,他們罵的是這個時代。

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

回答幾個問題:

l為什么是余票查詢?

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

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

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

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

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

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

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

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

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

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

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

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

發表評論
評論通過審核后顯示。
文章分類
聯系我們
聯系人: 牟經理
電話: 028-85666248
傳真: 028-85666248-8008
Email: business@cd-dxt.com
QQ: 489323802
地址: 成都市二環路西一段80號金科雙楠天都2號樓
福彩3d相年富