螞蟻?zhàn)兇笙螅簻\談常規(guī)網(wǎng)站是如何從小變大的
來源:解決方案 2012-06-25
2005年,我開始和朋友們開始拉活兒做網(wǎng)站,當(dāng)時(shí)第一個(gè)網(wǎng)站是在linux上用jsp搭建的,到后來逐步的引入了多種框架,如webwork、hibernate等。在到后來,進(jìn)入公司,開始用c/c++,做分布式計(jì)算和存儲(chǔ)。(到那時(shí)才解開了我的一個(gè)疑惑:C語言除了用來寫HelloWorld,還能干嘛?^_^)。
總而言之,網(wǎng)站根據(jù)不同的需求,不同的請(qǐng)求壓力,不同的業(yè)務(wù)模型,需要不同的架構(gòu)來給予支持。我從我的一些經(jīng)歷和感受出發(fā),大體上總結(jié)了一下的一些階段。詳情容我慢慢道來。
【第一階段:搭建屬于自己的網(wǎng)站】
我們最先開始的網(wǎng)站可能是長(zhǎng)成這個(gè)樣子的:
拿Java做例子,我們可能會(huì)引入struts、spring、hibernate等框架,用來做URL分流,C、V、M隔離,數(shù)據(jù)的ORM等。這樣,我們的系統(tǒng)中,數(shù)據(jù)訪問層可以抽取出很多公用的類,業(yè)務(wù)邏輯層也可以抽取出很多公用的業(yè)務(wù)類,同一個(gè)業(yè)務(wù)邏輯可以對(duì)應(yīng)多個(gè)展示頁面,可復(fù)用性得到極大的增強(qiáng)。
不過,從性能上看,引入框架后,效率并不見得比第一種架構(gòu)高,有可能還有降低。因?yàn)榭蚣芸赡軙?huì)大量引入“反射”的機(jī)制,來創(chuàng)建對(duì)應(yīng)的業(yè)務(wù)對(duì)象;同時(shí),也可能增加額外的框架邏輯,來增強(qiáng)隔離性。從而使得整體服務(wù)能力下降。幸好,在這個(gè)階段,業(yè)務(wù)請(qǐng)求量不大,性能不是我們太care的事情。J
【第三階段:降低磁盤壓力 】
可能隨著業(yè)務(wù)的持續(xù)發(fā)展,或者是網(wǎng)站關(guān)注度逐步提升(也有可能是搜索引擎的爬蟲關(guān)注度逐步提升。我之前有一個(gè)網(wǎng)站,每天有超過1/3的訪問量,就是各種爬蟲貢獻(xiàn)的),我們的請(qǐng)求量逐步變大,這個(gè)時(shí)候,往往出現(xiàn)瓶頸的就是磁盤性能。在linux下,用vmstat、iostat等命令,可以看到磁盤的bi、bo、wait、util等值持續(xù)高位運(yùn)行。怎么辦呢?
其實(shí),在我們剛剛踏進(jìn)大學(xué)校門的時(shí)候,第一門計(jì)算機(jī)課程——《計(jì)算機(jī)導(dǎo)論》里面就給出了解決方案。依稀記得下面這個(gè)圖:
在我們的存儲(chǔ)體系里面,磁盤一般是機(jī)械的(現(xiàn)在Flash、SSD等開始逐步大規(guī)模使用了),讀取速度最慢,而內(nèi)存訪問速度較快(讀取一個(gè)字節(jié)約10μs,速度較磁盤能高幾百倍),速度最快的是CPU的cache。不過價(jià)格和存儲(chǔ)空間卻遞減。
話題切換回來,當(dāng)我們的磁盤出現(xiàn)性能瓶頸的時(shí)候,我們這個(gè)時(shí)候,就要考慮其他的存儲(chǔ)介質(zhì),那么我們是用cpucache還是內(nèi)存呢,或是其他形態(tài)的磁盤?綜合性價(jià)比來看,到這個(gè)階段,我個(gè)人還是推薦使用內(nèi)存�，F(xiàn)在內(nèi)存真是白菜價(jià),而且容量持續(xù)增長(zhǎng)(我現(xiàn)在就看到64G內(nèi)存的機(jī)器[截止2012-4-3])。
但是問題來了,磁盤是持久化存儲(chǔ)的,斷電后。數(shù)據(jù)不會(huì)丟失,而內(nèi)存卻是易失性存儲(chǔ)介質(zhì),斷電后內(nèi)容會(huì)丟失。因此,內(nèi)存只能用來保存臨時(shí)性數(shù)據(jù),持久性數(shù)據(jù)還是需要放到磁盤等持久化介質(zhì)上。因此,內(nèi)存可以有多種設(shè)計(jì),其中最常見的就是cache(其他的設(shè)計(jì)方式會(huì)在后面提及)。這種數(shù)據(jù)結(jié)構(gòu)通常利用LRU算法(現(xiàn)在還有結(jié)合隊(duì)列、集合等多種數(shù)據(jù)結(jié)構(gòu),以及排序等多種算法的cache),用于記錄一段時(shí)間的臨時(shí)性數(shù)據(jù),在必要的時(shí)候可以淘汰或定期刪除,以保證數(shù)據(jù)的有效性。cache通常以Key-Value形式來存儲(chǔ)數(shù)據(jù)(也有Key-SubKey-Value,或者是Key-List,以及Key-Set等形式的)。因?yàn)閿?shù)據(jù)存放在內(nèi)存,所以訪問速度會(huì)提高上百倍,并且極大的減少磁盤IO壓力。
Cache有多種架構(gòu)設(shè)計(jì),最常見的就是穿透式和旁路式。穿透式通常是程序本身使用對(duì)應(yīng)的cache代碼庫,將cache編譯進(jìn)程序,通過函數(shù)直接訪問。旁路式則是以服務(wù)的方式提供查詢和更新。在此階段,我們通常使用旁路式cache,這種cache往往利用開源的服務(wù)程序直接搭建就可以使用(如MemCache)。旁路式結(jié)構(gòu)如下圖:
請(qǐng)求來臨的時(shí)候,我們的程序先從cache里面取數(shù)據(jù),如果數(shù)據(jù)存在并且有效,就直接返回結(jié)果;如果數(shù)據(jù)不存在,則從數(shù)據(jù)庫里面獲取,經(jīng)過邏輯處理后,先寫入到cache,然后再返回給用戶數(shù)據(jù)。這樣,我們下次再訪問的時(shí)候,就可以從cache中獲取數(shù)據(jù)。
Cache引入以后,最重要的就是調(diào)整內(nèi)存的大小,以保證有足夠的命中率。根據(jù)經(jīng)驗(yàn),好的內(nèi)存設(shè)置,可以極大的提升命中率,從而提升服務(wù)的響應(yīng)速度。如果原來IO有瓶頸的網(wǎng)站,經(jīng)過引入內(nèi)存cache以后,性能提升10倍應(yīng)該是沒有問題的。
不過,有一個(gè)問題就是:cache依賴。如果cache出問題(比如掛了,或是命中率下降),那就杯具了L。這個(gè)時(shí)候,服務(wù)就會(huì)直接將大的壓力壓向數(shù)據(jù)庫,造成服務(wù)響應(yīng)慢,或者是直接500。
另外,服務(wù)如果重新啟動(dòng)時(shí),也會(huì)出現(xiàn)慢啟動(dòng),即:給cache充數(shù)據(jù)的階段。對(duì)于這種情況,可以采取回放日志,或是從數(shù)據(jù)庫抽取最新數(shù)據(jù)等方式,在服務(wù)啟動(dòng)前,提前將一部分?jǐn)?shù)據(jù)放入到cache中,保證有一定命中率。
通過這樣的拆分后,我們就邁出了多機(jī)的第一步。雖然看起來比較簡(jiǎn)單和容易,但是這也是非常具有里程碑意義的。這樣的優(yōu)化,可能會(huì)提升20-30%左右的一個(gè)CPUidle。能夠使得我們的網(wǎng)站能夠經(jīng)受更大的壓力。
【第五階段:邏輯程序的多機(jī)化】
當(dāng)我們的訪問量持續(xù)增加的時(shí)候,我們承受這成長(zhǎng)的快樂和痛苦。流量刷刷往上漲,高興!但是呢,服務(wù)器叫苦不絕,我們的程序已經(jīng)快到不能服務(wù)的邊緣了。怎么辦?
“快使用分布式,哼哼哈嘿”J
這個(gè)時(shí)候,我們就需要針對(duì)CPU瓶頸,將我們的程序分別放在多臺(tái)服務(wù)器上,讓他們同時(shí)提供服務(wù),將用戶請(qǐng)求分?jǐn)偟蕉鄠�(gè)提供服務(wù)的機(jī)器。
好,如果提供這樣的服務(wù),我們會(huì)遇到什么樣的問題?怎么樣來解決?
我們一個(gè)個(gè)的來分析:
一、WebServer怎么樣來分流用戶請(qǐng)求?That’s a good question!
在考慮這個(gè)問題的時(shí)候,我們常見的WebServer早已給我們想好了解決方案�，F(xiàn)在主流的WebServer幾乎都提供一個(gè)叫“LoadBalance”的功能,翻譯過來就是負(fù)載均衡。我們可以在WebServer上配置一組機(jī)器列表,當(dāng)請(qǐng)求來臨的時(shí)候,WebServer會(huì)根據(jù)一定的規(guī)則選取某一臺(tái)機(jī)器,將請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)的邏輯處理程序上。
有同學(xué)馬上就會(huì)問了,“一定的規(guī)則”是怎么樣的規(guī)則?他能解決什么樣的問題?如果機(jī)器宕了怎么辦?……
哈哈,這里的一定規(guī)則就是“LoadBalance”。負(fù)載均衡其實(shí)是分布式計(jì)算和存儲(chǔ)中最基礎(chǔ)的算法,他的好壞,直接決定了服務(wù)的穩(wěn)定性。我曾經(jīng)設(shè)計(jì)和開發(fā)了一個(gè)負(fù)載均衡算法(現(xiàn)在正在大規(guī)模使用),有一次就因?yàn)橐粋�(gè)很小的case,導(dǎo)致服務(wù)大面積出現(xiàn)問題。
負(fù)載均衡要解決的就是,上游程序如何在我們提供的一堆機(jī)器列表中,找到合適的機(jī)器來提供下游的服務(wù)。因此,我們可以將負(fù)載均衡分成兩個(gè)方向來看:第一,根據(jù)怎樣的規(guī)則來選機(jī)器;第二,符合規(guī)則的機(jī)器中,哪些是能提供服務(wù)的。對(duì)于第一個(gè)問題,我們通常使用隨機(jī)、輪詢、一致Hash等算法;對(duì)于第二個(gè)問題,我們要使用心跳、服務(wù)響應(yīng)判定等方法檢測(cè)機(jī)器的健康狀態(tài)。關(guān)于負(fù)載均衡,要談的話點(diǎn)其實(shí)很多,我之前也寫過專門的一篇文章來介紹,后續(xù)有空了,我再詳細(xì)的描述。
總之,分流的問題,我們可以通過負(fù)載均衡來比較輕松的解決了。
1
2
3
4
5
6
7
8
下一頁
文章編輯: 365webcall網(wǎng)頁客服系統(tǒng)(www.365webcall.com)
我的評(píng)論
| 登錄賬號(hào)： | 密碼： | 快速注冊(cè) | 找回密碼 |  |
