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