寫在開頭的話：技術總是在不斷質疑中進步（改編自：質疑是科學研究不斷前進的動力）
1、2、
lvs+nginx 這套架構是普遍流行的，成熟的架構，變種有：f5+nginx， 個人覺得f5+nginx比lvs+nginx好，因為硬體分流比軟體更穩定，效能更高。其實lvs+nginx是我們這種小成本**用的。
訂單流程的核心是資料庫的效能，12306用的是記憶體資料庫，效能應該已經提公升到了極致。
架構圖中前置了mq訊息佇列，這應該是削峰作用，防止資料庫崩潰的手段，日常應該沒有太多作用；mq是非同步的，會產生資料庫的事務問題，因此架構裡面著重要解釋如何解決一致性的問題。
文中解釋mq屬於業務定製的快取，也就是mq會彙總請求，統一進行訂單處理，只把結果寫入資料庫中。因此mq屬於乙個超級業務快取，只把結果存入資料庫中，這樣就解決了一致性的問題。同時文中還進行了延申說明，mq是可以並行部署的，沒有效能問題。
現在看起來這個架構是一套高效能的成熟的架構，除了一些微小的無關痛癢的瑕疵。
文中並沒有對查票業務進行說明，我個人認為查票業務應該比這個部分重要，理由有兩點：1、大部分使用者會反覆查票，查票的效能要求更高，更能給使用者好的體驗；2、中介機構的刷票業務才是影響效能的重點，也是常常造成崩潰的原因。
查票裡面的難點是需要進行路線計算，這個過程可以分為兩個步驟：首先查詢出路線，其次需要和座位數量匹配，篩選出有效的路線。從目前使用看來，這個部分效能還不夠，應該是業務的分離程度不夠的原因。
最後總結：這個架構裡面不清晰的兩個地方，mq和查票兩個模組，大部分業務都在這裡，應該著重設計細化的地方。個人覺得查票是非常影響使用者體驗的，官方應該繼續努力把這個模組優化好。
查票業務有乙個核心就是狀態傳遞是單向的，不需要設計鎖來實現狀態的更新，因此查票業務是可以做到效能極高，再配合ip反刷票機制，系統不會崩潰。
如果我是12306架構師
12306，因為系統問題，成了it業界內大家茶餘飯後經常談論的話題。先分享乙個真實故事，我同事看了12306這個 他說，這個 做下來只要5萬，我反駁，被他嘲笑。笑話終歸笑話，沒有諷刺鐵道部，以及12306研發方的意思，我同事是實習生，他不懂12306。近日，我們在乙個技術群裡討論了乙個開放式話題 如...
1 架構的開悟
軟體架構 有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。通常說架構是一種能力，架構角色則是要求你在具體事務中行使某些行為，而架構師則是用來標識這些能力與行為的乙個職務。通常我們大多數人都具有架構的能力，並且也或多或少地行使架構師可能會有的行為，但是可能還沒有 架構師 這個頭銜...
1 架構的概念
涉及到的內容包括 系統與子系統 模組與元件 框架與架構 系統與子系統 系統泛指由一群有關聯的個體組成，根據某種規則運作，能完成個別元件不能單獨完成的工作的群體。它的意思是 總體 整體 或 聯盟 子系統也是由一群有關聯的個體所組成的系統，多半會是更大系統中的一部分。模組與元件 從邏輯的角度來拆分系統後...