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