大型系統(tǒng)架構(gòu)簡(jiǎn)介

1、=WEB程序的架構(gòu)基本上可以分成以下三類(lèi):(一 基于“WEB頁(yè)面/文件”,例如CGI和PHP/ASP程序。程序的文件分別存儲(chǔ)在不同的目錄里,與URL相對(duì)應(yīng)。當(dāng)HTTP請(qǐng)求提交至服務(wù)器時(shí),URL直接指向某個(gè)文件,然后由該文件來(lái)處理請(qǐng)求,并返回響應(yīng)結(jié)果。可以想像,我們?cè)谡军c(diǎn)根目錄的news目錄下放置一個(gè)readnews.php文件。這種開(kāi)發(fā)方式最自然,最易理解,也是PHP最常用的方式。要注意產(chǎn)生的URL對(duì)搜索引擎不友好,不過(guò)你可以用服務(wù)器提供的URL重寫(xiě)方案來(lái)處理,例如Apache的mod_rewrite。(二 基于“動(dòng)作”(Action。這是MVC架構(gòu)的WEB程序所采用的最常見(jiàn)的方式。目前主流的

2、WEB 框架像Struts、Webwork(Java,Ruby on Rails(Ruby,Zend Framework(PHP等都采用這種設(shè)計(jì)。URL 映射到控制器(controller和控制器中的動(dòng)作(action,由action來(lái)處理請(qǐng)求并輸出響應(yīng)結(jié)果。這種設(shè)計(jì)和上面的基于文件的方式一樣,都是請(qǐng)求/響應(yīng)驅(qū)動(dòng)的方案,離不開(kāi)HTTP?？梢韵胂裨趯?shí)際代碼中,我們會(huì)有一個(gè)控制器newsController,其中有一個(gè)readAction。不同框架可能默認(rèn)實(shí)現(xiàn)方式稍有不同,有的是一個(gè)Controller一個(gè)文件,其中有多個(gè)Action,有的是每個(gè)Action一個(gè)文件。當(dāng)然這些你都可以自己控制,題外

3、話(huà)。這種方式的URL通常都很漂亮,對(duì)搜索引擎友好,因?yàn)楹芏嗫蚣芏甲詭в蠻RL重寫(xiě)功能。可以自由規(guī)定URL中controller、action及參數(shù)出現(xiàn)的位置。另外,還有更直接的基于URL的設(shè)計(jì)方案,那就是REST。通過(guò)人為規(guī)定URL的構(gòu)成形式(比如Action 限制成只有幾種來(lái)促進(jìn)網(wǎng)站之間的互相訪(fǎng)問(wèn),降低開(kāi)發(fā)的復(fù)雜性,提高系統(tǒng)的可伸縮性。REST對(duì)于Web Services來(lái)說(shuō)是一個(gè)創(chuàng)新。雖然本文討論的是單個(gè)項(xiàng)目所采用的架構(gòu),而REST是為了解決網(wǎng)站之間的通訊問(wèn)題,但REST的出現(xiàn),會(huì)對(duì)單個(gè)項(xiàng)目的架構(gòu)造成影響(很顯然你在開(kāi)發(fā)時(shí)就要構(gòu)造規(guī)范的URL。將來(lái)混用REST和MVC應(yīng)該也是一種趨勢(shì)。Ro

4、R提供很好的REST支持,Zend Framework也提供了Zend_Rest來(lái)支持REST,包括Server和Client。(三 基于“組件”(Component ,GUI設(shè)計(jì)也常稱(chēng)控件、事件驅(qū)動(dòng)的架構(gòu),最常見(jiàn)的是微軟的.NET?；舅枷胧前殉绦蚍殖珊芏嘟M件,每個(gè)組件都可以觸發(fā)事件,調(diào)用特定的事件處理器來(lái)處理(比如在一個(gè)HTML按鈕上設(shè)置onClick事件鏈接到一個(gè)PHP函數(shù)。這種設(shè)計(jì)遠(yuǎn)離HTTP,HTTP 請(qǐng)求完全抽象,映射到一個(gè)事件。事實(shí)上這種設(shè)計(jì)原本最常應(yīng)用于傳統(tǒng)桌面GUI程序的開(kāi)發(fā),例如Delphi,Java Swing等。所有表現(xiàn)層的組件比如窗口,或者HTML表單都可以由IDE來(lái)

5、提供,我們只需要在IDE里點(diǎn)擊或拖動(dòng)鼠標(biāo)就能夠自動(dòng)添加一個(gè)組件,并且添加一個(gè)相應(yīng)的事件處理器。這種開(kāi)發(fā)方式有幾個(gè)優(yōu)點(diǎn):復(fù)用性-代碼高度可重用。易于使用-通常只需要配置控件的屬性,編寫(xiě)相關(guān)的事件處理函數(shù)。我個(gè)人也挺喜歡這種方式,PEAR就提供了相當(dāng)強(qiáng)大的HTML_QuickForm,用于在頁(yè)面添加表單元素及其事件處理函數(shù),還可以與Smarty等模板引擎相結(jié)合。這對(duì)于項(xiàng)目開(kāi)發(fā)來(lái)說(shuō)是一個(gè)補(bǔ)充性的功能,在項(xiàng)目中的某些部份使用QuickForm,有時(shí)可以大大加快開(kāi)發(fā)。而完全基于組件和事件驅(qū)動(dòng)的開(kāi)發(fā)框架對(duì)于PHP來(lái)說(shuō)也已經(jīng)不新鮮,PRADO就是一個(gè)這樣的框架,曾經(jīng)得過(guò)Zend編程大賽的頭獎(jiǎng)。但目前來(lái)說(shuō)很顯

6、然Prado所提倡的這種開(kāi)發(fā)方式仍然沒(méi)有被大部份PHP程序員所接受。為什么呢?= 大型WEB系統(tǒng)架構(gòu)設(shè)計(jì)的總結(jié)博客分類(lèi):Java相關(guān)總結(jié)一下自己對(duì)大型WEB系統(tǒng)架構(gòu)設(shè)計(jì)的想法:1. 一般大型WEB系統(tǒng)的兩個(gè)共通點(diǎn):1海量的web訪(fǎng)問(wèn)(以?xún)|為單位的PV2系統(tǒng)需要保存海量數(shù)據(jù),這些數(shù)據(jù)被頻繁訪(fǎng)問(wèn)2. 前端負(fù)載均衡考慮:1DNS負(fù)載均衡為一個(gè)DNS關(guān)聯(lián)多個(gè)服務(wù)器的IP地址,當(dāng)客戶(hù)端發(fā)起DNS查詢(xún)時(shí),對(duì)于同一DNS,不同的客戶(hù)端得到不同的服務(wù)器IP地址,從而達(dá)到負(fù)載均衡的目的。DNS負(fù)載均衡有一個(gè)問(wèn)題,就是沒(méi)有考慮容錯(cuò),如果后臺(tái)的某臺(tái)Web服務(wù)器出現(xiàn)故障,DNS服務(wù)器仍然會(huì)把DNS 請(qǐng)求分配到這臺(tái)故障

7、服務(wù)器上,導(dǎo)致不能響應(yīng)客戶(hù)端。即使及時(shí)修改了dns設(shè)置,還是要等待足夠的時(shí)間(刷新時(shí)間才能發(fā)揮作用,在此期間保存了故障服務(wù)器地址的客戶(hù)計(jì)算機(jī)將不能正常訪(fǎng)問(wèn)服務(wù)器。2IP負(fù)載均衡基于LVS的3種實(shí)現(xiàn)。LVS-NAT:把用戶(hù)請(qǐng)求報(bào)文中目的ip地址改為內(nèi)網(wǎng)的web服務(wù)器地址后發(fā)送到內(nèi)網(wǎng)的web服務(wù)器上。在把內(nèi)網(wǎng)web服務(wù)器上響應(yīng)報(bào)文的原地址改為NAT服務(wù)器的地址。據(jù)說(shuō)LVS-NAT的擴(kuò)充能力有限,當(dāng)服務(wù)器結(jié)點(diǎn)數(shù)目升到20時(shí),LVS主機(jī)本身有可能成為系統(tǒng)的新瓶頸,因?yàn)樵贚VS-NAT中請(qǐng)求和響應(yīng)封包都需要通過(guò)均衡服務(wù)器(LVS主機(jī)/Director。LVS-TUN:均衡服務(wù)器把從客戶(hù)端收到的報(bào)文再用i

8、p進(jìn)行封裝,然后將報(bào)文通過(guò)IP隧道傳遞到其中某個(gè)web服務(wù)器上,真正的web服務(wù)器處理請(qǐng)求,并將response直接回復(fù)給發(fā)起請(qǐng)求的客戶(hù)端。這種做法的好處是真正的web服務(wù)器可以不和均衡服務(wù)器在一個(gè)網(wǎng)絡(luò)內(nèi),且不需要通過(guò)均衡服務(wù)器轉(zhuǎn)發(fā)response給客戶(hù)端,性能較NAT好,但需要真正的web服務(wù)器支持IP Tunneling(一般Linux都支持。LVS-DR:讓均衡服務(wù)器和實(shí)際后端web服務(wù)器擁有相同別名的IP地址,均衡服務(wù)器只需要修改MAC地址,然后將客戶(hù)端請(qǐng)求分發(fā)到不同的后端web服務(wù)器上。這種模式,客戶(hù)的請(qǐng)求報(bào)文是通過(guò)均衡服務(wù)器,但響應(yīng)的response就直接發(fā)往客戶(hù),且沒(méi)有IP Tu

9、nneling的開(kāi)銷(xiāo),所以在3種負(fù)載均衡方案中,效率最高,但必須要求均衡服務(wù)器(Director與后端web服務(wù)器(Real Server都有一塊網(wǎng)卡連在同一物理網(wǎng)段上。3. 前端異步處理:1異步servlet的引入Web2.0,Ajax技術(shù)的大量使用,產(chǎn)生了海量的響應(yīng)時(shí)間要求不高的數(shù)據(jù)請(qǐng)求。對(duì)于這種情況,采用JEE6的異步servelt可以解決這個(gè)問(wèn)題。2Asynchrony Everywhere通過(guò)JMS,分離前端和后端處理。4. 分布式緩存:高訪(fǎng)問(wèn)的數(shù)據(jù)放到分布式緩存中,memcached、TT、hazelcast.5. 數(shù)據(jù)庫(kù)的考慮:1主從復(fù)制這種模式下,需要考慮讀寫(xiě)分離,也就是說(shuō)讓寫(xiě)

10、操作要作用在主數(shù)據(jù)庫(kù)上。2垂直分區(qū)將不同類(lèi)型的數(shù)據(jù),存儲(chǔ)在不同的數(shù)據(jù)庫(kù)中,方便上層業(yè)務(wù)模塊在部署上的分離。3水平分區(qū)將同一個(gè)表的數(shù)據(jù),通過(guò)某種算法分布到不同的數(shù)據(jù)庫(kù)中。= web架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)分享本人作為一位web工程師,著眼最多之處莫過(guò)于性能與架構(gòu),本次幸得參與sd2.0大會(huì),得以與同行廣泛交流,于此二方面,有些心得,不敢獨(dú)享,與眾博友分享,本文是這次參會(huì)與眾同撩交流的心得,有興趣者可以查看視頻架構(gòu)設(shè)計(jì)的幾個(gè)心得:一,不要過(guò)設(shè)計(jì):never over design這是一個(gè)常常被提及的話(huà)題,但是只要想想你的架構(gòu)里有多少功能是根本沒(méi)有用到,或者最后廢棄的,就能明白其重要性了,初涉架構(gòu)設(shè)計(jì),往往傾向

11、于設(shè)計(jì)大而化一的架構(gòu),希望設(shè)計(jì)出具有無(wú)比擴(kuò)展性,能適應(yīng)一切需求的增加架構(gòu),web開(kāi)發(fā)領(lǐng)域是個(gè)非常動(dòng)態(tài)的過(guò)程,我們很難預(yù)測(cè)下個(gè)星期的變化,而又需要對(duì)變化做出最快最有效的響應(yīng)。ebay的工程師說(shuō)過(guò),他們的架構(gòu)設(shè)計(jì)從來(lái)都不能滿(mǎn)足系統(tǒng)的增長(zhǎng),所以他們的系統(tǒng)永遠(yuǎn)都在推翻重做。請(qǐng)注意,不是ebay架構(gòu)師的能力有問(wèn)題,他們?cè)O(shè)計(jì)的架構(gòu)總是建立舊版本的瓶頸上,希望通過(guò)新的架構(gòu)帶來(lái)突破,然而新架構(gòu)帶來(lái)的突破總是在很短的時(shí)間內(nèi)就被新增需求淹沒(méi),于是他們不得不又使用新的架構(gòu)web開(kāi)發(fā),是個(gè)非常敏捷的過(guò)程,變化隨時(shí)都在產(chǎn)生,用戶(hù)需求千變?nèi)f化,許多方面偶然性非常高,較之軟件開(kāi)發(fā),希望用一個(gè)架構(gòu)規(guī)劃以后的所有設(shè)計(jì),是不現(xiàn)實(shí)

12、的二,web架構(gòu)生命周期:web architectures life cycle既然要杜絕過(guò)設(shè)計(jì),又要保證一定的前瞻性,那么怎么才能找到其中的平衡呢?希望下面的web架構(gòu)生命周期能夠幫到你 設(shè)計(jì)的架構(gòu)需要在1-10倍的增長(zhǎng)下,通過(guò)簡(jiǎn)單的增加硬件容量就能夠勝任,而在5-10倍的增長(zhǎng)期間,請(qǐng)著手下一個(gè)版本的架構(gòu)設(shè)計(jì),使之能承受下一個(gè)10倍間的增長(zhǎng)google之所以能夠稱(chēng)霸,不完全是因?yàn)樗阉骷夹g(shù)和排序技術(shù)有多先進(jìn),其實(shí)包括baidu和yahoo,所使用的技術(shù)現(xiàn)在也已經(jīng)大同小異,然而,google能在一個(gè)月內(nèi)通過(guò)增加上萬(wàn)臺(tái)服務(wù)器來(lái)達(dá)到足夠系統(tǒng)容量的能力確是很難被復(fù)制的三,緩存:Cache空間換取時(shí)間

13、,緩存永遠(yuǎn)計(jì)算機(jī)設(shè)計(jì)的重中之重,從cpu到io,到處都可以看到緩存的身影,web架構(gòu)設(shè)計(jì)重,緩存設(shè)計(jì)必不可少,關(guān)于怎樣設(shè)計(jì)合理的緩存,jbosscache的創(chuàng)始人,淘寶的創(chuàng)始人是這樣說(shuō)的:其實(shí)設(shè)計(jì)web 緩存和企業(yè)級(jí)緩存是非常不同的,企業(yè)級(jí)緩存偏重于邏輯,而web緩存,簡(jiǎn)單快速為好。緩存帶來(lái)的問(wèn)題是什么?是程序的復(fù)雜度上升,因?yàn)閿?shù)據(jù)散布在多個(gè)進(jìn)程,所以同步就是一個(gè)麻煩的問(wèn)題,加上集群,復(fù)雜度會(huì)進(jìn)一步提高,在實(shí)際運(yùn)用中,采用怎樣的同步策略常常需要和業(yè)務(wù)綁定老錢(qián)為搜狐設(shè)計(jì)的帖子設(shè)計(jì)了鏈表緩存,這樣既可以滿(mǎn)足靈活插入的需要,又能夠快速閱讀,而其他一些大型社區(qū)也經(jīng)常采用類(lèi)此的結(jié)構(gòu)來(lái)優(yōu)化帖子列表,mem

14、cache也是一個(gè)常常用到的工具Cache的常用的策略是:讓數(shù)據(jù)在內(nèi)存中,而不是在比較耗時(shí)的磁盤(pán)上。從這個(gè)角度講,mysql提供的heap 引擎(存儲(chǔ)方式也是一個(gè)值得思考的方法,這種存儲(chǔ)方法可以把數(shù)據(jù)存儲(chǔ)在內(nèi)存中,并且保留sql強(qiáng)大的查詢(xún)能力,是不是一舉兩得呢?我們這里只說(shuō)到了讀緩存,其實(shí)還有一種寫(xiě)緩存,在以?xún)?nèi)容為主的社區(qū)里比較少用到,因?yàn)檫@樣的社區(qū)最主要需要解決的問(wèn)題是讀問(wèn)題,但是在處理能力低于請(qǐng)求能力時(shí),或者單個(gè)希望請(qǐng)求先被緩存形成塊,然后批量處理時(shí),寫(xiě)緩存就出現(xiàn)了,在交互性很強(qiáng)的社區(qū)設(shè)計(jì)里我們很容易找到這樣的緩存四,核心模塊一定要自己開(kāi)發(fā):DIY your core module這點(diǎn)我們

15、是深有體會(huì),錢(qián)宏武和云風(fēng)也都有談到,我們經(jīng)常傾向于使用一些開(kāi)源模塊,如果不涉及核心模塊,確實(shí)是可以的,如果涉及,那么就要小心了,因?yàn)楫?dāng)訪(fǎng)問(wèn)量達(dá)到一定的程度,這些模塊往往都有這樣那樣的問(wèn)題,當(dāng)然我們可以把問(wèn)題歸結(jié)為對(duì)開(kāi)源的模塊不熟悉,但是不管怎樣,核心出現(xiàn)問(wèn)題的時(shí)候,不能完全掌握其代碼是非常可怕的五,合理選擇數(shù)據(jù)存儲(chǔ)方式:reasonable data storage我們一定要使用數(shù)據(jù)庫(kù)嗎,不一定,雷鳴告訴我們搜索不一定需要數(shù)據(jù)庫(kù),云風(fēng)告訴我們,游戲不一定需要數(shù)據(jù)庫(kù),那么什么時(shí)候我們才需要數(shù)據(jù)庫(kù)呢,為什么不干脆用文件來(lái)代替他呢?首先我們需要先承認(rèn),數(shù)據(jù)庫(kù)也是對(duì)文件進(jìn)行操作。我們需要數(shù)據(jù)庫(kù),主要是

16、使用下面這幾個(gè)功能,一個(gè)是數(shù)據(jù)存儲(chǔ),一個(gè)是數(shù)據(jù)檢索,在關(guān)系數(shù)據(jù)庫(kù)中,我們其實(shí)非常在乎數(shù)據(jù)庫(kù)的復(fù)雜搜索的能力,看看一個(gè)統(tǒng)計(jì)用的tsql 就知道了(不用仔細(xì)讀,掃一眼就可以了select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id from review where Reviewid=a.Id as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and a.Cr

17、eativity_Class=c.Id and a.Creativity_Class_2=d.Idselect a.Id,max(c.Class_name,(max(d.Class_name_2,max(a.Creativity_Title,max(b.User_na me,count(e.Id as countNum from Creativity as a,User_info as b,class as c,cla ss2 as d,review as e where a.user_id=b.id and a.Creativity_Class=c.Id and a.C reativity_

18、Class_2=d.Id and a.Id=e.Reviewid group by a.Id . .我們可以看出需要數(shù)據(jù)庫(kù)關(guān)聯(lián),排序的能力,這個(gè)能力在某些情況下非常重要,但是如果你的網(wǎng)站的常規(guī)操作,全是這樣復(fù)雜的邏輯,那效率一定是非常低的,所以我們常常在數(shù)據(jù)庫(kù)里加入許多冗余字段,來(lái)減小簡(jiǎn)單查詢(xún)時(shí)關(guān)聯(lián)等操作帶來(lái)的壓力,我們看看下面這張圖,可以看到數(shù)據(jù)庫(kù)的設(shè)計(jì)重心,和網(wǎng)站(指內(nèi)容型社區(qū)需要面對(duì)的問(wèn)題實(shí)際是有一些偏差的 同樣其他一些軟件產(chǎn)品也遇到同樣的問(wèn)題所以具我了解,有許多特殊的運(yùn)用都有自己設(shè)計(jì)的特殊數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)與方法,比如有的大型服務(wù)程序采取樹(shù)形數(shù)據(jù)存儲(chǔ)結(jié)構(gòu),lucene使用文件來(lái)存儲(chǔ)索引和文件

19、從另外一個(gè)角度上看,使用數(shù)據(jù)庫(kù),意味著數(shù)據(jù)和表現(xiàn)是完全分離的(這當(dāng)然是經(jīng)典的設(shè)計(jì)思路,也就是說(shuō)當(dāng)需要展示數(shù)據(jù)時(shí),不得不需要一個(gè)轉(zhuǎn)換的過(guò)程,也可以說(shuō)是綁定的過(guò)程,當(dāng)網(wǎng)站具備一定規(guī)模的時(shí)候,數(shù)據(jù)庫(kù)往往成為效率的瓶頸,所以許多網(wǎng)站也采用直接書(shū)寫(xiě)靜態(tài)文件的方法來(lái)避免讀取操作時(shí)的綁定這并不是說(shuō)我們從今天起就可以把我們親愛(ài)的數(shù)據(jù)庫(kù)打入冷宮,而是我們?cè)谠O(shè)計(jì)數(shù)據(jù)的持久化時(shí),需要根據(jù)實(shí)際情況來(lái)選擇存儲(chǔ)方式,而數(shù)據(jù)庫(kù)不過(guò)是其中一個(gè)選項(xiàng)六,搞清楚誰(shuí)是最重要的人:who's the most important guy在用例需求分析的時(shí)候常常講到涉眾,就是和你的設(shè)計(jì)息息相關(guān)的人,在web中我們一定以為最重要的

20、涉眾莫過(guò)于用戶(hù)了。,在一個(gè)傳統(tǒng)的互動(dòng)社區(qū)開(kāi)發(fā)中,最重要的東西是內(nèi)容,用戶(hù)產(chǎn)生內(nèi)容,所以用戶(hù)就是上帝,至于內(nèi)容挑選工具,不就是給坐我后面三排的妹妹們用的嗎?湊或行了,實(shí)在有問(wèn)題我就在數(shù)據(jù)里手動(dòng)幫你加得了。這大概是眼下許多小型甚至中型網(wǎng)站技術(shù)人員的普遍想法。錢(qián)宏武在他的講座里談到了這個(gè)問(wèn)題:實(shí)際上網(wǎng)站每天產(chǎn)生的內(nèi)容非常的多,普通人是不可能看完的,而編輯負(fù)責(zé)把精華的內(nèi)容推薦到首頁(yè)上,所以很多用戶(hù)讀到的內(nèi)容其實(shí)都依賴(lài)于編輯的推薦,所以設(shè)計(jì)讓編輯工作方便的工具也是非常重要,有時(shí)甚至是最重要的。七,不要執(zhí)著于文檔:don't be crazy about documentweb開(kāi)發(fā)的文檔重要嗎?什

21、么文檔最重要?我的看法是web開(kāi)發(fā)中交流>文檔,現(xiàn)在大的軟件公司比較流行的做法是:注重產(chǎn)品設(shè)計(jì)文檔,在這種方法里,產(chǎn)品文檔非常詳盡,并且沒(méi)有歧義,開(kāi)發(fā)人員基于設(shè)計(jì)文檔開(kāi)發(fā),測(cè)試人員基于設(shè)計(jì)文檔制定測(cè)試方案,任何新人都可以通過(guò)閱讀產(chǎn)品設(shè)計(jì)文檔來(lái)了解項(xiàng)目的概況而web項(xiàng)目從概念到實(shí)現(xiàn)的時(shí)間是非常短的,而且越短越好,并且由于變化迅速,要想寫(xiě)出完整的產(chǎn)品和需求文檔是幾乎不可能的,大多數(shù)情況是等你寫(xiě)出完備的文檔,項(xiàng)目早就是另外一個(gè)樣子,但是沒(méi)有文檔的問(wèn)題是,如果團(tuán)隊(duì)發(fā)生變化,添加新成員怎樣才能了解軟件的結(jié)構(gòu)和概念呢,一種是每個(gè)人都了解軟件的整個(gè)結(jié)構(gòu),除非你的團(tuán)隊(duì)整體消失,否則任何一個(gè)人都能夠擔(dān)當(dāng)培

22、養(yǎng)新人的責(zé)任,這種face2face交流比文檔有效率很多。于是就有了前office開(kāi)發(fā)者,現(xiàn)任yahoo中國(guó)某產(chǎn)品開(kāi)發(fā)負(fù)責(zé)人的劉振飛所感覺(jué)到的落差,他說(shuō),我們的項(xiàng)目是吵出來(lái)的,我聽(tīng)完會(huì)心一笑八,團(tuán)隊(duì):team不要專(zhuān)家團(tuán)隊(duì),而要外科手術(shù)式的團(tuán)隊(duì),你的團(tuán)隊(duì)里一定要有清道夫,需要有弓箭手,讓他們和項(xiàng)目一起成長(zhǎng),才是項(xiàng)目負(fù)責(zé)人的最大成就總結(jié):0架構(gòu)是一種權(quán)衡 1web開(kāi)發(fā)的特點(diǎn)是是:沒(méi)有太復(fù)雜的技術(shù)難點(diǎn),一切在于迅速的把握需求,其實(shí)這正式敏捷開(kāi)發(fā)的要旨所在,一切都可以非常快速的建立,非?？焖俚闹貥?gòu),我們的開(kāi)發(fā)工具,底層庫(kù)和框架,包括搜索引擎和web文檔提供的幫助,都提我們供給了敏捷的能力。2此外,相應(yīng)

23、的,最有效率的交流方式必須留給web開(kāi)發(fā),那就是face2face(面對(duì)面,不要太擔(dān)心你的設(shè)計(jì)不能被完備的文檔所保留下來(lái),他們會(huì)以交流,代碼和小卡片的方式保存下來(lái)3人的因素會(huì)更加重要,無(wú)論是對(duì)用戶(hù)的需求,還是開(kāi)發(fā)人員的素質(zhì)。另:有關(guān)web效率,有著名的14條規(guī)則,由yahoo性能效率小組所總結(jié),并廣為流傳。業(yè)已出現(xiàn)相關(guān)插件(YSlow,針對(duì)具體網(wǎng)頁(yè)按彼規(guī)則評(píng)分,這次該小組負(fù)責(zé)人Tenni Theurer也受邀來(lái)到此次大會(huì),我把Tenni小姐(之前真的沒(méi)有想到她是個(gè)女孩,并且如此年輕和她的團(tuán)隊(duì)的14 rules列在下面Make Fewer HTTP RequestsUse a Content D

24、elivery NetworkAdd an Expires HeaderGzip ComponentsPut CSS at the TopMove Scripts to the BottomAvoid CSS ExpressionsMake JavaScript and CSS ExternalReduce DNS LookupsMinify JavaScriptAvoid RedirectsRemove Duplicate ScriptsConfigure ETagsMake Ajax Cacheable通過(guò)安裝firebug和YSlow這兩個(gè)firefox插件(請(qǐng)注意要先安裝firebug

25、再安裝yslow,下載后拖動(dòng)到firefox里即可我們可以看到你的網(wǎng)頁(yè)根據(jù)下面的規(guī)則的評(píng)分,這是我在博客園博客首頁(yè)的評(píng)分截圖,上面D表示總分,下面是單項(xiàng)評(píng)分,A最好F最差,不知道還有沒(méi)有G :=置頂淺談大型web系統(tǒng)架構(gòu)分類(lèi):大規(guī)模Web 2.0架構(gòu)2011-10-11 18:27 8909人閱讀評(píng)論(4 收藏舉報(bào)web服務(wù)器負(fù)載均衡數(shù)據(jù)庫(kù)緩存系統(tǒng)目錄(?+動(dòng)態(tài)應(yīng)用,是相對(duì)于網(wǎng)站靜態(tài)內(nèi)容而言,是指以c/c+、php、Java、perl、.net等服務(wù)器端語(yǔ)言開(kāi)發(fā)的網(wǎng)絡(luò)應(yīng)用軟件,比如論壇、網(wǎng)絡(luò)相冊(cè)、交友、BLOG等常見(jiàn)應(yīng)用。動(dòng)態(tài)應(yīng)用系統(tǒng)通常與數(shù)據(jù)庫(kù)系統(tǒng)、緩存系統(tǒng)、分布式存儲(chǔ)系統(tǒng)等密不可分。大型動(dòng)

26、態(tài)應(yīng)用系統(tǒng)平臺(tái)主要是針對(duì)于大流量、高并發(fā)網(wǎng)站建立的底層系統(tǒng)架構(gòu)。大型網(wǎng)站的運(yùn)行需要一個(gè)可靠、安全、可擴(kuò)展、易維護(hù)的應(yīng)用系統(tǒng)平臺(tái)做為支撐,以保證網(wǎng)站應(yīng)用的平穩(wěn)運(yùn)行。大型動(dòng)態(tài)應(yīng)用系統(tǒng)又可分為幾個(gè)子系統(tǒng):1Web前端系統(tǒng)2負(fù)載均衡系統(tǒng)3數(shù)據(jù)庫(kù)集群系統(tǒng)4緩存系統(tǒng)5分布式存儲(chǔ)系統(tǒng)6分布式服務(wù)器管理系統(tǒng)7代碼分發(fā)系統(tǒng)Web前端系統(tǒng)結(jié)構(gòu)圖: 為了達(dá)到不同應(yīng)用的服務(wù)器共享、避免單點(diǎn)故障、集中管理、統(tǒng)一配置等目的,不以應(yīng)用劃分服務(wù)器,而是將所有服務(wù)器做統(tǒng)一使用,每臺(tái)服務(wù)器都可以對(duì)多個(gè)應(yīng)用提供服務(wù),當(dāng)某些應(yīng)用訪(fǎng)問(wèn)量升高時(shí),通過(guò)增加服務(wù)器節(jié)點(diǎn)達(dá)到整個(gè)服務(wù)器集群的性能提高,同時(shí)使他應(yīng)用也會(huì)受益。該Web前端系統(tǒng)基于A

27、pache/Lighttpd/Eginx等的虛擬主機(jī)平臺(tái),提供PHP程序運(yùn)行環(huán)境。服務(wù)器對(duì)開(kāi)發(fā)人員是透明的,不需要開(kāi)發(fā)人員介入服務(wù)器管理負(fù)載均衡系統(tǒng) 負(fù)載均衡系統(tǒng)分為硬件和軟件兩種。硬件負(fù)載均衡效率高,但是價(jià)格貴,比如F5等。軟件負(fù)載均衡系統(tǒng)價(jià)格較低或者免費(fèi),效率較硬件負(fù)載均衡系統(tǒng)低,不過(guò)對(duì)于流量一般或稍大些網(wǎng)站來(lái)講也足夠使用,比如lvs, nginx。大多數(shù)網(wǎng)站都是硬件、軟件負(fù)載均衡系統(tǒng)并用。數(shù)據(jù)庫(kù)集群系統(tǒng)結(jié)構(gòu)圖: 由于 Web 前端采用了負(fù)載均衡集群結(jié)構(gòu)提高了服務(wù)的有效性和擴(kuò)展性, 因此數(shù)據(jù)庫(kù)必須也是高可靠的, 才能保證整個(gè)服務(wù)體系的高可靠性,如何構(gòu)建一個(gè)高可靠的、可以提供大規(guī)模并發(fā)處理的

28、數(shù)據(jù)庫(kù)體系? 我們可以采用如上圖所示的方案:1 使用 MySQL 數(shù)據(jù)庫(kù), 考慮到 Web 應(yīng)用的數(shù)據(jù)庫(kù)讀多寫(xiě)少的特點(diǎn), 我們主要對(duì)讀數(shù)據(jù)庫(kù)做了優(yōu)化, 提供專(zhuān)用的讀數(shù)據(jù)庫(kù)和寫(xiě)數(shù)據(jù)庫(kù),在應(yīng)用程序中實(shí)現(xiàn)讀操作和寫(xiě)操作分別訪(fǎng)問(wèn)不同的數(shù)據(jù)庫(kù)。2 使用 MySQL Replication 機(jī)制實(shí)現(xiàn)快速將主庫(kù)(寫(xiě)庫(kù)的數(shù)據(jù)庫(kù)復(fù)制到從庫(kù)(讀庫(kù)。一個(gè)主庫(kù) 對(duì)應(yīng)多個(gè)從庫(kù),主庫(kù)數(shù)據(jù)實(shí)時(shí)同步到從庫(kù)。3 寫(xiě)數(shù)據(jù)庫(kù)有多臺(tái), 每臺(tái)都可以提供多個(gè)應(yīng)用共同使用, 這樣可以解決寫(xiě)庫(kù)的性能瓶頸問(wèn)題和單點(diǎn)故 障問(wèn)題。4 讀數(shù)據(jù)庫(kù)有多臺(tái),通過(guò)負(fù)載均衡設(shè)備實(shí)現(xiàn)負(fù)載均衡,從而達(dá)到讀數(shù)據(jù)庫(kù)的高性能、高可靠和高可擴(kuò) 展性。5 數(shù)據(jù)庫(kù)服務(wù)器和應(yīng)

29、用服務(wù)器分離。6 從數(shù)據(jù)庫(kù)使用 BigIP 做負(fù)載均衡。緩存系統(tǒng)緩存分為文件緩存、內(nèi)存緩存、數(shù)據(jù)庫(kù)緩存。在大型 Web 應(yīng)用中使用最多且效率最高的是內(nèi)存緩存。 最常用的內(nèi)存緩存工具是 Memcached 。使用正確的緩存系統(tǒng)可以達(dá)到實(shí)現(xiàn)以下目標(biāo):1、使用緩存系統(tǒng)可以提高訪(fǎng)問(wèn)效率,提高服務(wù)器吞吐能力,改善用戶(hù)體驗(yàn)。2、減輕對(duì)數(shù)據(jù)庫(kù)及存儲(chǔ)集服務(wù)器的訪(fǎng)問(wèn)壓力。3、 Memcached 服務(wù)器有多臺(tái),避免單點(diǎn)故障,提供高可靠性和可擴(kuò)展性,提高性能。分布式存儲(chǔ)系統(tǒng) 結(jié)構(gòu)圖:Web 系統(tǒng)平臺(tái)中的存儲(chǔ)需求有下面兩個(gè)特點(diǎn):1 存儲(chǔ)量很大,經(jīng)常會(huì)達(dá)到單臺(tái)服務(wù)器無(wú)法提供的規(guī)模,比如相冊(cè)、視頻等應(yīng)用。因此需要專(zhuān)業(yè)的

30、大 規(guī)模存儲(chǔ)系統(tǒng)。2 負(fù)載均衡 cluster 中的每個(gè)節(jié)點(diǎn)都有可能訪(fǎng)問(wèn)任何一個(gè)數(shù)據(jù)對(duì)象,每個(gè)節(jié)點(diǎn)對(duì)數(shù)據(jù)的處理也能被其 他節(jié)點(diǎn)共享,因此這些節(jié)點(diǎn)要操作的數(shù)據(jù)從邏輯上看只能是一個(gè)整體,不是各自獨(dú)立的數(shù)據(jù)資源。因此高性能的分布式存儲(chǔ)系統(tǒng)對(duì)于大型網(wǎng)站應(yīng)用來(lái)說(shuō)是非常重要的一環(huán)。(這個(gè)地方需要加入對(duì)某個(gè) 分布式存儲(chǔ)系統(tǒng)的簡(jiǎn)單介紹。分布式服務(wù)器管理系統(tǒng)結(jié)構(gòu)圖:隨著網(wǎng)站訪(fǎng)問(wèn)流量的不斷增加,大多的網(wǎng)絡(luò)服務(wù)都是以負(fù)載均衡集群的方式對(duì)外提供服務(wù),隨之集群 規(guī)模的擴(kuò)大,原來(lái)基于單機(jī)的服務(wù)器管理模式已經(jīng)不能夠滿(mǎn)足我們的需求,新的需求必須能夠集中式的、 分組的、批量的、自動(dòng)化的對(duì)服務(wù)器進(jìn)行管理,能夠批量化的執(zhí)行計(jì)劃任務(wù)

31、。在分布式服務(wù)器管理系統(tǒng)軟件中有一些比較優(yōu)秀的軟件,其中比較理想的一個(gè)是 Cfengine 。它可以對(duì) 服務(wù)器進(jìn)行分組,不同的分組可以分別定制系統(tǒng)配置文件、計(jì)劃任務(wù)等配置。它是基于 C/S 結(jié)構(gòu)的,所有 的服務(wù)器配置和管理腳本程序都保存在 Cfengine Server上, 而被管理的服務(wù)器運(yùn)行著 Cfengine Client 程 序, Cfengine Client通過(guò) SSL 加密的連接定期的向服務(wù)器端發(fā)送請(qǐng)求以獲取最新的配置文件和管理命令、 腳本程序、補(bǔ)丁安裝等任務(wù)。有了 Cfengine 這種集中式的服務(wù)器管理工具, 我們就可以高效的實(shí)現(xiàn)大規(guī)模的服務(wù)器集群管理, 被管 理服務(wù)器和 C

32、fengine Server 可以分布在任何位置,只要網(wǎng)絡(luò)可以連通就能實(shí)現(xiàn)快速自動(dòng)化的管理。 代碼發(fā)布系統(tǒng)結(jié)構(gòu)圖:隨著網(wǎng)站訪(fǎng)問(wèn)流量的不斷增加,大多的網(wǎng)絡(luò)服務(wù)都是以負(fù)載均衡集群的方式對(duì)外提供服務(wù),隨之集群 規(guī)模的擴(kuò)大,為了滿(mǎn)足集群環(huán)境下程序代碼的批量分發(fā)和更新,我們還需要一個(gè)程序代碼發(fā)布系統(tǒng)。 這個(gè)發(fā)布系統(tǒng)可以幫我們實(shí)現(xiàn)下面的目標(biāo):1 生產(chǎn)環(huán)境的服務(wù)器以虛擬主機(jī)方式提供服務(wù),不需要開(kāi)發(fā)人員介入維護(hù)和直接操作, 提供發(fā)布系統(tǒng) 可以實(shí)現(xiàn)不需要登陸服務(wù)器就能把程序分發(fā)到目標(biāo)服務(wù)器。2 我們要實(shí)現(xiàn)內(nèi)部開(kāi)發(fā)、內(nèi)部測(cè)試、生產(chǎn)環(huán)境測(cè)試、生產(chǎn)環(huán)境發(fā)布的 4個(gè)開(kāi)發(fā)階段的管理,發(fā)布系統(tǒng) 可以介入各個(gè)階段的代碼發(fā)布。

33、3 我們需要實(shí)現(xiàn)源代碼管理和版本控制, SVN 可以實(shí)現(xiàn)該需求。這里面可以使用常用的工具 Rsync ,通過(guò)開(kāi)發(fā)相應(yīng)的腳本工具實(shí)現(xiàn)服務(wù)器集群間代碼同步分發(fā)。 相關(guān)連接程序開(kāi)發(fā)是一方面,系統(tǒng)架構(gòu)設(shè)計(jì)(硬件 +網(wǎng)絡(luò) +軟件是另一方面。中國(guó)的網(wǎng)絡(luò)分南北電信和網(wǎng)通,訪(fǎng)問(wèn)的 ip 就要區(qū)分南北進(jìn)入不同的網(wǎng)絡(luò);然后是集群,包括應(yīng)用服務(wù)器集群和 web 服務(wù)器集群,應(yīng)用服務(wù)器集群可以采用 apache+tomcat集群和 weblogic 集群等, web 服務(wù)器集群可以用反向代理,也可以用 NAT 的方式,或者多域名解析都可以;軟件架構(gòu)方面,做網(wǎng)站首先需要很多 web 服務(wù)器存儲(chǔ)靜態(tài)資源,比如圖片、視頻、

34、靜態(tài)頁(yè)等,千萬(wàn)不要把靜態(tài) 資源和應(yīng)用服務(wù)器放在一起;頁(yè)面數(shù)據(jù)調(diào)用更要認(rèn)真設(shè)計(jì),一些數(shù)據(jù)查詢(xún)可以不通過(guò)數(shù)據(jù)庫(kù)的方式,實(shí)時(shí)性要求不高的可以使用 lucene 來(lái)實(shí) 現(xiàn),即使有實(shí)時(shí)性的要求也可以用 lucene , lucene+compass還是非常優(yōu)秀的;不能用 lucene 實(shí)現(xiàn)的可以用緩存, 分布式緩存可以用 memcached , 如果有錢(qián)的話(huà)用 10來(lái)臺(tái)機(jī)器做緩存, >10G的存儲(chǔ)量相信存什么都?jí)蛄? 如果沒(méi)錢(qián)的話(huà)可以在頁(yè)面緩存和數(shù)據(jù)緩存上下功夫, 多用 OSCACHE 和 EHCACHE , SWARMCACHE 也可以,不過(guò)據(jù)說(shuō)同步性不是很好; 然后很重要的一點(diǎn)就是數(shù)據(jù)庫(kù),大型

35、網(wǎng)站要用oracle,數(shù)據(jù)方面操作盡量多用存儲(chǔ)過(guò)程,絕對(duì)提升性能;同時(shí)要讓DBA對(duì)數(shù)據(jù)庫(kù)進(jìn)行優(yōu)化,優(yōu)化后的數(shù)據(jù)庫(kù)與沒(méi)優(yōu)化的有天壤之別;同時(shí)還可以擴(kuò)展分布式數(shù)據(jù)庫(kù),以后這方面的研究會(huì)越來(lái)越多;新聞?lì)惖木W(wǎng)站可以用靜態(tài)頁(yè)存儲(chǔ),采用定時(shí)更新機(jī)制減輕服務(wù)器負(fù)擔(dān);首頁(yè)每個(gè)小模塊可以使用oscache緩存,這樣不用每次都拉數(shù)據(jù);最后是寫(xiě)程序了,一個(gè)好的程序員寫(xiě)出來(lái)的程序會(huì)非常簡(jiǎn)潔、性能很好,一個(gè)初級(jí)程序員可能會(huì)犯很多低級(jí)錯(cuò)誤,這也是影響網(wǎng)站性能的原因之一。=大型網(wǎng)站后臺(tái)架構(gòu)的演變分類(lèi):大規(guī)模Web 2.0架構(gòu)2011-10-11 18:28 1802人閱讀評(píng)論(1 收藏舉報(bào)應(yīng)用服務(wù)器數(shù)據(jù)庫(kù)負(fù)載均衡serve

36、r數(shù)據(jù)庫(kù)服務(wù)器目錄(?+隨著用戶(hù)訪(fǎng)問(wèn)量的不斷增加,網(wǎng)站的后臺(tái)也會(huì)不斷變化以應(yīng)對(duì)需求。本文主要從一個(gè)小型網(wǎng)站到大型網(wǎng)站的過(guò)度與變化來(lái)陳述。1.1 網(wǎng)站后臺(tái)架構(gòu)主要指由web server 、應(yīng)用服務(wù)器、數(shù)據(jù)庫(kù)、存儲(chǔ)、監(jiān)控等組成的網(wǎng)站后臺(tái)系統(tǒng)。1.2 架構(gòu)演變個(gè)人站點(diǎn)后臺(tái)架構(gòu)。如圖2-1所示。圖2-1 單臺(tái)一組如圖所示,如果是個(gè)人站點(diǎn),訪(fǎng)問(wèn)量不大,一般都是將web server、應(yīng)用服務(wù)器、數(shù)據(jù)庫(kù)部署在一臺(tái)物理服務(wù)器上。從圖中也可以看到,一個(gè)網(wǎng)站最基本的后臺(tái)需要web server、應(yīng)用服務(wù)器、數(shù)據(jù)庫(kù)三部分組成?？紤]到網(wǎng)站訪(fǎng)問(wèn)量的不斷增加,網(wǎng)站的后臺(tái)架構(gòu)也必須不斷調(diào)整和優(yōu)化,進(jìn)一步實(shí)現(xiàn)功能分離。特

37、別是隨著訪(fǎng)問(wèn)量不斷增加以及考慮到數(shù)據(jù)庫(kù)的負(fù)載和數(shù)據(jù)的重要性,數(shù)據(jù)庫(kù)需要分離出來(lái)。從web server到數(shù)據(jù)庫(kù)實(shí)現(xiàn)各個(gè)層次的負(fù)載均衡?？紤]到數(shù)據(jù)庫(kù)的安全性和處理性能,數(shù)據(jù)庫(kù)單臺(tái)部署。如圖2-2-1-1所示。圖2-2-1-1 數(shù)據(jù)庫(kù)分離如圖所示,數(shù)據(jù)庫(kù)與web server 、應(yīng)用服務(wù)器分離出來(lái),單臺(tái)部署。這樣做有兩個(gè)好處:(1數(shù)據(jù)庫(kù)服務(wù)器性能提高,不再和webserver 、應(yīng)用服務(wù)器搶占資源。(2數(shù)據(jù)庫(kù)服務(wù)器安全性能提高,不會(huì)因?yàn)橐慌_(tái)服務(wù)器宕機(jī)而影響所有服務(wù),特別是數(shù)據(jù)庫(kù)服務(wù)。隨著訪(fǎng)問(wèn)量的不斷增加,單臺(tái)web server 負(fù)載會(huì)加大,甚至有宕機(jī)的危險(xiǎn),所以需要在前端增加負(fù)載均衡器,實(shí)現(xiàn)we

38、b server層的負(fù)載均衡。緩解壓力。如圖2-2-1-2所示。 2-2-1-2 前端負(fù)載均衡如圖所示,通過(guò)增加web server并用負(fù)載均衡器(load balance來(lái)緩解前端的web server和應(yīng)用服務(wù)器壓力。并且,為了保證數(shù)據(jù)庫(kù)的絕對(duì)安全,做了Master-Slave主從備份。這樣當(dāng)master db宕機(jī)之后, slave db可以立即啟用。所以這樣做有以下好處:(1 前臺(tái)web server 和應(yīng)用服務(wù)器壓力減少,負(fù)載均衡器分流負(fù)載。(2 后端數(shù)據(jù)庫(kù)安全性加強(qiáng),出現(xiàn)故障后,業(yè)務(wù)可以很快切換到slave db 上。隨著訪(fǎng)問(wèn)量的不斷增加,發(fā)現(xiàn)整個(gè)系統(tǒng)的讀寫(xiě)比例很大,對(duì)用戶(hù)而言,讀操

39、作多于寫(xiě)操作,而且比例很大,這就需要進(jìn)一步改善架構(gòu),實(shí)現(xiàn)讀寫(xiě)分離。通過(guò)增加db proxy,實(shí)現(xiàn)讀寫(xiě)分離。如圖所示,2-2-1-3。 圖2-2-1-3考慮到讀寫(xiě)比例大的特點(diǎn),如圖2-2-1-3所示,通過(guò)增加db proxy,以及master-slaves ,實(shí)現(xiàn)讀寫(xiě)分離,所有寫(xiě)操作在master db上進(jìn)行,所有讀操作在其他slave dbs 上進(jìn)行,這樣做有以下好處:(1 緩解單臺(tái)db的壓力,減少單臺(tái)db的負(fù)載(2 增加多個(gè)slave,當(dāng)master db宕機(jī)之后,可以很快切換到slave 上,減少所有db同時(shí)宕機(jī)的風(fēng)險(xiǎn)。很多用戶(hù)訪(fǎng)問(wèn),讀與寫(xiě)操作比例很大,如圖2-2-1-3所示,通過(guò)在web

40、 server層上增加緩存,可以提高訪(fǎng)問(wèn)速度。比如可以緩存css、jpg等靜態(tài)文件。增加緩存有兩個(gè)好處:(1 加快用戶(hù)的讀請(qǐng)求訪(fǎng)問(wèn)速度。(2 緩解web server的壓力。雖然上述幾個(gè)架構(gòu)圖,從各個(gè)層面緩解了服務(wù)器壓力,但是,還是存在當(dāng)點(diǎn)故障的可能性。如果出現(xiàn)單點(diǎn)故障,沒(méi)有在線(xiàn)物理設(shè)備提供使用,那該系統(tǒng)也不是一個(gè)高可用的系統(tǒng)。針對(duì)上述問(wèn)題,增加在線(xiàn)物理備份設(shè)備,解決單點(diǎn)故障問(wèn)題,如圖2-2-1-4所示。 圖2-2-1-4如圖2-2-1-4所示,增加了負(fù)載均衡器的在線(xiàn)備用設(shè)備和db proxy在線(xiàn)備用服務(wù)器,這樣做可以在負(fù)載均衡器出現(xiàn)故障的時(shí)候,啟用在線(xiàn)備用設(shè)備;如果db proxy出現(xiàn)故障,

41、也可以啟用在線(xiàn)備用db proxy,實(shí)現(xiàn)故障轉(zhuǎn)移。保證系統(tǒng)的高可用性。=大型網(wǎng)站架構(gòu)演變分類(lèi):大規(guī)模Web 2.0架構(gòu)2011-10-11 18:292194人閱讀評(píng)論(2收藏舉報(bào)數(shù)據(jù)庫(kù)分布式應(yīng)用負(fù)載均衡存儲(chǔ)算法今天我們來(lái)談?wù)勔粋€(gè)網(wǎng)站一般是如何一步步來(lái)構(gòu)建起系統(tǒng)架構(gòu)的,雖然我們希望網(wǎng)站一開(kāi)始就能有一個(gè)很好的架構(gòu),但馬克思告訴我們事物是在發(fā)展中不斷前進(jìn)的,網(wǎng)站架構(gòu)也是隨著業(yè)務(wù)的擴(kuò)大、用戶(hù)的需求不斷完善的,下面是一個(gè)網(wǎng)站架構(gòu)逐步發(fā)展的基本過(guò)程,讀完后,請(qǐng)思考,你現(xiàn)在在哪個(gè)階段。架構(gòu)演變第一步:物理分離WebServer和數(shù)據(jù)庫(kù)最開(kāi)始,由于某些想法,于是在互聯(lián)網(wǎng)上搭建了一個(gè)網(wǎng)站,這個(gè)時(shí)候甚至有可能主

42、機(jī)都是租借的,但由于這篇文章我們只關(guān)注架構(gòu)的演變歷程,因此就假設(shè)這個(gè)時(shí)候已經(jīng)是托管了一臺(tái)主機(jī),并且有一定的帶寬了。這個(gè)時(shí)候由于網(wǎng)站具備了一定的特色,吸引了部分人訪(fǎng)問(wèn),逐漸你發(fā)現(xiàn)系統(tǒng)的壓力越來(lái)越高,響應(yīng)速度越來(lái)越慢,而這個(gè)時(shí)候比較明顯的是數(shù)據(jù)庫(kù)和應(yīng)用互相影響,應(yīng)用出問(wèn)題了,數(shù)據(jù)庫(kù)也很容易出現(xiàn)問(wèn)題,而數(shù)據(jù)庫(kù)出問(wèn)題的時(shí)候,應(yīng)用也容易出問(wèn)題。于是進(jìn)入了第一步演變階段:將應(yīng)用和數(shù)據(jù)庫(kù)從物理上分離,變成了兩臺(tái)機(jī)器,這個(gè)時(shí)候技術(shù)上沒(méi)有什么新的要求,但你發(fā)現(xiàn)確實(shí)起到效果了,系統(tǒng)又恢復(fù)到以前的響應(yīng)速度了,并且支撐住了更高的流量,并且不會(huì)因?yàn)閿?shù)據(jù)庫(kù)和應(yīng)用形成互相的影響?？纯催@一步完成后系統(tǒng)的圖示: 架構(gòu)演變第二步

43、:增加頁(yè)面緩存好景不長(zhǎng),隨著訪(fǎng)問(wèn)的人越來(lái)越多,你發(fā)現(xiàn)響應(yīng)速度又開(kāi)始變慢了,查找原因,發(fā)現(xiàn)是訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的操作太多,導(dǎo)致數(shù)據(jù)連接競(jìng)爭(zhēng)激烈,所以響應(yīng)變慢。但數(shù)據(jù)庫(kù)連接又不能開(kāi)太多,否則數(shù)據(jù)庫(kù)機(jī)器壓力會(huì)很高,因此考慮采用緩存機(jī)制來(lái)減少數(shù)據(jù)庫(kù)連接資源的競(jìng)爭(zhēng)和對(duì)數(shù)據(jù)庫(kù)讀的壓力。這個(gè)時(shí)候首先也許會(huì)選擇采用squid等類(lèi)似的機(jī)制來(lái)將系統(tǒng)中相對(duì)靜態(tài)的頁(yè)面(例如一兩天才會(huì)有更新的頁(yè)面進(jìn)行緩存(當(dāng)然,也可以采用將頁(yè)面靜態(tài)化的方案,這樣程序上可以不做修改,就能夠很好的減少對(duì)WebServer的壓力以及減少數(shù)據(jù)庫(kù)連接資源的競(jìng)爭(zhēng),OK,于是開(kāi)始采用squid來(lái)做相對(duì)靜態(tài)的頁(yè)面的緩存。看看這一步完成后系統(tǒng)的圖示: 這一步涉

44、及到了這些知識(shí)體系:前端頁(yè)面緩存技術(shù),例如squid,如想用好的話(huà)還得深入掌握下squid的實(shí)現(xiàn)方式以及緩存的失效算法等。架構(gòu)演變第三步:增加頁(yè)面片段緩存增加了squid做緩存后,整體系統(tǒng)的速度確實(shí)是提升了,WebServer的壓力也開(kāi)始下降了,但隨著訪(fǎng)問(wèn)量的增加,發(fā)現(xiàn)系統(tǒng)又開(kāi)始變的有些慢了。在嘗到了squid之類(lèi)的動(dòng)態(tài)緩存帶來(lái)的好處后,開(kāi)始想能不能讓現(xiàn)在那些動(dòng)態(tài)頁(yè)面里相對(duì)靜態(tài)的部分也緩存起來(lái)呢,因此考慮采用類(lèi)似ESI之類(lèi)的頁(yè)面片段緩存策略,OK,于是開(kāi)始采用ESI來(lái)做動(dòng)態(tài)頁(yè)面中相對(duì)靜態(tài)的片段部分的緩存。看看這一步完成后系統(tǒng)的圖示: 這一步涉及到了這些知識(shí)體系:頁(yè)面片段緩存技術(shù),例如ESI等,

45、想用好的話(huà)同樣需要掌握ESI的實(shí)現(xiàn)方式等;架構(gòu)演變第四步:數(shù)據(jù)緩存在采用ESI之類(lèi)的技術(shù)再次提高了系統(tǒng)的緩存效果后,系統(tǒng)的壓力確實(shí)進(jìn)一步降低了,但同樣,隨著訪(fǎng)問(wèn)量的增加,系統(tǒng)還是開(kāi)始變慢。經(jīng)過(guò)查找,可能會(huì)發(fā)現(xiàn)系統(tǒng)中存在一些重復(fù)獲取數(shù)據(jù)信息的地方,像獲取用戶(hù)信息等,這個(gè)時(shí)候開(kāi)始考慮是不是可以將這些數(shù)據(jù)信息也緩存起來(lái)呢,于是將這些數(shù)據(jù)緩存到本地內(nèi)存,改變完畢后,完全符合預(yù)期,系統(tǒng)的響應(yīng)速度又恢復(fù)了,數(shù)據(jù)庫(kù)的壓力也再度降低了不少?？纯催@一步完成后系統(tǒng)的圖示: 這一步涉及到了這些知識(shí)體系:緩存技術(shù),包括像Map數(shù)據(jù)結(jié)構(gòu)、緩存算法、所選用的框架本身的實(shí)現(xiàn)機(jī)制等。架構(gòu)演變第五步:增加WebServer好景

46、不長(zhǎng),發(fā)現(xiàn)隨著系統(tǒng)訪(fǎng)問(wèn)量的再度增加,webserver機(jī)器的壓力在高峰期會(huì)上升到比較高,這個(gè)時(shí)候開(kāi)始考慮增加一臺(tái)webserver,這也是為了同時(shí)解決可用性的問(wèn)題,避免單臺(tái)的webserver down機(jī)的話(huà)就沒(méi)法使用了,在做了這些考慮后,決定增加一臺(tái)webserver,增加一臺(tái)webserver時(shí),會(huì)碰到一些問(wèn)題,典型的有:1、如何讓訪(fǎng)問(wèn)分配到這兩臺(tái)機(jī)器上,這個(gè)時(shí)候通常會(huì)考慮的方案是Apache自帶的負(fù)載均衡方案,或LVS這類(lèi)的軟件負(fù)載均衡方案;2、如何保持狀態(tài)信息的同步,例如用戶(hù)session等,這個(gè)時(shí)候會(huì)考慮的方案有寫(xiě)入數(shù)據(jù)庫(kù)、寫(xiě)入存儲(chǔ)、cookie或同步session信息等機(jī)制等;3、

47、如何保持?jǐn)?shù)據(jù)緩存信息的同步,例如之前緩存的用戶(hù)數(shù)據(jù)等,這個(gè)時(shí)候通常會(huì)考慮的機(jī)制有緩存同步或分布式緩存;4、如何讓上傳文件這些類(lèi)似的功能繼續(xù)正常,這個(gè)時(shí)候通常會(huì)考慮的機(jī)制是使用共享文件系統(tǒng)或存儲(chǔ)等;在解決了這些問(wèn)題后,終于是把webserver增加為了兩臺(tái),系統(tǒng)終于是又恢復(fù)到了以往的速度。看看這一步完成后系統(tǒng)的圖示: 這一步涉及到了這些知識(shí)體系:負(fù)載均衡技術(shù)(包括但不限于硬件負(fù)載均衡、軟件負(fù)載均衡、負(fù)載算法、linux轉(zhuǎn)發(fā)協(xié)議、所選用的技術(shù)的實(shí)現(xiàn)細(xì)節(jié)等、主備技術(shù)(包括但不限于ARP欺騙、linuxheart-beat 等、狀態(tài)信息或緩存同步技術(shù)(包括但不限于Cookie技術(shù)、UDP協(xié)議、狀態(tài)信息

48、廣播、所選用的緩存同步技術(shù)的實(shí)現(xiàn)細(xì)節(jié)等、共享文件技術(shù)(包括但不限于NFS等、存儲(chǔ)技術(shù)(包括但不限于存儲(chǔ)設(shè)備等。架構(gòu)演變第六步:分庫(kù)享受了一段時(shí)間的系統(tǒng)訪(fǎng)問(wèn)量高速增長(zhǎng)的幸福后,發(fā)現(xiàn)系統(tǒng)又開(kāi)始變慢了,這次又是什么狀況呢,經(jīng)過(guò)查找,發(fā)現(xiàn)數(shù)據(jù)庫(kù)寫(xiě)入、更新的這些操作的部分?jǐn)?shù)據(jù)庫(kù)連接的資源競(jìng)爭(zhēng)非常激烈,導(dǎo)致了系統(tǒng)變慢,這下怎么辦呢?此時(shí)可選的方案有數(shù)據(jù)庫(kù)集群和分庫(kù)策略,集群方面像有些數(shù)據(jù)庫(kù)支持的并不是很好,因此分庫(kù)會(huì)成為比較普遍的策略,分庫(kù)也就意味著要對(duì)原有程序進(jìn)行修改,一通修改實(shí)現(xiàn)分庫(kù)后,不錯(cuò),目標(biāo)達(dá)到了,系統(tǒng)恢復(fù)甚至速度比以前還快了?？纯催@一步完成后系統(tǒng)的圖示: 這一步涉及到了這些知識(shí)體系:這一步更多

49、的是需要從業(yè)務(wù)上做合理的劃分,以實(shí)現(xiàn)分庫(kù),具體技術(shù)細(xì)節(jié)上沒(méi)有其他的要求;但同時(shí)隨著數(shù)據(jù)量的增大和分庫(kù)的進(jìn)行,在數(shù)據(jù)庫(kù)的設(shè)計(jì)、調(diào)優(yōu)以及維護(hù)上需要做的更好,因此對(duì)這些方面的技術(shù)還是提出了很高的要求的。架構(gòu)演變第七步:分表、DAL和分布式緩存隨著系統(tǒng)的不斷運(yùn)行,數(shù)據(jù)量開(kāi)始大幅度增長(zhǎng),這個(gè)時(shí)候發(fā)現(xiàn)分庫(kù)后查詢(xún)?nèi)匀粫?huì)有些慢,于是按照分庫(kù)的思想開(kāi)始做分表的工作。當(dāng)然,這不可避免的會(huì)需要對(duì)程序進(jìn)行一些修改,也許在這個(gè)時(shí)候就會(huì)發(fā)現(xiàn)應(yīng)用自己要關(guān)心分庫(kù)分表的規(guī)則等,還是有些復(fù)雜的。于是萌生能否增加一個(gè)通用的框架來(lái)實(shí)現(xiàn)分庫(kù)分表的數(shù)據(jù)訪(fǎng)問(wèn),這個(gè)在ebay的架構(gòu)中對(duì)應(yīng)的就是DAL,這個(gè)演變的過(guò)程相對(duì)而言需要花費(fèi)較長(zhǎng)的時(shí)間

50、。當(dāng)然,也有可能這個(gè)通用的框架會(huì)等到分表做完后才開(kāi)始做。同時(shí),在這個(gè)階段可能會(huì)發(fā)現(xiàn)之前的緩存同步方案出現(xiàn)問(wèn)題,因?yàn)閿?shù)據(jù)量太大,導(dǎo)致現(xiàn)在不太可能將緩存存在本地,然后同步的方式,需要采用分布式緩存方案了。于是,又是一通考察和折磨,終于是將大量的數(shù)據(jù)緩存轉(zhuǎn)移到分布式緩存上了?？纯催@一步完成后系統(tǒng)的圖示: 這一步涉及到了這些知識(shí)體系:分表更多的同樣是業(yè)務(wù)上的劃分,技術(shù)上涉及到的會(huì)有動(dòng)態(tài)hash算法、consistenthash 算法等;DAL涉及到比較多的復(fù)雜技術(shù),例如數(shù)據(jù)庫(kù)連接的管理(超時(shí)、異常、數(shù)據(jù)庫(kù)操作的控制(超時(shí)、異常、分庫(kù)分表規(guī)則的封裝等;架構(gòu)演變第八步:增加更多的WebServer在做完分庫(kù)分表這些工作后,數(shù)據(jù)庫(kù)上的壓力已經(jīng)降到比較低了,又開(kāi)始過(guò)著每天看著訪(fǎng)問(wèn)量暴增的幸福生活了。突然有一天,發(fā)現(xiàn)系統(tǒng)的訪(fǎng)問(wèn)又開(kāi)始有變慢的趨勢(shì)了,這個(gè)時(shí)候首先查看數(shù)據(jù)庫(kù),壓力一切正常,之后查看webserver,發(fā)現(xiàn)apache阻塞了很多的請(qǐng)求,而應(yīng)用服務(wù)器對(duì)每個(gè)請(qǐng)求也是比較快的,看來(lái)是請(qǐng)求數(shù)太高導(dǎo)致需要排隊(duì)等待,響應(yīng)速度變慢。這還好辦,一般來(lái)說(shuō),這個(gè)時(shí)候也會(huì)有些錢(qián)了,于是添加一些webserver服務(wù)器,在這個(gè)添加web