【正文】 .....................................................................................................331 Jeff.. Bazos?.....................................................................................................331 Werner Vogels, the CTO of ................................................................................331 Re: Amazon Architecture ...................................................................................331 Re: Amazon Architecture ...................................................................................331 Re: Amazon Architecture ...................................................................................332 It39。 創(chuàng)業(yè)期的網(wǎng)站往往采用比較簡(jiǎn)單的系統(tǒng)架構(gòu)，或者是直接使用比較成熟的開源軟件。太復(fù)雜的設(shè)計(jì)容易降低開發(fā)效率，提高維護(hù)成本，在出現(xiàn)性能問題或者突發(fā)事件的時(shí)候也不容易找到原因。一個(gè)網(wǎng)站最基本的要求，就是有比較快的訪問速度，沒有速度，再好的內(nèi)容或服務(wù)也出不來(lái)。 這些工作都做了以后，下面數(shù)據(jù)庫(kù)如果再出現(xiàn)性能問題就需要考慮多臺(tái)服務(wù)器了，一臺(tái)服務(wù)器已經(jīng)解決不了問題了，我以前的文章中也提到過，這里也不再展開。修改 ，加大并發(fā)數(shù)量和關(guān)閉不需要的模塊。 純交互站點(diǎn)， mysql 性能會(huì)是一個(gè)瓶頸。比如 Ligd還不支持緩存，而現(xiàn)在的絕大部分站點(diǎn)都是用程序生成動(dòng)態(tài)內(nèi)容，沒有緩存的話即使程序 的效率再高也很難滿足大訪問量的需求，而且讓程序不停的去做同一件事情也實(shí)在沒有意義。新請(qǐng)求或者過期的頁(yè)面請(qǐng)求交由 Apache 中 Web 程序來(lái)處理。 Ligd 服務(wù)于 80 端口， Squid 運(yùn)行在 3128 端口， Apache 運(yùn)行在 81 端口。 實(shí)例講解 下面以 和 域下面的幾個(gè)站點(diǎn)為例來(lái)介紹一下此方案的具體做法。把 Squid 放在 Apache或者 Ligd 的前端來(lái)緩存 Web 服務(wù)器生成的動(dòng)態(tài)內(nèi)容，而 Web 應(yīng)用程序只需要適當(dāng)?shù)卦O(shè)置頁(yè)面實(shí)效時(shí)間即可。而輕量級(jí)的 Web服務(wù)器 Ligd 卻是后起之秀，其靜態(tài)文件的響應(yīng)能力遠(yuǎn)高于 Apache，據(jù)說(shuō)是 Apache 的 23 倍。 ZEND 要使用較小的優(yōu)化等級(jí)， 15 就足夠了， 1023 級(jí)別只會(huì)加重服務(wù)器負(fù)載~ MYSQL 要盡量少使用長(zhǎng)連接，限制為 23 秒即可 ~ 要全部采用手工編譯方式，不要用 ports 安裝，因?yàn)樗鼤?huì)帶上很多你不需要的模塊，切記。 ? 談?wù)劥笮透哓?fù)載網(wǎng)站服務(wù)器的優(yōu)化心得 ! 因?yàn)楣ぷ鞯年P(guān)系，我做過幾個(gè)大型網(wǎng)站（書庫(kù)、證券）的相關(guān)優(yōu)化工作，一般是在世界排行 10004000 以內(nèi)的 ~~ 這些網(wǎng)站使用的程序各不一樣，配置也不盡相同，但是它們有一個(gè)共同的特點(diǎn)，就是使用的是 FREEBSD 系統(tǒng) ，高配置高負(fù)載， PV 值非常高，都是需要用兩臺(tái)以上獨(dú)立主機(jī)來(lái)支持的網(wǎng)站 ~ 我在優(yōu)化及跟蹤的過程中，開始效果也差強(qiáng)人意，也不太理想，后來(lái)通過閱讀大量資料才慢慢理清了一些思路，寫出來(lái)希望給大家有所幫助。當(dāng)然前期沒注意的話后期也有解決辦法，只不過可能不會(huì)解決的特別徹底，但還是要吧非常有效的提升性能。經(jīng)過一段時(shí)間的運(yùn)行，除非是特別好的設(shè)計(jì)以及比較好的維護(hù)， 一般都會(huì)在論壇里存在各種各樣亂七八糟的對(duì)用戶信息的調(diào)用，而且是直接針對(duì)數(shù)據(jù)庫(kù)的，這樣如果要將用戶數(shù)據(jù)移走的話要修改代碼的工作量將不容忽視，而另外一個(gè)解決辦法是復(fù)制一份用戶數(shù)據(jù)出來(lái)，以新的用戶數(shù)據(jù)庫(kù)為主，論壇里的用戶數(shù)據(jù)通過同步或異步的機(jī)制實(shí)現(xiàn)同步。實(shí)際上目前開源的項(xiàng)目也比較多了，在 上可以找到各種各樣的開源項(xiàng)目。 軟件方面，如果使用了更大容量的內(nèi)存和改善的 I/O 性能，已經(jīng)能夠大幅提高數(shù)據(jù)庫(kù)的運(yùn)行效率，還可以配置查詢緩存和進(jìn)一步優(yōu)化數(shù)據(jù)庫(kù)結(jié)構(gòu)和查詢語(yǔ)句，就能讓數(shù)據(jù)庫(kù)的性能再進(jìn)一大步。s Inside? .........................................................................................................256 The Stats..........................................................................................................256 Recipe for handling rapid growth ........................................................................256 Web Servers .....................................................................................................256 Video Serving...................................................................................................257 Serving Video Key Points ..................................................................................258 Serving Thumbnails ..........................................................................................258 Databases ........................................................................................................259 Data Center Strategy .........................................................................................261 Lessons Learned ......................................................................................................261 1. Jesse 我現(xiàn)在按照常規(guī)的設(shè)計(jì)方法對(duì)表進(jìn)行設(shè)計(jì)，已經(jīng)出現(xiàn)了查詢非常緩慢地情形。s WSDL ........................................................................................................332 Re: It39。使用開源軟件的好處是搭建速度快，基本不需要開發(fā)，買個(gè)空間域名，下個(gè)軟件一搭建，用個(gè)半天就搞定了，一個(gè)嶄新的網(wǎng)站就開張了，在前期可以極大程度的節(jié)約時(shí)間成本和開發(fā)成本。 另外一個(gè)問題是開源軟件的后期維護(hù)和繼續(xù)開發(fā)可能會(huì)存在問題，這一點(diǎn)不是絕對(duì)的，取決于開源軟件的架構(gòu)是否清晰合理，擴(kuò)展性好，如果是較小的改動(dòng)可能一般不會(huì)存在什么問題，例如添加一項(xiàng)用戶屬性或者文章屬性，但有些需求可能就不是很容易實(shí)現(xiàn)了。所以，訪問速度在網(wǎng)站初創(chuàng)的時(shí)候就需要考慮，無(wú)論是采用開源軟件還是自己開發(fā)都需要注意，數(shù)據(jù)層盡量能夠正確，高效的使用 SQL。 其它解決速度問題的辦法就不僅僅是在應(yīng)用里面就可以實(shí)現(xiàn)的了，需要從更高的高度去設(shè)計(jì)系統(tǒng)，考慮到服務(wù)器，網(wǎng)絡(luò)的架構(gòu)，以及各種系統(tǒng)級(jí)應(yīng)用軟件的配合，這里也不再展開。因?yàn)閍pache 非常消耗內(nèi)存，盡量輕裝上陣 ~~ 可以適當(dāng)?shù)氖褂瞄L(zhǎng)連接。需要長(zhǎng)期跟蹤更改參數(shù)。首先，Web 程序是需要做緩存處理的，即把反復(fù)使用的數(shù)據(jù)做緩存。經(jīng)過 Ligd 和 Squid 的兩級(jí)過濾， Apache需要處理的請(qǐng)求將大大減少，減少了 Web 應(yīng)用程序的壓力。 Ligd 的配置 多個(gè)域名采用 /var//dom。 在這種架構(gòu)下，每一級(jí)都是可以進(jìn)行單獨(dú)優(yōu)化的，比如 Ligd 可以采用異步 IO 方式， Squid可以啟用內(nèi)存來(lái)緩存， Apache 可以啟用 MPM 等，并且每一級(jí)都可以使用多臺(tái)機(jī)器來(lái)均衡負(fù)載，伸縮性很好。而做這個(gè)是 Squid 的強(qiáng)項(xiàng)，它本是做代理的，支持高效的緩存，可以用來(lái)給站點(diǎn)做反向代理加速。但是它的強(qiáng)大有時(shí)候卻顯得笨重，配置文件得讓人望而生畏，高并發(fā)情況下效率不太高。 PHP 編譯的時(shí)候，注意要 盡量以實(shí)用為目的加入?yún)?shù)，沒有用到的堅(jiān)決不加，以免浪費(fèi)系統(tǒng)資源。這個(gè)過程會(huì)是一個(gè)充滿艱辛和樂趣的過程，也是一個(gè)可以逐漸過渡的過程，主動(dòng)出擊，提前考慮，減少救火可以讓這個(gè)過程輕松一些。在初期這個(gè)問題可能不是特別明顯，當(dāng)訪問量大起來(lái)以后，這個(gè)可能成為最主要的性能瓶頸，各種雜亂無(wú)章的 SQL會(huì)讓人看的瘋掉。由于網(wǎng)站初始的用戶數(shù)據(jù)可能大部分都存放在論壇里，這個(gè)時(shí)候我們需要把用戶數(shù)據(jù)獨(dú)立出來(lái)就會(huì)碰到麻煩，如何既能把用戶數(shù)據(jù)獨(dú)立出來(lái)又不影響論壇原有系統(tǒng)的繼續(xù)運(yùn)行會(huì)是件很頭痛的事情。 一方面是開源軟件一般只有在比較成熟的領(lǐng)域 才有，如果是一些創(chuàng)新型的項(xiàng)目很難找到合適的開源軟件，這個(gè)時(shí)候沒什么好的解決辦法，如果非要用開源的話一般會(huì)找一個(gè)最相似的改一下。s Inside? .........................................................................................................344 The Stats..........................................................................................................344 The Stack.........................................................................................................344 Reliable Storage Mechanism with GFS (Google File System) .................................345 Do Something With the Data Using MapReduce ...................................................346 Storing Structured Data in BigTable ....................................................................347 Hardware .........................................................................................................349 Misc................................................................................................................349 Future Directions for Google ..............................................................................349 Lessons Learned ......................................................................................................350 不管怎么樣，先要找出瓶頸在哪個(gè)部分：是 CPU 負(fù)荷太高（經(jīng)常 100％），還是內(nèi)存不夠用（大量使用虛擬內(nèi)存），還是磁盤 I/O 性能跟不上（硬盤指示燈狂閃）？這幾個(gè)都是可以通過升級(jí)硬件來(lái)解決或者改善的（使用更高等級(jí)的 CPU，更快速和更大容量的內(nèi)存，配置硬件磁盤陣列并使用更多數(shù)量的高速 SCSI 硬盤），但這需要較大的投入。s Scalability and Performance .....................................................................252 ? YouTube Architecture....................................................