序言：? 此文的撰寫始于國慶期間，當(dāng)中由于工作過于繁忙而不斷終止撰寫，最近在設(shè)計(jì)另一個(gè)電商平臺(tái)時(shí)再次萌發(fā)了完善此文并且發(fā)布此文的想法，期望自己的綿薄之力能夠給予各位同行一些火花，共同推進(jìn)國內(nèi)的大型在線交易系統(tǒng)的研發(fā)工作，本文更多地站在軟件工程角度來看待整個(gè)問題，有關(guān)后續(xù)的技術(shù)問題研究，將在另外的博文中予以探討。

?? 一年一度的國慶大假剛落下帷幕，由于這次長假是歷史上最長的一次，因此出行問題備受關(guān)注，而鐵路出行作為最主要的出行方式更是大家討論的熱點(diǎn)，老生常談的購票難問題又被提起。這幾天我在網(wǎng)站上也看到很多關(guān)于12306.cn的討論，很多網(wǎng)友都發(fā)表了自己對(duì)于鐵道部購票網(wǎng)站的不滿，更有很多同行討論了關(guān)于12306網(wǎng)站的設(shè)計(jì)問題，期待能夠貢獻(xiàn)自己的綿薄之力，我仔細(xì)拜讀了其中至少10篇文章，很多同行多是站在技術(shù)的角度來考慮，其中不乏很多有創(chuàng)意的想法，純粹的技術(shù)設(shè)計(jì)能解決一些問題，不過似乎不能夠全面地解決這個(gè)龐大的、堪稱瞬間流量“世界第一”的實(shí)時(shí)交易網(wǎng)站，目前12306的問題與其說是一個(gè)技術(shù)問題，還不如說它是個(gè)軟件工程問題，道理非常簡單，請(qǐng)看如下的新聞報(bào)導(dǎo)：

??????? [[[回望12306網(wǎng)站在2011年12月底以來的表現(xiàn)，鐵道部高層也直呼想不到。 ?
?? ?鐵道部副部長胡亞東介紹，今年第一次在全國鐵路實(shí)行網(wǎng)絡(luò)電話訂票，截至1月8日已經(jīng)達(dá)到每天200萬張，12306網(wǎng)站的注冊(cè)用戶已超過1000萬人。1月1日至7日，“12306”網(wǎng)站日均點(diǎn)擊次數(shù)已經(jīng)超過了10億次，專家認(rèn)為瞬間點(diǎn)擊可能達(dá)到了“世界第一”。 ?
? ?? ?高度的關(guān)注、巨大的訪問量，導(dǎo)致12306網(wǎng)站頻繁出現(xiàn)系統(tǒng)崩潰、無法登陸、無法支付等情況。 ?
? ?? ?“像春運(yùn)這樣龐大的需求量，難道鐵道部沒有預(yù)想到并有所準(zhǔn)備？”隆梅資本管理有限公司副總經(jīng)理馬宏興對(duì)此困惑不解。 ?
?? ?在探究12306網(wǎng)站問題的深層原因以及解決之道時(shí)，各家看法不同，“12306網(wǎng)站的問題最終還是系統(tǒng)架構(gòu)的問題。因?yàn)橛脩粲写罅康膭?dòng)態(tài)、交互式訪問，所有的請(qǐng)求都會(huì)發(fā)送到12306網(wǎng)站的服務(wù)器端，同時(shí)在線并發(fā)用戶數(shù)量太多，導(dǎo)致網(wǎng)站無力承載，造成擁堵。”華南師范大學(xué)計(jì)算機(jī)學(xué)院副院長單志龍認(rèn)為。 ?
??????? 又有說法認(rèn)為，如果給12306網(wǎng)站增加服務(wù)器和帶寬，也能夠緩解擁堵的癥狀。這一觀點(diǎn)鐵道部內(nèi)部頗為認(rèn)同。 ?
?? ?“得承認(rèn)，我們對(duì)訪問量估計(jì)得不足。”鐵道部信息技術(shù)中心一位中層向記者透露，12306網(wǎng)站曾在2011年春運(yùn)期間試運(yùn)行，高峰時(shí)段訪問量約在1億點(diǎn)擊量，因此，信息中心估計(jì)2012年春運(yùn)期間的訪問量約在3億至4億。 ?
?? ?但是，結(jié)果卻大大出乎人們的預(yù)料。“12306”網(wǎng)站在1月9日的日點(diǎn)擊量達(dá)到14億次，是原來料想峰值的5倍之多。“崩潰”在所難免！]]]

