快要太監(jiān)了 :-(
由于各種個人原因, 鐵道部的這個博文系列中止了很久。最近終于連自己都不好意思了。所以還是繼續(xù)完成它吧，估計1-2周一篇的節(jié)奏。
感覺不先劃分一下大的系統(tǒng)架構(gòu)總會讓大家感覺有點頭暈, 不過沒能力對整個12306進(jìn)行設(shè)計，這個貨太大了。只是借這個機(jī)會談?wù)勛约簩ο到y(tǒng)結(jié)構(gòu)分析的一些感想
樸素的面向?qū)ο蠓治?/strong>
面向?qū)ο笫且粋€萬金油，但是據(jù)說真正懂的人不多是吧？
我對面向?qū)ο蟮母杏X就是: 他本質(zhì)上是對現(xiàn)實世界的抽象，其表面現(xiàn)象是不斷細(xì)分對象的粒度，提升對象的抽象度。最終形成一種用有限數(shù)量的獨立的對象“積木”構(gòu)造整個需求不斷變化的系統(tǒng)的目標(biāo)。
而系統(tǒng)級別的分析也大致如此，我們可以借鑒類分析中的很多概念，不斷劃小系統(tǒng)規(guī)模，剝離職責(zé)，抽出依賴性。
一般系統(tǒng)結(jié)構(gòu)
這里只是一個簡單模型，用以表達(dá)我對多數(shù)項目的結(jié)構(gòu)分析。
配置數(shù)據(jù)服務(wù)：系統(tǒng)運行所需要的動態(tài)配置信息
資產(chǎn)數(shù)據(jù)服務(wù)：所有實際或虛擬的“物”的管理（CRUD），甚至可以包括人。
業(yè)務(wù)數(shù)據(jù)服務(wù)：該企業(yè)實際經(jīng)營的業(yè)務(wù)產(chǎn)生的數(shù)據(jù)。超市的收銀記錄，企業(yè)的銷售記錄，鐵道部的售票記錄
報表數(shù)據(jù)服務(wù)：各類統(tǒng)計報表需要的
其中業(yè)務(wù)系統(tǒng)和業(yè)務(wù)數(shù)據(jù)服務(wù)應(yīng)該是最核心的部分。
一般而言，那些配置和資產(chǎn)管理的部分不會造成嚴(yán)重的性能問題。只要在實現(xiàn)CRUD的時候多考慮考慮相關(guān)的業(yè)務(wù)需求，努力做到任何資產(chǎn)的屬性變動時，確保相關(guān)的業(yè)務(wù)完整性就好（出租公司管理系統(tǒng)里，一輛出租車今天還在運營，后臺系統(tǒng)絕對不應(yīng)該可以輕松地把它標(biāo)記成報廢車輛，連軟刪除都是不合理的做法）。
12306之所以能招全國人民圍觀，我覺得主要還是花的錢和大家的感受之間有落差。而我陰暗的以為這個問題的核心部分就在票務(wù)處理的部分。
所以我后續(xù)的幾篇博文都會圍繞票務(wù)處理里面的內(nèi)容展開。
另外，我要大家了解的是，我是要設(shè)計一個合理的區(qū)間票售票系統(tǒng)核心。而不是實現(xiàn)鐵道部的需求。本質(zhì)上我認(rèn)為鐵道部不會說清楚他自己的需求，而太極公司的需求分析有可以進(jìn)一步深挖的可能。
12306核心需求及模塊分析
整體架構(gòu)沒法子設(shè)計，太大了。有興趣的可以參考
中國鐵路客票發(fā)售和預(yù)訂系統(tǒng)5_0版的研究與實現(xiàn)
國鐵路客票發(fā)售和預(yù)訂系統(tǒng)5.0版本(TRSv5.0)售票與經(jīng)由維護(hù)操作說明
目前我專注的是用于訂票的部分。我感覺這個是最重要的部分。
12306最大的問題，就是如何在訂票的時候高效率得并且適當(dāng)優(yōu)化得找到需要數(shù)量的車票。并且要能徹底保證一張票不會被兩個請求同時處理成功。
只要這個問題無法徹底解決，任何分布式處理，最終都會卡在這個問題上。
我會涉及到的模塊
12306票務(wù)處理功能模塊分析
假想完整網(wǎng)絡(luò)訂票流程圖
這里實際的用戶和系統(tǒng)的交互有4種類型。
1、車次和余額查詢
2、訂票
3、取消訂票
4、確認(rèn)訂票
這里希望廣大圍觀群眾都來評估一下這個假設(shè)的訂票流程及其參數(shù)是不是都合理？如果這個流程本身不合理，則我后續(xù)的分析都要重寫了。不熟悉售票流程的，可以看看我之前的分析文章。
然后我們繼續(xù)來細(xì)化一下
車次和余額查詢
輸入：起始站，終到站，日期，座位類型集合
輸出：車次，對應(yīng)座位類型可售余額
作用：最終用戶根據(jù)查詢結(jié)果選擇需要出行的車次，并進(jìn)一步進(jìn)入訂票操作。但是系統(tǒng)不保證顯示為有票的車次在下一步操作中必然有票。
這里其實涉及到兩個類型的查詢
1、哪些車次符合用戶的查詢結(jié)果，可以通過一個基本固定不變的數(shù)據(jù)源來提供。而該數(shù)據(jù)源可以實現(xiàn)分布式緩存以緩解查詢壓力，甚至可以考慮客戶端部分結(jié)果緩存。
輸入：起始站，終到站，日期
輸出 :車次列表，
2、特定車次，特定座位類型的可售票數(shù)量。這個數(shù)據(jù)的來源應(yīng)該和第一個查詢不同。
輸入：起始站，終到站，車次，日期
輸出：數(shù)量
訂票(我喜歡稱它為鎖票)
輸入：起始站，終到站，日期，座位類型，需要車票數(shù)量，用戶ID
輸出：實際到的獲取車票數(shù)量
作用：最終用戶通過訂票操作，順利鎖定需要數(shù)量的車票。系統(tǒng)保證用戶在規(guī)定的時間段內(nèi)對這幾張車票具有優(yōu)先訂購權(quán)利，且其他人不得購買這些車票。
目前我感覺留給用戶10-15分鐘時間繼續(xù)后續(xù)操作，以進(jìn)入支付環(huán)節(jié)（當(dāng)然，這必須是在系統(tǒng)本身性能良好條件下。否則點個按鈕就要等10分鐘，那就不對了。）
同時如果超時，則系統(tǒng)會在后續(xù)訂票操作中忽視該鎖定狀態(tài)。
取消訂票
輸入：起始站，終到站，日期，座位類型，數(shù)量，用戶ID
輸出：成功標(biāo)志
作用：用戶放棄已經(jīng)獲得的被鎖定的售票權(quán)利，系統(tǒng)恢復(fù)對應(yīng)的數(shù)據(jù)為可售。
確認(rèn)訂票（確認(rèn)支付）
輸入：起始站，終到站，日期，座位類型，數(shù)量，用戶ID，支付相關(guān)信息
輸出：成功標(biāo)志/確認(rèn)失?。▌偤面i定超時，且被他人訂走）
作用：最終確認(rèn)售票，系統(tǒng)向第三方支付服務(wù)提交確認(rèn)請求。
