上節，對12306。cn有了一個很好的鋪墊，這節我們來討論，架構的具體問題
署接上文
於是，在網上紛紛對本系統產生了各種各樣的討論，有的說是系統設計問題、有的說是系統帶寬不足、有的說明系統設計時有失公平（競標）、有的說付了款卻沒了票、有的說是需要用“雲計算{技術}”才能解決等等。不管怎么樣，重新架構或進行重大調整是必然的。個人覺得雲計算只不過是一種資源或信息服務方式，它也需要更好的系統的架構和穩健的系統才能提供這種服務方式，所以通過“雲計算”並不能解決本系統的超大規模的訪問的承載，相反更應該從系統架構方面來重拾系統的穩健和可擴展性。
目前12306.cn最高日訪問量達14.09億次，最高日訂票量為166萬筆。顯示出本系統的高訪問量和事務密集。個人認為14億次訪問量與系統幾乎處於癱瘓狀態有關，因為用戶一旦進行操作失敗並會重復訪問，因此如果系統運行穩定和可以正常服務后日訪問量將大幅減少（據Aleax不完全統計7天訪問本系統的用戶是全球互聯網用戶的0.902%，按全球用戶為22億計算，大約為：0.1984億，所以每日的訪問獨立人數平均為0.1984億/7=285萬人，因此日訪問量14億更多的是來源於操作不成功的用戶重復訪問所至）。
初步分析可以肯定，12306.cn之所以無法正常提供服務和進行實時處理，其最可能的影響因素主要有：系統架構不合理、余票查詢處理不當（此項業務訪問量是本系統最大的訪問量）、火車時刻查詢處理系統、訂票/支付系統集中（這是導致付款不成功的主要因素）、互聯網與鐵路網接入等問題。
本文將從系統業務流程、系統架構、高並發量分流方案、余票駁借、孤島計算模式等方面提出一種全新的火車票訂票系統解決方案。
本方案假設與目標
假設：
系統域名為：hcpxxxxxx.cn；
原有客票系統已經穩定，可向網絡訂票提供正常的服務；
不考慮櫃台與電話訂票。
目標：
日最高訂票量500萬張（按目前網絡訂票系統工作18小時算，每秒處理訂單量為78張）；
高鋒時每秒處理訂票：5000張；
日PV（頁面點擊量）：20億次；
系統的基本業務流程
系統余票信息查詢
火車時刻查詢
火車票基本訂票流程
其中“輸入乘客信息，訂票數量進行訂票”的過程如下：向客票系統查詢實時余票——>若有余票——>鎖訂所訂票數——>出票，否則不成功。
系統總體架構
為了實現超大訪問和實時處理系統，系統基本架構如下圖所示：
DNS分流
DNS分流是建立高吞吐量系統的第一步，特別是在中國，由於南北互通問題，通過DNS分流可以把南北用戶自動分配到南北各自的網絡中。DNS分流已經有成熟的技術和軟件，因此這里不再詳細描述。
DNS分流主要目的是把客流引入到不同的WEB前端服務器，通過DNS分流可以實現客流的一級分流，比如分別在電信和網通放置5台前端WEB轉發（消息路由）服務器，則南北用戶將自動由DNS分流引入到這些服務器中。一般大型的WEB系統不會在前端WEB服務器中部署應用，因為這樣是不可能達到高並發請求的，而是把前端WEB服務器作為消息路由服務器，把用戶請求按業務類型或是其它算法把客戶分流引入更多的服務器機群中，大概結構如圖所示：
前端WEB轉發（消息路由）服務器
前端WEB服務器在高訪問量的系統中顯然不能作為應用服務器，因此前端WEB應該作為高速穿透性請求轉發器，由這些轉發器把用戶的請求高速地分流到后端不同的應用和服務器集群中。WEB服務器不僅為請求分發系統，同時也是負載分發系統、業務分發系統，但均不需要進行軟件開發、只是部署而已。
前端WEB服務器與DNS分流共同組成整個系統的分流、負載均衡入口。
把好動靜態數據關、采用孤島計算模式
大型內容發布系統、商品系統無不把信息生成靜態HTML或靜態數據，這樣可以極大地緩解后端應用服務器和數據庫的壓力。
可以這樣設想，有多少人訪問系統就有多少計算機參與到整個系統的計算。顯然服務器端占了計算的主要部分，那么是否可以讓這些使用者的計算機也參與到整個系統中來，而並非僅僅是瀏覽呢？答案是肯定的。同時對於大訪問量的系統來說更應該讓訪問者的計算機參與進來。采用訪問者的計算機參與計算的模式，我把它叫“孤島計算模式”，它只負責當前訪問者相關的計算，這樣就不會與服務器和其它訪問者構成相互影響的關系。因此把一些互不相關、計算量頻繁，而數據量又不大的系統安排給訪問者的計算機來計算是設計超大型訪問量的系統的一個必然選擇，這樣可以充分利用訪問者計算機的閑置資源。
那么在本系統中有哪些資源可以由訪問者的計算機來計算呢？顯然有很多，比如時刻表查詢、站名查詢、轉程查詢、余票查詢的站名處理等信息。那么有人會問這不就需要把這些數據都下載到客戶端嗎？答案是否定的，系統應該采用按需計算模式，把用戶需要的數據下載到客戶端即可。比如用要查詢K112次列車的信息，那么就不需要下載T88次列車的信息。
為了適應客戶端高速計算，處理掉服務器中的信息從數據庫中直接查詢也是必然的，大量信息可以生成XML數據或是HTML靜態數據，比如時刻表、車站、車次等信息均可以生成靜態的XML數據，這樣可以把服務器的CPU時間安排給更需要的業務系統或是分拆給不同的業務系統。
同時，通過大量資源的靜態化處理和分離式計算，可以提高CDN的效率。
業務系統分流
除了系統整體部署和硬件架構外，系統的業務分開處理，也是一個大型系統必須進行的。基於火車票訂票系統的幾個基本流程，大概可以分以下幾個子業務系統：
用戶注冊
使用獨立的服務器和通道提交注冊信息和資料（比如：user.hcpxxxxxx.cn）。
用戶登錄驗證
登錄驗證是用戶進入系統的第一道關，因此它的訪問量也相對較大，應該使用獨立的通道（同時需要采用負載均衡），比如使用：login.hcpxxxxxx.cn 專門處理用戶登錄。
余票信息查詢（比如使用：q.hcpxxxxxx.cn）
余票信息查詢應該是整個系統請求量最大的一個業務系統，目前系統采用30分鍾更新余票信息，這樣做不僅不合理（不具有實時性），更增加了系統的壓力。
建議采用余票駁借措施來處理系統，所謂余票駁借，即從總的客票系統中一次性借入一定比例（比如20%）的票量到網絡訂票系統中，並建立具有負載均衡的高速動態緩存服務器來查詢余票。采用余票駁借可以提供訂票的速度。
比如某日票量為500萬張，由系統駁借20%即100萬張進入網絡售票系統，那么這100萬張在客票系統看來已經被訂出。因此在網絡售票系統中產生的訂單和出票不需要再與客票系統進行交互，而是由后端的處理系統定時或是實時地把成功出票的訂單更新到客票系統，這樣可以大大提供系統的訂單處理吞吐量，同時也可以排除與客票系統高並發請求的壓力風險。
在經過一定的時間或是客票系統售完后可以把駁借出來的票回收到客票系統中，或是網絡票售完后再從客票系統中駁借票。這樣與客票系統的交互請求量將不再存在壓力。所以客票駁借是雙向的。可以由專門的服務器來完成操作。以達到網絡系統是真正的實時系統。
駁借方式可以由專門的系統來管理策略並監控各系統的售票情況，以便可以相互駁借。
訂票系統(book.hcpxxxxxx.cn)
在采用余票駁借的情況下，訂票系統顯示格外輕松，它的購票過程更加簡便，不需要在購票提交時進入原有客票系統鎖定余票，而是僅需要駁借的這一部分中出票即可。
那么所有網絡出票的信息如何返回到鐵路系統中去呢？這變得很簡單，只需要更新駁借的票的身份信息即可（即由誰訂了駁借的票），並且可由一兩台服務器在后端進行處理。
由於訂票量大，所以訂票系統需要采用分布式架構和車次分流架構（車次分流可參考相關章節）。分布式架構可采用形式較多，比如按車次分流后各自獨立數據庫，在訂票產生后由后端的服務器來歸並計算訂票情況。
支付回饋系統(payback.hcpxxxxxx.cn)
支付系統本應該是一個最簡單的系統，但是由於支付后銀行的系統需要回饋訂票系統某訂單支付是否成功，這也給訂票系統產生了壓力。那么對回饋系統構建獨立架構也是必不可少的，否則回饋不成功，則系統認為沒有支付，就產生了目前付了款，但沒了票的情況。支付流程大概如下圖所示，顯然現有系統在支付回饋中出了問題，歸根到底還是訂票系統崩潰或是無法響應所至。但相對於整個系統來說支付回饋的請求量遠少於余票查詢系統的訪問
短信確認系統
短信確認系統由訂票系統使用，因此不存在請求上太大的壓力，但是構建短信隊列是必要的。並且實時性要求並不高。
以下信息並非高訪問量的系統可以構建完全的靜態和客戶端計算模式的系統。
火車時刻查詢
正晚點查詢
客票代售點查詢
鐵路轉程查詢
火車車次分流
由於火車車次間相對獨立性，因此使用基於車次進行分流是一種可行的措施。比如：T1~T1000采用A服務器、D1~D100采用B服務器，這樣來進行分流。由客戶端（用戶計算機）來決定使用哪一個服務器提供服務。這樣在訂票時對服務器的壓力可以大大減少，同時可以無限制的擴展服務器以實現無限的分流。
比如可以這樣安排服務器：
T1~T1000訂票自動轉發到：t1_t1000.hcpxxxxxx.cn。
D1~D100訂票自動轉發到：d1_d100.hcpxxxxxx.cn。
這樣的決定並不需要服務器來計算，而是由訪問者的計算機在網頁中就可以決定。即在什么服務器上進行出票。
僅增加帶寬並不能解決本系統的高吞吐量
總結 個人覺得帶寬絕對不是本系統訪問緩慢的原因，而是后端的數據庫、應用服務器響應緩慢所至（因出錯后有比如系統忙的提示或是由CDN返回的超時錯誤）。
但具有較高的帶寬也是建立高吞吐量系統的重要因素之一。
應用高速緩存快速響應