筆者連日來也萌發(fā)了一個(gè)想法，假如讓我來設(shè)計(jì)12306網(wǎng)站，我作為總架構(gòu)師，該當(dāng)如何考慮呢？自己雖然經(jīng)歷過眾多的大項(xiàng)目的全生命周期跟蹤管理，對(duì)于軟件工程應(yīng)該是有一定的研究，但像如此巨型項(xiàng)目，應(yīng)該如何來設(shè)計(jì)、管控與實(shí)施？ 確實(shí)也頗傷腦筋，下面就筆者根據(jù)自己多年根植于IT研發(fā)的經(jīng)驗(yàn)，特別是近年來對(duì)于巨型網(wǎng)站譬如國內(nèi)的淘寶、京東等，國外的Facebook、Google等的跟蹤研究經(jīng)驗(yàn)談?wù)勛约旱目捶ā?

1. 需求分析階段
需求分析是至關(guān)重要的，對(duì)于12306而言，需求分析的重點(diǎn)應(yīng)該需要得出如下方面的關(guān)鍵數(shù)據(jù)才算需求分析基本結(jié)束：
終端用戶方面的：
訪問用戶數(shù)量、總體注冊(cè)用戶數(shù)量、平時(shí)訪問用戶的峰值、平時(shí)訪問用戶的谷值、大假期訪問用戶的峰值、大假期訪問用戶的谷值、小假期訪問用戶的峰值、小假期訪問用戶的谷值；
用戶的地域分布性、用戶可能介入的設(shè)備、用戶接入的網(wǎng)絡(luò)狀況統(tǒng)計(jì)分析；
后臺(tái)服務(wù)方面的：
關(guān)鍵購票流程業(yè)務(wù)分析：
購票的基本流程分析、一次購票的TPS數(shù)量分析、一次購票的用戶流量分析、一次購票的用戶靜態(tài)流量分析、一次購票的用戶動(dòng)態(tài)流量分析；
這其中又分為初次購票與再次購票兩種情況，流程稍微有些不同；
系統(tǒng)提供的其他服務(wù)統(tǒng)計(jì)分析；
前面所說的的大假在國內(nèi)目前只有2個(gè)即春節(jié)與國慶，小假較多譬如清明、端午、中秋等。
對(duì)于用戶訪問用戶數(shù)、流量、網(wǎng)絡(luò)、后臺(tái)的TPS數(shù)量能夠建立一個(gè)數(shù)學(xué)預(yù)測模型那就非常的清晰了，對(duì)于后續(xù)的設(shè)計(jì)指導(dǎo)意義至關(guān)重要；

對(duì)于如此大的網(wǎng)站在安全性方面的需求需要做重點(diǎn)調(diào)研，另外由于是實(shí)時(shí)交易網(wǎng)站，還需要考慮金融安全問題，安全方面還得從如下兩個(gè)方面來全面考慮：
?? 內(nèi)部安全，主要關(guān)注資金以及交易的安全，特別是防止內(nèi)部人員尤其是系統(tǒng)管理員；
?? 外部安全，主要關(guān)注如何確保拒絕外部惡意入侵與攻擊成為一個(gè)核心，特別是類似DDOS之類的攻擊；
對(duì)照筆者的論述以及前面的新聞內(nèi)容，不難發(fā)現(xiàn)，12306的設(shè)計(jì)組非常明顯沒有充分深入地進(jìn)行需求調(diào)研與數(shù)據(jù)模型分析，特別是預(yù)案設(shè)計(jì)，因此筆者才敢說這更是個(gè)工程問題，而不完全是個(gè)純粹的技術(shù)問題。

2. 系統(tǒng)原型設(shè)計(jì)階段
國內(nèi)很多的軟件公司不太重視原型設(shè)計(jì)，這點(diǎn)對(duì)于小軟件開發(fā)無關(guān)緊要，可是一旦到了大型軟件的開發(fā)之時(shí)，不重視原型設(shè)計(jì)會(huì)失敗得很慘，筆者曾經(jīng)在后期救過一個(gè)ITSM管理系統(tǒng)的開發(fā)，究其原因，其中很重要的一條是對(duì)于原型設(shè)計(jì)不太重視，特別是在應(yīng)用了大量的新技術(shù)而未進(jìn)行原型設(shè)計(jì)是一件風(fēng)險(xiǎn)極大的事情，在筆者親身帶的幾十個(gè)項(xiàng)目中有一部分就是這種情況，其中幾個(gè)項(xiàng)目的痛苦經(jīng)歷（通宵達(dá)晝的加班長達(dá)1-2個(gè)月）更是令我終生難忘；

