面向?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)運(yùn)行所需要的動態(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)里,，一輛出租車今天還在運(yùn)營，后臺系統(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)請求,。