在互聯網從業者看來，12306購票網站問題的根源在于鐵道部自成一體的積習與互聯網開放透明的時代潮流之間的不兼容。盡管與“鐵老大”之間難有對接溝通渠道，“程序員”們還是自發成立了旨在優化和開發12306的開源項目。我們從項目中邀請數位專業人士，測評12306網站，并對“鐵老大”的互聯網表現做出分析和建議。
像修鐵路一樣建網站
洪水般兇猛的春運勢能推動下，作為“鐵路官方唯一購買火車票的網站”，12306確實承受了相當大的壓力——數據機構Hitwise披露，2013年1月19日，12306頁面瀏覽量（PV）達到1.2億，平均每個用戶瀏覽14個頁面，這意味著12306當日獨立訪客（UV）接近千萬，這樣的數據已經超過京東、去哪兒等網站。
在2012年的春運期間，全國數千萬用戶遇到了服務器宕機、支付故障、排隊時間冗長等一系列問題。有70%用戶反映無法在30分鐘內正常登錄網站，剩余的30%人中分別在查詢-選定-下單-支付這四步過程中隨機遇到服務器拒絕訪問、網站停止響應、當前用戶數過多的情況。
“問題的實質是傳統思維的鐵老大在進入互聯網的過程中準備不足。”某知名電商公司技術副總裁何然認為，12306遇到的首先是服務模式的挑戰：互聯網產品需要“小步快跑”式的微創新，首先快速推出業務占領市場空白，然后在最短時間內進行技術迭代，在此期間內以良好服務提升用戶體驗，降低流失，這是一個正常互聯網公司所應遵循的發展軌跡。
而12306的建設與修建一條鐵路的傳統模式沒有什么分別：承包方簽訂服務協議，完工后不再負責運營、維護及后續開發。這種模式本身就存在隱患，再加上春運期間的流量和訪問數遠遠超過想象，直接導致服務器故障。何然做了一個對比，“12306訪問峰值數據相當于淘寶的‘雙十一’活動期間數據量。為了實現穩定的數據庫結構，淘寶用了將近八年，而12306卻只有短短幾個月。”
缺乏中間層的設計硬傷
“程序開發中有一個堤壩理論：修建堤壩為了抵御大浪，一般會做幾層，一層比一層高，這樣可以分批次抵擋波浪。網站流量也是如此，層級越多，分流后壓力就越小，網站也就越安全。12306在設計上，缺少中間層的緩沖，前端用戶需求直接涌入最后端的數據庫，造成了一系列的故障。”
何然進一步解釋，如果按照大型商業網站的思路來設計12306，最底層的是車票池（集中式數據庫），對接傳統鐵路系統票務TRS（鐵路客票系統）和TBS（高鐵售票系統），“這部分是傳統業務，有多年的積淀，做得不錯”。
第二層是分布式數據庫。從集中式數據庫到分布式數據庫，其實就是從一個大車票池分流到很多小車票池。比如華北地區一個池，珠三角一個池，把不同的需求分散出去。
第三層是交易網關，主要是處理訂單信息及支付環節。并發式是這一層的主要特點，同時會有百萬級別的用戶進行在線交易。
第四層是安全層，起到防火墻的作用，用于過濾和清除黃牛刷票等惡意流量，及網絡攻擊防護，保障普通用戶的正常訪問。最上層是服務網關，基于這一層，可以搭建購票網站（12306）、安卓客戶端、iOS客戶端等，這一層也是直接對接用戶的。
第二層到第四層在開發中一般叫作引擎，而如果引擎的部分設計失誤或實現不完全，直接表現就是前端服務不穩定，容易發生出票故障、支付錯誤等問題。
“看起來之前12306的架構就是在第五層服務網關接受了用戶購票的請求后，直接推到底層的數據庫環節，缺少中間層引擎部分的緩沖和分流，這就使得集中式數據庫在瞬時大流量請求面前崩潰了。”
原始的前端水平
在架構之外，12306還存在一系列問題，包括至今仍未更改的簡陋界面。眾多網站的前端工程師在分析后均表示，這樣的前端水平實在過于原始，技術還停留在三四年前。
一系列12306的漏洞接二連三地被發現。比如有“技術宅”通過修改12306提交頁面的代碼，成功定到臥鋪下鋪（正常出票為隨機鋪位）；還有人寫出了提前20天以上購票的腳本；最終則出現了“購票助手”、“瀏覽器購票插件”這類工具。
“打開主頁要建60多個HTTP連接，現在的瀏覽器都是并發請求的，100萬用戶就是6000多萬個請求，太多了；首頁圖片共計700k左右，如果100萬用戶首次同時訪問，并在120秒之內返回，就要下載47Gbps的數據。如果網站能減肥，節約帶寬后訪問速度會大幅提升。”程序員“銀魂最高”建議。
軟件工程師趙會軍認為：“即使這個并發量做到足夠大，結果只能是所有票瞬間賣完，然后系統全天剩余時間無所事事。所以，首先要解決的是把購票時間規則改變，進行分散，然后才輪到解決并發量的問題。”
丁香園CTO馮大輝則建議使用通用的數字證書。“12306的數字證書是自己簽發的而非通用的，需要瀏覽器和其他應用來兼容，在某些瀏覽器上甚至根本無法使用，這顯然影響用戶體驗。”
這些建議部分已經被實現。比如今年的放票規則就已經修改為8至18時，除14時外每小時均有部分新票發售。自2013年1月7日開始（提前20天）發售春運客票至今，整個12306只有兩次時間不長的技術故障。結合數據庫的一系列改進，2013年絕大多數人的反饋不再是“登不上”，而是“買不到票”。
有限的網絡票源
買不到票當然并不只是因為客票有限的原因。在這個顯而易見的問題背后，隱藏著的是新老系統的對接問題。
12306并非一套獨立的購票系統。鐵道部原先用的是一套人工售票系統，12306是建立在這個系統之上的互聯網通用自助購票平臺，兩者共享同一個票池。這就引出一個最現實的問題，一列火車的所有客票，究竟有多少應該通過互聯網發售？
比如今年春運在“購票助手”出現后在互聯網上曾引發熱議：既然網絡客票提前20天發售而售票窗只提前18天，擁有“購票助手”對排隊買票的農民工是否公平？
通過了解整套購票系統，答案已經很明顯。但我們有理由相信在去年的春運時期，鐵道部由于首次設計客票方案，在兩者的比例上缺乏經驗，導致12306可買的票數實際上并沒有想象的那么多。
“從今年整體情況來看，12306及電話訂票的總出票數占到客票總量的30%至40%。這個比例比去年高一些，但我們不能因此認為這已經是最優方案。網絡渠道出票比例多大最合適，還要慢慢摸索”，一位鐵路系統的內部人士表示。
可以想見在今后很長一段時間內，這種網絡+人工售票雙軌并行的銷售方式不會改變，而這也就注定了無論你是使用360瀏覽器、購票助手軟件或是每天堅持自行點擊鼠標，你爭取的都只是本就為數不多的車票中比較小的那一部分。
至少在互聯網上做到開放和透明
雖然并不明白個中原理，但得知整個12306項目的中標金額合計在3億人民幣以上時，公眾還是發出了憤怒的聲音：3億就換來這么個玩意？
曾負責過大型資訊門戶和電商網站技術架構的何然坦言：“12306技術上的難度很大。3億的數字肯定含有水分，但差距并不像一般人所想象的那么大。”
例如把12306與淘寶對比：雖然“雙十一”活動期間淘寶總交易數1.06億筆，但淘寶商品實際上是靜態的，只需要做購買隊列，當排隊者超過商品數時即關閉購買，其間并不需要查詢數據庫。而12306的所有查詢都必須實時，尤其是同一條線路上當起點站的票狀態被確定時，沿途各站的車票狀態都會隨之變化，因此即使試圖做分布式數據，整條線路上所有支站狀態表加在一起也是一個相當大的數字。
“通過測算可以看出來，去年可用性太差了，今年技術和業務都有優化。”丁香園CTO馮大輝透露，2012年5月鐵道部邀請阿里巴巴等多家互聯網公司技術骨干，作為顧問向12306項目提建議，其中部分已被采納。
盡管能得到專業人士的理解，也有不小進步，但12306仍然被千夫所指。可以說，鐵道部建設網站的傳統方式即埋下隱患；在應對業界討論和公眾輿論方面仍然缺乏開放的姿態，則放大了問題。
例如2012年9月，何然看到很多程序員無法在12306訂購火車票，即牽頭成立了12306ng.org社區。該項目所有開發過程、開放文檔、源代碼都是開放的，所有互聯網公司都可免費調用（包括12306）。何然的想法是，12306開源項目能夠部分替代12306在線訂票或分發、處理數據，并且能與12306無縫切換。目前這一社區已經聚集了1萬多名開發者，也做出了一些相關的產品如瀏覽器搶票插件、手機客戶端等。
但何然表示前景并不樂觀：“離想象中還很遠，和鐵道部的溝通基本沒有；他們也沒有開放接口，我們走得很艱難。”
2012年，曾有網友提出鐵道部應當對12306進行公開招標，亦有人戲言應當讓淘寶接管這部分業務。而以鐵道部自成一體的特殊狀況來看，這些提議都缺乏可行性。但鐵道部若希望減少批評，降低輿論壓力，則應當公布網站建設資金去向，并在維護和后續開發上呈現互聯網時代所應有的開放姿態。至少在以開放和透明為時代潮流的互聯網上，“鐵老大”的前現代思維應該改一改了。 |
返回頂部