根據(jù)前面的需求方面的分析討論，不難發(fā)現(xiàn)12306的原型設(shè)計(jì)中需要解決的問題如下：
前端Web服務(wù)器基于巨量訪問的（秒均訪問千萬級(jí)別）可伸縮性模式驗(yàn)證：
?? 這塊可供選擇的技術(shù)包括如下一些：基于CDN的Internet緩存加速技術(shù)、基于Apache Server+JBoss(Weblogic)的組合服務(wù)不同的、基于不同接口的調(diào)用原型研究、請(qǐng)求排隊(duì)技術(shù)等的原型研究；

后端數(shù)據(jù)庫讀寫基于火車票應(yīng)用的可擴(kuò)展模式；
?? 大家都知道，借鑒Facebook的巨量數(shù)據(jù)處理經(jīng)驗(yàn)，必須基于現(xiàn)代數(shù)據(jù)庫的分區(qū)技術(shù)、分布式處理技術(shù)并且通過后續(xù)的查詢結(jié)果集成技術(shù)來實(shí)現(xiàn)巨量交易數(shù)據(jù)的可擴(kuò)展性，基于巨量數(shù)據(jù)應(yīng)用的可擴(kuò)展模式通常有如下模式：
? 水平擴(kuò)展技術(shù)，通常是基于分區(qū)技術(shù)來實(shí)施，維度是分區(qū)技術(shù)進(jìn)行選擇時(shí)的關(guān)鍵，針對(duì)于火車票的交易數(shù)據(jù)而言，時(shí)間維度是最好的選擇，具體執(zhí)行而言，可以將每天的車票交易信息放到某一分區(qū)上來執(zhí)行，這樣對(duì)于后續(xù)的數(shù)據(jù)維護(hù)（存儲(chǔ)備份等）都將帶來極大的方便；
????? 垂直擴(kuò)展技術(shù)，通常是基于地域等實(shí)現(xiàn)的分布式擴(kuò)展，針對(duì)于火車票的交易數(shù)據(jù)而言，如何將不同地域的車票、車次信息劃歸為不同的數(shù)據(jù)庫服務(wù)器來執(zhí)行，確保在數(shù)據(jù)交易上的廣域可并行性；

對(duì)于12306系統(tǒng)，筆者建議最好能夠按照列車始發(fā)與到達(dá)站的地域性進(jìn)行垂直切割，而交易數(shù)據(jù)按照時(shí)間來進(jìn)行橫向水平擴(kuò)展形成不同的子數(shù)據(jù)庫，同時(shí)通過中間的緩存服務(wù)器、索引服務(wù)器、集成服務(wù)器將不同的數(shù)據(jù)進(jìn)行地整合過來，提供給前端的應(yīng)用服務(wù)器，因此從系統(tǒng)架構(gòu)上來看這個(gè)結(jié)構(gòu)圖形如下：




3. 原型驗(yàn)證階段
針對(duì)系統(tǒng)的原型設(shè)計(jì)，需要針對(duì)相應(yīng)的子系統(tǒng)來驗(yàn)證原型的技術(shù)穩(wěn)定性與成熟度，具體而言分別分為如下幾段：
針對(duì)前端訪問的巨量級(jí)別的HTTP負(fù)載均衡子系統(tǒng)驗(yàn)證，特別是驗(yàn)證針對(duì)單個(gè)數(shù)據(jù)農(nóng)場的服務(wù)響應(yīng)能力，需要驗(yàn)證單個(gè)服務(wù)器的HTTP極限響應(yīng)數(shù)量、動(dòng)態(tài)擴(kuò)展機(jī)制、網(wǎng)絡(luò)帶寬占用情況等；
針對(duì)中間訪問的緩存子系統(tǒng)、索引子系統(tǒng)、集成子系統(tǒng)，需要驗(yàn)證依照前端的用戶請(qǐng)求如何將連接到后端不同的數(shù)據(jù)庫上進(jìn)行相應(yīng)的數(shù)據(jù)分布化集成服務(wù)；
針對(duì)后端訪問的數(shù)據(jù)庫垂直、水平切割技術(shù)，基于地域的垂直切割與基于時(shí)間的水平切割技術(shù)并且結(jié)合存儲(chǔ)方面的分布式來擴(kuò)充數(shù)據(jù)庫系統(tǒng)的事務(wù)能力；

