2006-6-17 于敦德
上次我們以L(fǎng)iveJournal為例詳細分析了一個(gè)小網(wǎng)站在一步一步的發(fā)展成為大規模的網(wǎng)站中性能優(yōu)化的方案，以解決在發(fā)展中由于負載增長(cháng)而引起的性能問(wèn)題，同時(shí)在設計網(wǎng)站架構的時(shí)候就從根本上避免或者解決這些問(wèn)題。
今天我們來(lái)看一下在網(wǎng)站的設計上一些通常使用的解決大規模訪(fǎng)問(wèn)，高負載的方法。我們將主要涉及到以下幾方面：
1、 前端負載
2、 業(yè)務(wù)邏輯層
3、 數據層
在LJ性能優(yōu)化文章中我們提到對服務(wù)器分組是解決負載問(wèn)題，實(shí)現無(wú)限擴展的解決方案。通常中我們會(huì )采用類(lèi)似LDAP的方案來(lái)解決，這在郵件的服務(wù)器以及個(gè)人網(wǎng)站，博客的應用中都有使用，在Windows下面有類(lèi)似的Active Directory解決方案。有的應用（例如博客或者個(gè)人網(wǎng)頁(yè)）會(huì )要求在二級域名解析的時(shí)候就將用戶(hù)定位到所屬的服務(wù)器群組，這個(gè)時(shí)候請求還沒(méi)到應用上面，我們需要在DNS里解決這個(gè)問(wèn)題。這個(gè)時(shí)候可以用到一款軟件bind dlz，這是bind的一個(gè)插件，用于取代bind的文本解析配置文件。它支持包括LDAP，BDB在內的多種數據存儲方式，可以比較好的解決這個(gè)問(wèn)題。
另外一種涉及到DNS的問(wèn)題就是目前普遍存在的南北互聯(lián)互通的問(wèn)題，通過(guò)bind9內置的視圖功能可以根據不同的IP來(lái)源解析出不同的結果，從而將南方的用戶(hù)解析到南方的服務(wù)器，北方的用戶(hù)解析到北方的服務(wù)器。這個(gè)過(guò)程中會(huì )碰到兩個(gè)問(wèn)題，一是取得南北IP的分布列表，二是保證南北服務(wù)器之間的通訊順暢。第一個(gè)問(wèn)題有個(gè)笨辦法解決，從日志里取出所有的訪(fǎng)問(wèn)者IP，寫(xiě)一個(gè)腳本，從南北的服務(wù)器分別ping回去，然后分析結果，可以得到一個(gè)大致準確的列表，當然最好的辦法還是直到從運營(yíng)商那里拿到這份列表。后一個(gè)問(wèn)題解決辦法比較多，最好的辦法就是租用雙線(xiàn)機房，同一臺機器，雙IP，南北同時(shí)接入，差一些的辦法就是南北各自找機房，通過(guò)大量的測試找出中間通訊順暢的兩個(gè)機房，后一種通常來(lái)說(shuō)成本較低，但效果較差，維護不便。
另外DNS負載均衡也是廣泛使用的一種負載均衡方法，通過(guò)并列的多條A記錄將訪(fǎng)問(wèn)隨即的分布到多臺前端服務(wù)器上，這種通常使用在靜態(tài)頁(yè)面居多的應用上，幾大門(mén)戶(hù)內容部分的前端很多都是用的這種方法。
用戶(hù)被定位到正確的服務(wù)器群組后，應用程序就接手用戶(hù)的請求，并開(kāi)始沿著(zhù)定義好的業(yè)務(wù)邏輯進(jìn)行處理。這些請求主要包括兩類(lèi)靜態(tài)文件(圖片，js腳本,css等)，動(dòng)態(tài)請求。
靜態(tài)請求一般使用squid進(jìn)行緩存處理，可以根據應用的規模采用不同的緩存配置方案，可以是一級緩存，也可以是多級緩存，一般情況下cache的命中率可以達到70%左右，能夠比較有效的提升服務(wù)器處理能力。Apache的deflate模塊可以壓縮傳輸數據，提高速度，2.0版本以后的cache模塊也內置實(shí)現磁盤(pán)和內存的緩存，而不必要一定做反向代理。
動(dòng)態(tài)請求目前一般有兩種處理方式，一種是靜態(tài)化，在頁(yè)面發(fā)生變化時(shí)重新靜態(tài)頁(yè)面，現在大量的CMS，BBS都采用這種方案，加上cache，可以提供較快的訪(fǎng)問(wèn)速度。這種通常是寫(xiě)操作較少的應用比較適合的解決方案。
另一種解決辦法是動(dòng)態(tài)緩存，所有的訪(fǎng)問(wèn)都仍然通過(guò)應用處理，只是應用處理的時(shí)候會(huì )更多的使用內存，而不是數據庫。通常訪(fǎng)問(wèn)數據庫的操作是極慢的，而訪(fǎng)問(wèn)內存的操作很快，至少是一個(gè)數量級的差距，使用memcached可以實(shí)現這一解決方案，做的好的memcache甚至可以達到90%以上的緩存命中率。10年前我用的還是2M的內存，那時(shí)的一本雜事上曾經(jīng)風(fēng)趣的描述一對父子的對話(huà)：
兒子：爸爸，我想要1G的內存。
爸爸：兒子，不行，即使是你過(guò)生日也不行。
時(shí)至今日，大內存的成本已經(jīng)完全可以承受。Google使用了大量的PC機建立集群用于數據處理，而我一直覺(jué)得，使用大內存PC可以很低成本的解決前端甚至中間的負載問(wèn)題。由于PC硬盤(pán)壽命比較短，速度比較慢，CPU也稍慢，用于做web前端既便宜，又能充分發(fā)揮大內存的優(yōu)勢，而且壞了的話(huà)只需要替換即可，不存在數據的遷移問(wèn)題。
下面就是應用的設計。應用在設計的時(shí)候應當盡量的設計成支持可擴展的數據庫設計，數據庫可以動(dòng)態(tài)的添加，同時(shí)支持內存緩存，這樣的成本是最低的。另外一種應用設計的方法是采用中間件，例如ICE。這種方案的優(yōu)點(diǎn)是前端應用可以設計的相對簡(jiǎn)單，數據層對于前端應用透明，由ICE提供，數據庫分布式的設計在后端實(shí)現，使用ICE封裝后給前端應用使用，這路設計對每一部分設計的要求較低，將業(yè)務(wù)更好的分層，但由于引入了中間件，分了更多層，實(shí)現起來(lái)成本也相對較高。
在數據庫的設計上一方面可以使用集群，一方面進(jìn)行分組。同時(shí)在細節上將數據庫優(yōu)化的原則盡量應用，數據庫結構和數據層應用在設計上盡量避免臨時(shí)表的創(chuàng )建、死鎖的產(chǎn)生。數據庫優(yōu)化的原則在網(wǎng)上比較常見(jiàn)，多google一下就能解決問(wèn)題。在數據庫的選擇上可以根據自己的習慣選擇，Oracle，MySQL等，并非Oracle就夠解決所有的問(wèn)題，也并非MySQL就代表小應用，合適的就是最好的。
前面講的都是基于軟件的性能設計方案，實(shí)際上硬件的良好搭配使用也可以有效的降低時(shí)間成本，以及開(kāi)發(fā)維護成本，只是在這里我們不再展開(kāi)。
網(wǎng)站架構的設計是一個(gè)整體的工程，在設計的時(shí)候需要考慮到性能，可括展性，硬件成本，時(shí)間成本等等，如何根據業(yè)務(wù)的定位，資金，時(shí)間，人員的條件設計合適的方案是件比較困難的事情，但多想多實(shí)踐，終究會(huì )建立一套適合自己的網(wǎng)站設計理念，用于指導網(wǎng)站的設計工作，為網(wǎng)站的發(fā)展奠定良好的基礎。
聯(lián)系客服
