愛上家娃
有文事者,必有武備 來如雷霆收震怒,罷如江海凝清光
導(dǎo)航
BlogJava
首頁
新隨筆
聯(lián)系
聚合
管理
統(tǒng)計
隨筆 - 63
文章 - 0
評論 - 17
引用 - 0
常用鏈接
我的隨筆
我的評論
我的參與
最新評論
留言簿
(3)
給我留言
查看公開留言
查看私人留言
隨筆檔案
2010年11月 (1)
2010年7月 (2)
2010年6月 (2)
2010年5月 (1)
2009年12月 (3)
2009年11月 (3)
2009年10月 (2)
2009年9月 (1)
2009年8月 (1)
2009年6月 (1)
2009年5月 (1)
2009年3月 (1)
2009年2月 (1)
2009年1月 (1)
2008年12月 (3)
2008年11月 (1)
2008年10月 (4)
2008年9月 (3)
2008年8月 (2)
2008年7月 (6)
2008年6月 (23)
搜索
最新評論
1.?re: ThinkPHP Cookie操作
發(fā)發(fā)發(fā)發(fā)發(fā)發(fā)
--But V
2.?re: SQL Server觸發(fā)器使用教程和命名規(guī)范
說說的就說遠了,ORACLE與SQLSERVER的觸發(fā)器一樣嗎?內(nèi)容與主題不符啊
--ymg022
3.?re: vb窗口最大化問題的解決方法
這個早就知道了,不過樓主有心將其整理成文并發(fā)布出來,還是要贊一個。
--李莫愁
4.?re: vb窗口最大化問題的解決方法
combox控件不能跟著變化呀 !!!!!!!!!!!!!
--kone
5.?男士錢包
朋友,你好,可以做個鏈接嗎
--男士錢包
閱讀排行榜
1.?SQL Server觸發(fā)器使用教程和命名規(guī)范(8579)
2.?vb窗口最大化問題的解決方法(7106)
3.?ThinkPHP Cookie操作 (2067)
4.?HTML代碼大全(1520)
5.?js返回上一頁(1254)
評論排行榜
1.?vb窗口最大化問題的解決方法(3)
2.?SQL(3)
3.?IE修改(2)
4.?征婚啟事(1)
5.?國內(nèi)SNS點評(1)
WEB 大型網(wǎng)站架構(gòu)演變和知識體系
之前也有一些介紹大型網(wǎng)站架構(gòu)演變的文章,例如LiveJournal的、ebay的,都是非常值得參考的,不過感覺他們講的更多的是每次演變的結(jié)果,而沒有很詳細的講為什么需要做這樣的演變,再加上近來感覺有不少同學(xué)都很難明白為什么一個網(wǎng)站需要那么復(fù)雜的技術(shù),于是有了寫這篇文章的想法,在這篇文章中將闡述一個普通的網(wǎng)站發(fā)展成大型網(wǎng)站過程中的一種較為典型的架構(gòu)演變歷程和所需掌握的知識體系,希望能給想從事互聯(lián)網(wǎng)行業(yè)的同學(xué)一點初步的概念,:),文中的不對之處也請各位多給點建議,讓本文真正起到拋磚引玉的效果。
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
架構(gòu)演變第一步:物理分離webserver和數(shù)據(jù)庫
最開始,由于某些想法,于是在互聯(lián)網(wǎng)上搭建了一個網(wǎng)站,這個時候甚至有可能主機都是租借的,但由于這篇文章我們只關(guān)注架構(gòu)的演變歷程,因此就假設(shè)這個時候已經(jīng)是托管了一臺主機,并且有一定的帶寬了,這個時候由于網(wǎng)站具備了一定的特色,吸引了部分人訪問,逐漸你發(fā)現(xiàn)系統(tǒng)的壓力越來越高,響應(yīng)速度越來越慢,而這個時候比較明顯的是數(shù)據(jù)庫和應(yīng)用互相影響,應(yīng)用出問題了,數(shù)據(jù)庫也很容易出現(xiàn)問題,而數(shù)據(jù)庫出問題的時候,應(yīng)用也容易出問題,于是進入了第一步演變階段:將應(yīng)用和數(shù)據(jù)庫從物理上分離,變成了兩臺機器,這個時候技術(shù)上沒有什么新的要求,但你發(fā)現(xiàn)確實起到效果了,系統(tǒng)又恢復(fù)到以前的響應(yīng)速度了,并且支撐住了更高的流量,并且不會因為數(shù)據(jù)庫和應(yīng)用形成互相的影響。
看看這一步完成后系統(tǒng)的圖示:
<!--[if !vml]-->
<!--[endif]-->
這一步涉及到了這些知識體系:
這一步架構(gòu)演變對技術(shù)上的知識體系基本沒有要求。
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
架構(gòu)演變第二步:增加頁面緩存
好景不長,隨著訪問的人越來越多,你發(fā)現(xiàn)響應(yīng)速度又開始變慢了,查找原因,發(fā)現(xiàn)是訪問數(shù)據(jù)庫的操作太多,導(dǎo)致數(shù)據(jù)連接競爭激烈,所以響應(yīng)變慢,但數(shù)據(jù)庫連接又不能開太多,否則數(shù)據(jù)庫機器壓力會很高,因此考慮采用緩存機制來減少數(shù)據(jù)庫連接資源的競爭和對數(shù)據(jù)庫讀的壓力,這個時候首先也許會選擇采用squid等類似的機制來將系統(tǒng)中相對靜態(tài)的頁面(例如一兩天才會有更新的頁面)進行緩存(當然,也可以采用將頁面靜態(tài)化的方案),這樣程序上可以不做修改,就能夠很好的減少對webserver的壓力以及減少數(shù)據(jù)庫連接資源的競爭,OK,于是開始采用squid來做相對靜態(tài)的頁面的緩存。
看看這一步完成后系統(tǒng)的圖示:
<!--[if !vml]-->
<!--[endif]-->
這一步涉及到了這些知識體系:
前端頁面緩存技術(shù),例如squid,如想用好的話還得深入掌握下squid的實現(xiàn)方式以及緩存的失效算法等。
架構(gòu)演變第三步:增加頁面片段緩存
增加了squid做緩存后,整體系統(tǒng)的速度確實是提升了,webserver的壓力也開始下降了,但隨著訪問量的增加,發(fā)現(xiàn)系統(tǒng)又開始變的有些慢了,在嘗到了squid之類的動態(tài)緩存帶來的好處后,開始想能不能讓現(xiàn)在那些動態(tài)頁面里相對靜態(tài)的部分也緩存起來呢,因此考慮采用類似ESI之類的頁面片段緩存策略,OK,于是開始采用ESI來做動態(tài)頁面中相對靜態(tài)的片段部分的緩存。
看看這一步完成后系統(tǒng)的圖示:
<!--[if !vml]-->
<!--[endif]-->
這一步涉及到了這些知識體系:
頁面片段緩存技術(shù),例如ESI等,想用好的話同樣需要掌握ESI的實現(xiàn)方式等;
架構(gòu)演變第四步:數(shù)據(jù)緩存
在采用ESI之類的技術(shù)再次提高了系統(tǒng)的緩存效果后,系統(tǒng)的壓力確實進一步降低了,但同樣,隨著訪問量的增加,系統(tǒng)還是開始變慢,經(jīng)過查找,可能會發(fā)現(xiàn)系統(tǒng)中存在一些重復(fù)獲取數(shù)據(jù)信息的地方,像獲取用戶信息等,這個時候開始考慮是不是可以將這些數(shù)據(jù)信息也緩存起來呢,于是將這些數(shù)據(jù)緩存到本地內(nèi)存,改變完畢后,完全符合預(yù)期,系統(tǒng)的響應(yīng)速度又恢復(fù)了,數(shù)據(jù)庫的壓力也再度降低了不少。
看看這一步完成后系統(tǒng)的圖示:
<!--[if !vml]-->
<!--[endif]-->
這一步涉及到了這些知識體系:
緩存技術(shù),包括像Map數(shù)據(jù)結(jié)構(gòu)、緩存算法、所選用的框架本身的實現(xiàn)機制等。
架構(gòu)演變第五步:增加webserver
好景不長,發(fā)現(xiàn)隨著系統(tǒng)訪問量的再度增加,webserver機器的壓力在高峰期會上升到比較高,這個時候開始考慮增加一臺webserver,這也是為了同時解決可用性的問題,避免單臺的webserver down機的話就沒法使用了,在做了這些考慮后,決定增加一臺webserver,增加一臺webserver時,會碰到一些問題,典型的有:
1、如何讓訪問分配到這兩臺機器上,這個時候通常會考慮的方案是Apache自帶的負載均衡方案,或LVS這類的軟件負載均衡方案;
2、如何保持狀態(tài)信息的同步,例如用戶session等,這個時候會考慮的方案有寫入數(shù)據(jù)庫、寫入存儲、cookie或同步session信息等機制等;
3、如何保持數(shù)據(jù)緩存信息的同步,例如之前緩存的用戶數(shù)據(jù)等,這個時候通常會考慮的機制有緩存同步或分布式緩存;
4、如何讓上傳文件這些類似的功能繼續(xù)正常,這個時候通常會考慮的機制是使用共享文件系統(tǒng)或存儲等;
在解決了這些問題后,終于是把webserver增加為了兩臺,系統(tǒng)終于是又恢復(fù)到了以往的速度。看看這一步完成后系統(tǒng)的圖示:
<!--[if !vml]-->
<!--[endif]-->
這一步涉及到了這些知識體系:
負載均衡技術(shù)(包括但不限于硬件負載均衡、軟件負載均衡、負載算法、linux轉(zhuǎn)發(fā)協(xié)議、所選用的技術(shù)的實現(xiàn)細節(jié)等)、主備技術(shù)(包括但不限于ARP欺騙、linux heart-beat等)、狀態(tài)信息或緩存同步技術(shù)(包括但不限于Cookie技術(shù)、UDP協(xié)議、狀態(tài)信息廣播、所選用的緩存同步技術(shù)的實現(xiàn)細節(jié)等)、共享文件技術(shù)(包括但不限于NFS等)、存儲技術(shù)(包括但不限于存儲設(shè)備等)。
架構(gòu)演變第六步:分庫
享受了一段時間的系統(tǒng)訪問量高速增長的幸福后,發(fā)現(xiàn)系統(tǒng)又開始變慢了,這次又是什么狀況呢,經(jīng)過查找,發(fā)現(xiàn)數(shù)據(jù)庫寫入、更新的這些操作的部分數(shù)據(jù)庫連接的資源競爭非常激烈,導(dǎo)致了系統(tǒng)變慢,這下怎么辦呢,此時可選的方案有數(shù)據(jù)庫集群和分庫策略,集群方面像有些數(shù)據(jù)庫支持的并不是很好,因此分庫會成為比較普遍的策略,分庫也就意味著要對原有程序進行修改,一通修改實現(xiàn)分庫后,不錯,目標達到了,系統(tǒng)恢復(fù)甚至速度比以前還快了。
看看這一步完成后系統(tǒng)的圖示:
<!--[if !vml]-->
<!--[endif]-->
這一步涉及到了這些知識體系:
這一步更多的是需要從業(yè)務(wù)上做合理的劃分,以實現(xiàn)分庫,具體技術(shù)細節(jié)上沒有其他的要求;
但同時隨著數(shù)據(jù)量的增大和分庫的進行,在數(shù)據(jù)庫的設(shè)計、調(diào)優(yōu)以及維護上需要做的更好,因此對這些方面的技術(shù)還是提出了很高的要求的。
架構(gòu)演變第七步:分表、DAL和分布式緩存
隨著系統(tǒng)的不斷運行,數(shù)據(jù)量開始大幅度增長,這個時候發(fā)現(xiàn)分庫后查詢?nèi)匀粫行┞谑前凑辗謳斓乃枷腴_始做分表的工作,當然,這不可避免的會需要對程序進行一些修改,也許在這個時候就會發(fā)現(xiàn)應(yīng)用自己要關(guān)心分庫分表的規(guī)則等,還是有些復(fù)雜的,于是萌生能否增加一個通用的框架來實現(xiàn)分庫分表的數(shù)據(jù)訪問,這個在ebay的架構(gòu)中對應(yīng)的就是DAL,這個演變的過程相對而言需要花費較長的時間,當然,也有可能這個通用的框架會等到分表做完后才開始做,同時,在這個階段可能會發(fā)現(xiàn)之前的緩存同步方案出現(xiàn)問題,因為數(shù)據(jù)量太大,導(dǎo)致現(xiàn)在不太可能將緩存存在本地,然后同步的方式,需要采用分布式緩存方案了,于是,又是一通考察和折磨,終于是將大量的數(shù)據(jù)緩存轉(zhuǎn)移到分布式緩存上了。看看這一步完成后系統(tǒng)的圖示:
<!--[if !vml]-->
<!--[endif]-->
這一步涉及到了這些知識體系:
分表更多的同樣是業(yè)務(wù)上的劃分,技術(shù)上涉及到的會有動態(tài)hash算法、consistent hash算法等;
DAL涉及到比較多的復(fù)雜技術(shù),例如數(shù)據(jù)庫連接的管理(超時、異常)、數(shù)據(jù)庫操作的控制(超時、異常)、分庫分表規(guī)則的封裝等;
架構(gòu)演變第八步:增加更多的webserver
在做完分庫分表這些工作后,數(shù)據(jù)庫上的壓力已經(jīng)降到比較低了,又開始過著每天看著訪問量暴增的幸福生活了,突然有一天,發(fā)現(xiàn)系統(tǒng)的訪問又開始有變慢的趨勢了,這個時候首先查看數(shù)據(jù)庫,壓力一切正常,之后查看webserver,發(fā)現(xiàn)apache阻塞了很多的請求,而應(yīng)用服務(wù)器對每個請求也是比較快的,看來是請求數(shù)太高導(dǎo)致需要排隊等待,響應(yīng)速度變慢,這還好辦,一般來說,這個時候也會有些錢了,于是添加一些webserver服務(wù)器,在這個添加webserver服務(wù)器的過程,有可能會出現(xiàn)幾種挑戰(zhàn):
1、Apache的軟負載或LVS軟負載等無法承擔巨大的web訪問量(請求連接數(shù)、網(wǎng)絡(luò)流量等)的調(diào)度了,這個時候如果經(jīng)費允許的話,會采取的方案是購買硬件負載,例如F5、Netsclar、Athelon之類的,如經(jīng)費不允許的話,會采取的方案是將應(yīng)用從邏輯上做一定的分類,然后分散到不同的軟負載集群中;
2、原有的一些狀態(tài)信息同步、文件共享等方案可能會出現(xiàn)瓶頸,需要進行改進,也許這個時候會根據(jù)情況編寫符合網(wǎng)站業(yè)務(wù)需求的分布式文件系統(tǒng)等;
在做完這些工作后,開始進入一個看似完美的無限伸縮的時代,當網(wǎng)站流量增加時,應(yīng)對的解決方案就是不斷的添加webserver。看看這一步完成后系統(tǒng)的圖示:
<!--[if !vml]-->
<!--[endif]-->
這一步涉及到了這些知識體系:
到了這一步,隨著機器數(shù)的不斷增長、數(shù)據(jù)量的不斷增長和對系統(tǒng)可用性的要求越來越高,這個時候要求對所采用的技術(shù)都要有更為深入的理解,并需要根據(jù)網(wǎng)站的需求來做更加定制性質(zhì)的產(chǎn)品。
架構(gòu)演變第九步:數(shù)據(jù)讀寫分離和廉價存儲方案
突然有一天,發(fā)現(xiàn)這個完美的時代也要結(jié)束了,數(shù)據(jù)庫的噩夢又一次出現(xiàn)在眼前了,由于添加的webserver太多了,導(dǎo)致數(shù)據(jù)庫連接的資源還是不夠用,而這個時候又已經(jīng)分庫分表了,開始分析數(shù)據(jù)庫的壓力狀況,可能會發(fā)現(xiàn)數(shù)據(jù)庫的讀寫比很高,這個時候通常會想到數(shù)據(jù)讀寫分離的方案,當然,這個方案要實現(xiàn)并不容易,另外,可能會發(fā)現(xiàn)一些數(shù)據(jù)存儲在數(shù)據(jù)庫上有些浪費,或者說過于占用數(shù)據(jù)庫資源,因此在這個階段可能會形成的架構(gòu)演變是實現(xiàn)數(shù)據(jù)讀寫分離,同時編寫一些更為廉價的存儲方案,例如BigTable這種。
看看這一步完成后系統(tǒng)的圖示:
<!--[if !vml]-->
<!--[endif]-->
這一步涉及到了這些知識體系:
數(shù)據(jù)讀寫分離要求對數(shù)據(jù)庫的復(fù)制、standby等策略有深入的掌握和理解,同時會要求具備自行實現(xiàn)的技術(shù);
廉價存儲方案要求對OS的文件存儲有深入的掌握和理解,同時要求對采用的語言在文件這塊的實現(xiàn)有深入的掌握。
架構(gòu)演變第十步:進入大型分布式應(yīng)用時代和廉價服務(wù)器群夢想時代
經(jīng)過上面這個漫長而痛苦的過程,終于是再度迎來了完美的時代,不斷的增加webserver就可以支撐越來越高的訪問量了,對于大型網(wǎng)站而言,人氣的重要毋庸置疑,隨著人氣的越來越高,各種各樣的功能需求也開始爆發(fā)性的增長,這個時候突然發(fā)現(xiàn),原來部署在webserver上的那個web應(yīng)用已經(jīng)非常龐大了,當多個團隊都開始對其進行改動時,可真是相當?shù)牟环奖悖瑥?fù)用性也相當糟糕,基本是每個團隊都做了或多或少重復(fù)的事情,而且部署和維護也是相當?shù)穆闊驗辇嫶蟮膽?yīng)用包在N臺機器上復(fù)制、啟動都需要耗費不少的時間,出問題的時候也不是很好查,另外一個更糟糕的狀況是很有可能會出現(xiàn)某個應(yīng)用上的bug就導(dǎo)致了全站都不可用,還有其他的像調(diào)優(yōu)不好操作(因為機器上部署的應(yīng)用什么都要做,根本就無法進行針對性的調(diào)優(yōu))等因素,根據(jù)這樣的分析,開始痛下決心,將系統(tǒng)根據(jù)職責進行拆分,于是一個大型的分布式應(yīng)用就誕生了,通常,這個步驟需要耗費相當長的時間,因為會碰到很多的挑戰(zhàn):
1、拆成分布式后需要提供一個高性能、穩(wěn)定的通信框架,并且需要支持多種不同的通信和遠程調(diào)用方式;
2、將一個龐大的應(yīng)用拆分需要耗費很長的時間,需要進行業(yè)務(wù)的整理和系統(tǒng)依賴關(guān)系的控制等;
3、如何運維(依賴管理、運行狀況管理、錯誤追蹤、調(diào)優(yōu)、監(jiān)控和報警等)好這個龐大的分布式應(yīng)用。
經(jīng)過這一步,差不多系統(tǒng)的架構(gòu)進入相對穩(wěn)定的階段,同時也能開始采用大量的廉價機器來支撐著巨大的訪問量和數(shù)據(jù)量,結(jié)合這套架構(gòu)以及這么多次演變過程吸取的經(jīng)驗來采用其他各種各樣的方法來支撐著越來越高的訪問量。看看這一步完成后系統(tǒng)的圖示:
<!--[if !vml]-->
<!--[endif]-->
這一步涉及到了這些知識體系:
這一步涉及的知識體系非常的多,要求對通信、遠程調(diào)用、消息機制等有深入的理解和掌握,要求的都是從理論、硬件級、操作系統(tǒng)級以及所采用的語言的實現(xiàn)都有清楚的理解。
運維這塊涉及的知識體系也非常的多,多數(shù)情況下需要掌握分布式并行計算、報表、監(jiān)控技術(shù)以及規(guī)則策略等等。
說起來確實不怎么費力,整個網(wǎng)站架構(gòu)的經(jīng)典演變過程都和上面比較的類似,當然,每步采取的方案,演變的步驟有可能有不同,另外,由于網(wǎng)站的業(yè)務(wù)不同,會有不同的專業(yè)技術(shù)的需求,這篇blog更多的是從架構(gòu)的角度來講解演變的過程,當然,其中還有很多的技術(shù)也未在此提及,像數(shù)據(jù)庫集群、數(shù)據(jù)挖掘、搜索等,但在真實的演變過程中還會借助像提升硬件配置、網(wǎng)絡(luò)環(huán)境、改造操作系統(tǒng)、CDN鏡像等來支撐更大的流量,因此在真實的發(fā)展過程中還會有很多的不同,另外一個大型網(wǎng)站要做到的遠遠不僅僅上面這些,還有像安全、運維、運營、服務(wù)、存儲等,要做好一個大型的網(wǎng)站真的很不容易,寫這篇文章更多的是希望能夠引出更多大型網(wǎng)站架構(gòu)演變的介紹,:)。
posted on 2009-05-04 16:29
肖馬輝
閱讀(209)
評論(0)
編輯
收藏
新用戶注冊
刷新評論列表
只有注冊用戶
登錄
后才能發(fā)表評論。
網(wǎng)站導(dǎo)航:
博客園
IT新聞
Chat2DB
C++博客
博問
管理
Powered by:
BlogJava
Copyright © 肖馬輝
主站蜘蛛池模板:
亚洲日韩中文字幕在线播放
|
韩国亚洲伊人久久综合影院
|
亚洲乱码中文字幕小综合
|
亚洲无人区码一二三码区别图片
|
国产免费牲交视频免费播放
|
97av免费视频
|
亚洲精品国产日韩无码AV永久免费网
|
久久久国产精品亚洲一区
|
免费一级全黄少妇性色生活片
|
亚洲美女视频免费
|
在线观看无码AV网站永久免费
|
色偷偷尼玛图亚洲综合
|
男人免费视频一区二区在线观看
|
国产免费看插插插视频
|
亚洲成人福利在线观看
|
免费观看在线禁片
|
亚洲精品高清一二区久久
|
一级黄色片免费观看
|
国产一级一片免费播放
|
人妻仑刮八A级毛片免费看
|
国产精品亚洲不卡一区二区三区
|
亚洲av无码一区二区三区人妖
|
国产亚洲精品国产
|
老司机免费午夜精品视频
|
aa级一级天堂片免费观看
|
亚洲欧美成人一区二区三区
|
114一级毛片免费
|
亚洲日韩在线中文字幕第一页
|
成在线人视频免费视频
|
亚洲精品色婷婷在线影院
|
精品免费视在线观看
|
中文字幕乱码亚洲无线三区
|
久久精品a一国产成人免费网站
|
久久亚洲AV成人无码
|
少妇人妻偷人精品免费视频
|
亚洲V无码一区二区三区四区观看
|
天黑黑影院在线观看视频高清免费
|
精品日韩亚洲AV无码一区二区三区
|
免费黄色网址入口
|
亚洲精品中文字幕
|
亚洲av女电影网
|