4. 系統(tǒng)正式設(shè)計(jì)階段
正式設(shè)計(jì)整個(gè)系統(tǒng)時(shí)要考慮的設(shè)計(jì)方面還是挺多的，分別列出如下。
功能性設(shè)計(jì)：
前端Web服務(wù)器設(shè)計(jì)，可以按照Apache來負(fù)責(zé)靜態(tài)頁面響應(yīng)處理、JBOSS/WEBLOGIC負(fù)責(zé)動(dòng)態(tài)頁面響應(yīng)處理來進(jìn)行設(shè)計(jì)，同時(shí)可以考慮將整個(gè)資源放到內(nèi)存里面而使得Apache服務(wù)器對(duì)于靜態(tài)資源的調(diào)用徹底離開磁盤I/O的制限，從而最大程度上提升前端Web服務(wù)器響應(yīng)能力，這點(diǎn)筆者在一個(gè)游戲網(wǎng)站的后端服務(wù)器上曾經(jīng)使用過，整體的web server響應(yīng)能力提升了好幾倍；
具體的業(yè)務(wù)設(shè)計(jì)需要依照個(gè)業(yè)務(wù)的流程來拆解實(shí)施，此設(shè)計(jì)的關(guān)鍵是在于將前段的業(yè)務(wù)如何能夠跟后端的高度擴(kuò)展的分布數(shù)據(jù)庫能夠集成對(duì)應(yīng)起來；

后端數(shù)據(jù)庫處理系統(tǒng)可以考慮按照如下的模式來予以完善設(shè)計(jì)：?? 將前段系統(tǒng)的運(yùn)算分解與將各服務(wù)器進(jìn)行（結(jié)果集成子系統(tǒng)）、使用成熟的反向搜索引擎系統(tǒng)作為前端的車站查詢系統(tǒng)（搜索引擎子系統(tǒng)）、中間基于車次的具體查詢可以使用緩存系統(tǒng)來實(shí)現(xiàn)（緩存子系統(tǒng)）、交易數(shù)據(jù)將寫入到RDBMS之中（可水平、垂直擴(kuò)展的事務(wù)處理子系統(tǒng)）； 這樣設(shè)計(jì)的好處主要是將各種交易以及訪問能夠最大程度上的并行化，實(shí)現(xiàn)分布式集成化處理，從而最大程度上提升系統(tǒng)的整體處理能力；

存儲(chǔ)子系統(tǒng)的設(shè)計(jì)：
主要是如何在RDMMS之間能夠最大化各數(shù)據(jù)庫的I/O處理能力同時(shí)提供不同地域（數(shù)據(jù)農(nóng)場）的數(shù)據(jù)同步服務(wù)支持，同時(shí)對(duì)于從網(wǎng)絡(luò)條件來看，建議將不同數(shù)據(jù)中心互聯(lián)的光纖與用戶請(qǐng)求的光纖分開了確保后端的數(shù)據(jù)同步響應(yīng)不受前端的密集巨量請(qǐng)求服務(wù)之影響。

安全性設(shè)計(jì)：
前端的安全性設(shè)計(jì)主要包括防止諸如拒絕訪問攻擊(DDOS)、腳本注入攻擊、用戶信息安全、系統(tǒng)入侵等，后端的安全性設(shè)計(jì)主要是要考慮賬戶信息、交易的安全等；
通常來說，前端可以考慮基于防火墻以及各種訪問監(jiān)測技術(shù)來做統(tǒng)計(jì)分析監(jiān)控各種異常情況，而后端主要是基于數(shù)據(jù)加密、交易通道安全、數(shù)據(jù)庫防篡改設(shè)計(jì)等來實(shí)施。

冗余設(shè)計(jì)：
包括依照地域、用戶群建立不同的數(shù)據(jù)中心的設(shè)計(jì)、基于DNS區(qū)域解析規(guī)劃設(shè)計(jì)、基于各服務(wù)器角色進(jìn)行的冗余設(shè)計(jì)（WEB服務(wù)器、搜索服務(wù)器、緩存服務(wù)器、集成服務(wù)器、數(shù)據(jù)庫服務(wù)器、存儲(chǔ)服務(wù)器等）所進(jìn)行的數(shù)據(jù)的冗余設(shè)計(jì)，譬如常見的集群技術(shù)、熱備以及熱切技術(shù)等均可考慮在此應(yīng)用；
其實(shí)筆者使用了中國國內(nèi)的服務(wù)器以及美國的服務(wù)器分別解析了12306.cn域名地址，顯示了兩個(gè)不同的地址，這已說明12306設(shè)計(jì)組已經(jīng)考慮了這些內(nèi)容：
從美國PING將會(huì)發(fā)現(xiàn)：
ping www.12306.cn
PING 08911.xdwscache.glb0.lxdns.com (183.60.136.64) 56(84) bytes of data.
64 bytes from 183.60.136.64: icmp_seq=1 ttl=49 time=171 ms
64 bytes from 183.60.136.64: icmp_seq=2 ttl=49 time=171 ms

