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