從上海PING將會(huì)發(fā)現(xiàn)：
ping www.12306.cn
Pinging 08911.xdwscache.glb0.lxdns.com [211.144.81.22] with 32 bytes of data:
Reply from 211.144.81.22: bytes=32 time=11ms TTL=59
Reply from 211.144.81.22: bytes=32 time=10ms TTL=59

部署與維護(hù)設(shè)計(jì)：
部署設(shè)計(jì)的關(guān)鍵是確保各種角色的服務(wù)器如何能夠?qū)崿F(xiàn)快速復(fù)制擴(kuò)展，在緊急需要時(shí)能夠快速部署實(shí)施，同時(shí)對(duì)于服務(wù)器集群在進(jìn)行升級(jí)時(shí)如何快速批量地更新整個(gè)執(zhí)行包；
維護(hù)設(shè)計(jì)的關(guān)鍵考慮因素是系統(tǒng)運(yùn)行的監(jiān)控與報(bào)警系統(tǒng)設(shè)計(jì)，監(jiān)控的指標(biāo)就前端包括整個(gè)系統(tǒng)的訪問數(shù)量、單個(gè)客戶端的訪問頻率、訪問的URL分布等，后端需要監(jiān)控的是各服務(wù)器的使用量、負(fù)載量同時(shí)以此進(jìn)行上報(bào)到監(jiān)控服務(wù)器來決定相應(yīng)的服務(wù)器是否需要進(jìn)行動(dòng)態(tài)擴(kuò)展；

5. 開發(fā)實(shí)施階段
針對(duì)于此巨型交易系統(tǒng)的開發(fā)，在開發(fā)階段的關(guān)鍵因素是代碼品質(zhì)控制，建議采用軟件工程成熟的Coding->Review->UT控制技術(shù)（基于TDD的開發(fā)模式）來完成個(gè)模塊以及集成子系統(tǒng)的品質(zhì)管控，在此特別提醒的是對(duì)于Review、UT段的密度需要做硬性的規(guī)定，流程裁剪時(shí)建議采用高密開發(fā)模式確保此階段的品質(zhì)管控目標(biāo)，在此不得不多說一句的是很多時(shí)候很多的公司、開發(fā)人員總是錯(cuò)誤地認(rèn)為這些流程過于復(fù)雜，浪費(fèi)時(shí)間，其實(shí)從各種實(shí)際的項(xiàng)目實(shí)施經(jīng)歷來看，此處多花了2-3倍的開發(fā)時(shí)間可以避免后續(xù)5-10甚至數(shù)十倍調(diào)試時(shí)間(Bug fix)的投入，整體上來算還是非常值得的，對(duì)于大型項(xiàng)目尤其如此，筆者在很多大型項(xiàng)目的集成階段碰到集成不暢、無法按時(shí)完成集成任務(wù)時(shí)，開發(fā)、測試人員都是通宵達(dá)晝地加班，這其中很多的工作都是無用功，何不在開發(fā)實(shí)施階段將系統(tǒng)的測試密度進(jìn)行加大呢？構(gòu)建質(zhì)量上更好的組件（部件、模塊），這樣到集成的時(shí)候就不手忙腳亂了。

由于此系統(tǒng)的規(guī)模非常大，因此在詳細(xì)設(shè)計(jì)、開發(fā)時(shí)，應(yīng)該考慮到各子系統(tǒng)必須設(shè)計(jì)得非常易于測試，特別是易于進(jìn)行單體測試與自動(dòng)化測試，這點(diǎn)可以大幅降低項(xiàng)目的執(zhí)行成本;

6. 測試階段
對(duì)此巨型系統(tǒng)的構(gòu)建完畢后需要經(jīng)歷子系統(tǒng)集成測試、系統(tǒng)總集成測試兩個(gè)階段，并且需要按照如下不同的測試種類來進(jìn)行逐個(gè)測試確認(rèn)：
?功能測試、性能測試、安全測試、破壞性測試、持久運(yùn)行能力測試等
功能測試需要針對(duì)多服務(wù)器角色集成后按照設(shè)計(jì)所提供的功能清單依據(jù)測試密度以及測試的分布性來確定不同方面的測試case，依據(jù)此來分步執(zhí)行此功能測試，并且依照測試執(zhí)行的結(jié)果來分析各個(gè)模塊的缺陷密度以及缺陷的消化曲線，以此指導(dǎo)后期的開發(fā)設(shè)計(jì)工作，并藉此可盡快完成功能方面的驗(yàn)收確認(rèn)；

性能測試針對(duì)這個(gè)案列相對(duì)比較復(fù)雜，由于服務(wù)器角色很多，其基本的思路還是分析確定前端各業(yè)務(wù)的使用比例，編寫開發(fā)自動(dòng)化測試腳本來模擬用戶的操作行為，并且在測試環(huán)境下針對(duì)特定的服務(wù)器數(shù)量的集群發(fā)起服務(wù)請(qǐng)求，同時(shí)完整地檢測每個(gè)角色服務(wù)器的CPU/Memory/Disk I|O/Network方面的性能參數(shù)值，通過不斷增減客戶端請(qǐng)求數(shù)（伴隨客戶端機(jī)器的增加、譬如初期使用100臺(tái)，逐步增加到200臺(tái)測試機(jī)）來觀察服務(wù)器的性能反應(yīng)，分析出拐點(diǎn)，同時(shí)需要測試出系統(tǒng)的極限吞吐量(RPS,TPS等值)，并且測試出增加不同的服務(wù)器角色對(duì)于這些吞吐量的影響，同時(shí)在此階段需要開發(fā)人員的協(xié)助來針對(duì)不同的角色根據(jù)測試結(jié)果進(jìn)行性能調(diào)優(yōu)工作；

安全測試，需要針對(duì)以下不同的場景進(jìn)行模擬攻擊測試：
外部安全而言： 包括腳本注入攻擊、端口掃描、拒絕服務(wù)攻擊、主機(jī)入侵等安全測試都需要逐個(gè)進(jìn)行驗(yàn)證，確保系統(tǒng)的外部安全；
內(nèi)部安全而言： 包括各服務(wù)器的數(shù)據(jù)的安全、密碼安全等進(jìn)行測試；

破壞性測試，需要就各個(gè)角色服務(wù)器所對(duì)應(yīng)的物理服務(wù)器進(jìn)行不同部位失效、移除等試驗(yàn)，看看整個(gè)服務(wù)器集群的監(jiān)控、維護(hù)服務(wù)以及服務(wù)輸出吞吐的影響，并且完善后續(xù)的各種系統(tǒng)對(duì)應(yīng)的維護(hù)流程；

持久運(yùn)行能力測試需要，待系統(tǒng)達(dá)到Beta測試版本要求之后，需要針對(duì)待部署的系統(tǒng)進(jìn)行一定負(fù)載量持續(xù)運(yùn)行至少2周以上，并且觀測系統(tǒng)的穩(wěn)定性方面的反應(yīng)，同時(shí)就數(shù)據(jù)庫的增長、日志的增長等各種情況進(jìn)行綜合評(píng)估并且需要結(jié)合后續(xù)的部署維護(hù)做適當(dāng)完善性調(diào)整；

7. 部署階段

對(duì)于如此巨型系統(tǒng)的部署調(diào)試工作，也是個(gè)不大不小的工程，那么如何確保部署調(diào)試工作進(jìn)展的順利，根據(jù)筆者多年維護(hù)廣域網(wǎng)系統(tǒng)的經(jīng)驗(yàn)，有如下幾點(diǎn)需要注意：

?-> 如何管理好不同的服務(wù)器之間的發(fā)行版本問題，確保發(fā)布不會(huì)亂，特別是小版本的升級(jí)上部署不會(huì)亂是個(gè)關(guān)鍵，否則對(duì)于數(shù)以千計(jì)的服務(wù)器那絕對(duì)是個(gè)災(zāi)難；

?->如何能夠快速解決單次發(fā)布的升級(jí)與回退問題同樣是很重要，這當(dāng)中筆者的經(jīng)驗(yàn)是使用一個(gè)經(jīng)過驗(yàn)證的發(fā)布部署流程以及校驗(yàn)流程，整個(gè)過程最后放在一個(gè)發(fā)布腳本中，對(duì)于具體的升級(jí)與回退，維護(hù)人員只需要執(zhí)行一次命令即可完成，并且對(duì)于每個(gè)版本發(fā)布完畢后的校驗(yàn)工作尤其重要，必須在腳本中予以體現(xiàn)；

?->最后一點(diǎn)對(duì)于部署而言，任何部署都必須要有回滾方案配套，確保任何時(shí)間點(diǎn)上系統(tǒng)皆可用；

8. 運(yùn)行維護(hù)階段
在運(yùn)行維護(hù)階段有很多細(xì)節(jié)需要配套考慮：
? ->系統(tǒng)整體的實(shí)時(shí)狀態(tài)監(jiān)控，包括各種角色的應(yīng)用主機(jī)的監(jiān)控、網(wǎng)絡(luò)設(shè)備的監(jiān)控、用戶訪問流量的監(jiān)控、服務(wù)可用性監(jiān)控、安全監(jiān)控等；
? ->系統(tǒng)巨量的交易數(shù)據(jù)轉(zhuǎn)儲(chǔ)、交易日志的轉(zhuǎn)儲(chǔ)問題， 這個(gè)問題的解決需要結(jié)合前面在設(shè)計(jì)時(shí)的 數(shù)據(jù)庫垂直（按時(shí)間維度）擴(kuò)展以及日志按照天的維度來進(jìn)行維護(hù)的方式進(jìn)行有計(jì)劃地轉(zhuǎn)儲(chǔ)到不同時(shí)間段的歷史庫中，并且通過數(shù)據(jù)的清洗、整理將部分重要數(shù)據(jù)轉(zhuǎn)入到OLAP/OLTP系統(tǒng)中，為后續(xù)系統(tǒng)基于實(shí)時(shí)交易數(shù)據(jù)的聯(lián)機(jī)分析改進(jìn)業(yè)務(wù)提供幫助；

9. 優(yōu)化階段

? ->業(yè)務(wù)流程優(yōu)化：這塊最主要的問題是將購票這個(gè)核心業(yè)務(wù)按照計(jì)算機(jī)易于執(zhí)行計(jì)算的模型來進(jìn)行不斷地優(yōu)化，同時(shí)體驗(yàn)，譬如異步事務(wù)提交優(yōu)化、排隊(duì)技術(shù)等皆可以使用在用戶的模型上，同時(shí)可以向用戶提供預(yù)訂業(yè)務(wù)等來降低某個(gè)時(shí)段的網(wǎng)站流量壓力，使得流量的整體峰值、谷值差距縮小很多；

? ->架構(gòu)設(shè)計(jì)優(yōu)化：在數(shù)據(jù)庫的分區(qū)（垂直、水平分區(qū)）方面不斷地進(jìn)行優(yōu)化，同時(shí)對(duì)于單數(shù)據(jù)庫，就事務(wù)處理能力方面進(jìn)行優(yōu)化存儲(chǔ)方面的操作，譬如使用固態(tài)硬盤替代傳統(tǒng)的SCSI盤等，并行虛擬寫技術(shù)等大幅提升磁盤I/O操作能力、或者采用內(nèi)存數(shù)據(jù)庫技術(shù)來管理好讀寫分離（讀自內(nèi)存、寫到內(nèi)存與磁盤同時(shí)），這樣可以在數(shù)據(jù)庫層面上獲得性能的大幅提升；如果能夠配合系統(tǒng)壓力測試模型來獲取其性能衰減曲線圖針對(duì)性地優(yōu)化，其效果將更加明顯；

?在中間層服務(wù)器上，如何將不同的車次分布在大小幾百個(gè)數(shù)據(jù)庫上，并且使用反向搜索引擎技術(shù)來連接前端的訪問請(qǐng)求到后端的數(shù)據(jù)庫服務(wù)器之間的映射與集成（這點(diǎn)可以參考MapReduce并行算法）；

在應(yīng)用層服務(wù)器上，如何將靜態(tài)內(nèi)容與動(dòng)態(tài)內(nèi)容予以剝離，并且無需保存的內(nèi)容（只讀）內(nèi)容全放在內(nèi)存中，如何平衡CDN加速與后端Web server的服務(wù)架構(gòu)也是不斷提升單個(gè)農(nóng)場集群服務(wù)能力的關(guān)鍵與核心；

? ->性能優(yōu)化： 這些優(yōu)化是非常之多的，譬如針對(duì)Web server的socket連接池優(yōu)化、日志優(yōu)化，針對(duì)中間集成服務(wù)器的并行任務(wù)分解與結(jié)果集成優(yōu)化，基于后端數(shù)據(jù)庫服務(wù)器的數(shù)據(jù)計(jì)算模型、訪問方式、冗余與數(shù)據(jù)同步、傳遞優(yōu)化、數(shù)據(jù)分區(qū)優(yōu)化等；

? ->其他調(diào)優(yōu)：其他方面的調(diào)優(yōu)譬如基于監(jiān)控的優(yōu)化、基于大并發(fā)量的快速響應(yīng)與擴(kuò)展優(yōu)化等等；

寫到此，感覺上似乎已經(jīng)設(shè)計(jì)完畢了，不過突然回頭一望，還真發(fā)現(xiàn)內(nèi)容非常之多，可能有實(shí)戰(zhàn)經(jīng)驗(yàn)的朋友肯定會(huì)提到此系統(tǒng)屬于“過度設(shè)計(jì)”了，不過筆者在此要說的是，確實(shí)這個(gè)最后的提醒是非常有必要的，任何系統(tǒng)的設(shè)計(jì)特別是如此復(fù)雜的系統(tǒng)的設(shè)計(jì)只能是需要通過時(shí)間來循序漸進(jìn)，先原型后實(shí)際系統(tǒng)并且遵循幾輪研發(fā)調(diào)優(yōu)（含架構(gòu)設(shè)計(jì)調(diào)優(yōu)），最后逐漸演變到一個(gè)真實(shí)成熟的系統(tǒng)，任何超前的設(shè)計(jì)最終都被證明是無用功而遭廢棄；

很多的網(wǎng)友對(duì)于12306的網(wǎng)站的技術(shù)議論紛紜，并且提出了眾多的創(chuàng)造性想法，筆者在提出自己的想法后還有幾點(diǎn)補(bǔ)充想法供大家參考：
1. 其實(shí)此網(wǎng)站的需求不是一個(gè)純粹的技術(shù)問題，試想一下，真的按照國慶、春節(jié)的高峰訪問需求來設(shè)計(jì)、部署整個(gè)系統(tǒng)的時(shí)候，在平時(shí)的時(shí)候大部分機(jī)器都是浪費(fèi)的，如何平衡峰值與谷值時(shí)矛盾是個(gè)技術(shù)問題，可背后掩蓋著的是全中國13億多人口在短短的10-15天內(nèi)完成眾多的人口遷徙，如此巨大的工程放在任何一個(gè)國家都是難于解決的問題，如何從需求層面來化解這個(gè)短期內(nèi)的巨量人口流動(dòng)問題才是此問題的命根； 正所謂 “ 解決火車票購買過程容易，而解決人人能買到火車票難！！！”
2. 此問題的求解永遠(yuǎn)是個(gè)迭代過程，需要看到的是很難有人能夠在短期內(nèi)設(shè)計(jì)并且實(shí)現(xiàn)這么一個(gè)巨量系統(tǒng)，這個(gè)工程問題的求解是拆解為不同的子模塊來分步實(shí)現(xiàn)，并且逐步迭代優(yōu)化求解的過程；

3. 此問題的解決必須是個(gè)系統(tǒng)工程，牽涉到資金、技術(shù)、人才、時(shí)間 這4個(gè)基本要素，很多的同行過于看重人才與技術(shù)，而忽略了資金等前提性因素，試想如果只有3000萬預(yù)算讓你來設(shè)計(jì)實(shí)現(xiàn)這個(gè)巨型交易系統(tǒng)，你能解決么？ 不說別的，光性能模擬測試就需要調(diào)動(dòng)數(shù)以萬計(jì)的前端機(jī)器來在全國范圍內(nèi)不同的典型區(qū)域發(fā)起海量請(qǐng)求，這些是個(gè)小資金能夠解決得了的問題么？

后記： 筆者深知，任何技術(shù)的討論必然會(huì)引起一些爭議，整個(gè)技術(shù)的發(fā)展必須要經(jīng)歷這樣的紛爭才能進(jìn)步與提高，在此博文發(fā)布的幾天內(nèi)，備受各位同行的關(guān)注，筆者非常感謝，也發(fā)現(xiàn)了諸多不友好的言辭， 對(duì)于有類似架構(gòu)經(jīng)驗(yàn)、大項(xiàng)目經(jīng)歷的同行一看就明白，而無此經(jīng)歷的同行看起來相對(duì)比較而言沒有感覺，筆者在此期望技術(shù)紛爭的同行不要爆粗，大家共同的目的是為了推動(dòng)技術(shù)交流，推動(dòng)你我的技術(shù)進(jìn)步，推動(dòng)國家與民族的技術(shù)發(fā)展。

總結(jié)

以上是生活随笔為你收集整理的假如我来架构12306网站(一) - 概论的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。