使用開源軟體，設計高性能可擴充網站

導讀：

　　上次我們以LiveJournal為例詳細分析了一個小網站在一步一步的發展成為大規模的網站中性能優化的方案，以解決在發展中由于負載增長而引起的性能問題，同時在設計網站架構的時候就從根本上避免或者解決這些問題。

　　今天我們來看一下在網站的設計上一些通常使用的解決大規模通路，高負載的方法。我們将主要涉及到以下幾方面：

　　1、 前端負載

　　2、 業務邏輯層

　　3、 資料層

　　在LJ性能優化文章中我們提到對伺服器分組是解決負載問題，實作無限擴充的解決方案。通常中我們會采用類似LDAP的方案來解決，這在郵件的伺服器以及個人網站，部落格的應用中都有使用，在Windows下面有類似的Active Directory解決方案。有的應用（例如部落格或者個人網頁）會要求在二級域名解析的時候就将使用者定位到所屬的伺服器群組，這個時候請求還沒到應用上面，我們需要在DNS裡解決這個問題。這個時候可以用到一款軟體bind dlz，這是bind的一個插件，用于取代bind的文本解析配置檔案。它支援包括LDAP，BDB在内的多種資料存儲方式，可以比較好的解決這個問題。

　　另外一種涉及到DNS的問題就是目前普遍存在的南北互聯互通的問題，通過bind9内置的視圖功能可以根據不同的IP來源解析出不同的結果，進而将南方的使用者解析到南方的伺服器，北方的使用者解析到北方的伺服器。這個過程中會碰到兩個問題，一是取得南北IP的分布清單，二是保證南北伺服器之間的通訊順暢。第一個問題有個笨辦法解決，從日志裡取出所有的通路者IP，寫一個腳本，從南北的伺服器分别ping回去，然後分析結果，可以得到一個大緻準确的清單，當然最好的辦法還是直到從營運商那裡拿到這份清單(update:參見這篇文章)。後一個問題解決辦法比較多，最好的辦法就是租用雙線機房，同一台機器，雙IP，南北同時接入，差一些的辦法就是南北各自找機房，通過大量的測試找出中間通訊順暢的兩個機房，後一種通常來說成本較低，但效果較差，維護不便。

　　另外DNS負載均衡也是廣泛使用的一種負載均衡方法，通過并列的多條A記錄将通路随即的分布到多台前端伺服器上，這種通常使用在靜态頁面居多的應用上，幾大門戶内容部分的前端很多都是用的這種方法。

　　使用者被定位到正确的伺服器群組後，應用程式就接手使用者的請求，并開始沿着定義好的業務邏輯進行處理。這些請求主要包括兩類靜态檔案(圖檔，js腳本,css等)，動态請求。

　　靜态請求一般使用squid進行緩存處理，可以根據應用的規模采用不同的緩存配置方案，可以是一級緩存，也可以是多級緩存，一般情況下cache的命中率可以達到70%左右，能夠比較有效的提升伺服器處理能力。Apache的deflate子產品可以壓縮傳輸資料，提高速度，2.0版本以後的cache子產品也内置實作磁盤和記憶體的緩存，而不必要一定做反向代理。

　　動态請求目前一般有兩種處理方式，一種是靜态化，在頁面發生變化時重新靜态頁面，現在大量的CMS，BBS都采用這種方案，加上cache，可以提供較快的通路速度。這種通常是寫操作較少的應用比較适合的解決方案。

　　另一種解決辦法是動态緩存，所有的通路都仍然通過應用處理，隻是應用處理的時候會更多的使用記憶體，而不是資料庫。通常通路資料庫的操作是極慢的，而通路記憶體的操作很快，至少是一個數量級的差距，使用memcached可以實作這一解決方案，做的好的memcache甚至可以達到90%以上的緩存命中率。10年前我用的還是2M的記憶體，那時的一本雜事上曾經風趣的描述一對父子的對話：

　　兒子：爸爸，我想要1G的記憶體。

　　爸爸：兒子，不行，即使是你過生日也不行。

　　時至今日，大記憶體的成本已經完全可以承受。Google使用了大量的PC機建立叢集用于資料處理，而我一直覺得，使用大記憶體PC可以很低成本的解決前端甚至中間的負載問題。由于PC硬碟壽命比較短，速度比較慢，CPU也稍慢，用于做web前端既便宜，又能充分發揮大記憶體的優勢，而且壞了的話隻需要替換即可，不存在資料的遷移問題。

　　下面就是應用的設計。應用在設計的時候應當盡量的設計成支援可擴充的資料庫設計，資料庫可以動态的添加，同時支援記憶體緩存，這樣的成本是最低的。另外一種應用設計的方法是采用中間件，例如ICE。這種方案的優點是前端應用可以設計的相對簡單，資料層對于前端應用透明，由ICE提供，資料庫分布式的設計在後端實作，使用ICE封裝後給前端應用使用，這路設計對每一部分設計的要求較低，将業務更好的分層，但由于引入了中間件，分了更多層，實作起來成本也相對較高。

　　在資料庫的設計上一方面可以使用叢集，一方面進行分組。同時在細節上将資料庫優化的原則盡量應用，資料庫結構和資料層應用在設計上盡量避免臨時表的建立、死鎖的産生。資料庫優化的原則在網上比較常見，多google一下就能解決問題。在資料庫的選擇上可以根據自己的習慣選擇，Oracle，MySQL等，并非Oracle就夠解決所有的問題，也并非MySQL就代表小應用，合适的就是最好的。

　　前面講的都是基于軟體的性能設計方案，實際上硬體的良好搭配使用也可以有效的降低時間成本，以及開發維護成本，隻是在這裡我們不再展開。

　　網站架構的設計是一個整體的工程，在設計的時候需要考慮到性能，可括展性，硬體成本，時間成本等等，如何根據業務的定位，資金，時間，人員的條件設計合适的方案是件比較困難的事情，但多想多實踐，終究會建立一套适合自己的網站設計理念，用于指導網站的設計工作，為網站的發展奠定良好的基礎。

　　yudunde 發表于 June 18, 2006 12:22 AM | Example

　　以往文章使用開源軟體，設計高性能可擴充網站

　　評論

　　Hi 敦德：

　　你的文章商業價值很高啊： 看比對出來的廣告

　　北京博大網人－南北互聯互通虛拟主機

　　249元/年=100M空間+100M郵箱+域名。南北互聯互通，高速通路。5年成功...

　　www.3271.cn

　　光明線上6年使用者超10萬－建網站面向全國

　　網站的設計：建網站980元，送域名空間，300種功能，網站自動生成，中...

　　www.aaawww.com

　　網站的設計－網站吧68元建站

　　提供網站的設計，NOON網站吧再掀自助網站風暴：超多功能上千頁面，全...

　　www.wangzhan8.com

　　信網－設計網站

　　360元建設網站，專業公司、多年經驗，按需訂制、非模闆制作，贈送域名...

　　www.clxtech.com

　　NOON設計網站專家68元建站－諾凡

　　NOON網站吧（京ICP證041545号）設計網站，再掀自助建站風暴：超多功能...

　　www.wangzhan8.com

　　億速互聯－讓您的企業在網絡中更精彩

　　專業網站整體策劃、資深美工設計、豐富的網站建設經驗。面向全國提供...

　　www.cnes.com.cn

　　最近我在做上下文廣告方面的系統：近期看看有沒有合作的機會。你的育兒部落格也是很有商業價值的内容。

　　Posted by: Che Dongat June 18, 2006 10:39 AM

　　哈哈，好的。我頁面上沒放廣告啊，你從哪裡查到的相關廣告?

　　Posted by: Donaldat June 18, 2006 11:27 AM

　　頂一下，其實很多時候我發現，瓶頸在資料庫上，

　　squid的方法不錯，但是很擔心被人當跳闆。

　　順便說一句，google現在的叢集已經不是隻有 pc了

　　Posted by: 二孬 at June 19, 2006 07:20 PM

　　squid參數裡可以設定的，避免被用來做正向代理

　　Posted by: Donaldat June 20, 2006 09:18 AM

　　奇怪，為什麼你和車東都沒有提到過是用LVS來做網站的負載均衡呢？？和DNS相比有什麼優缺點呢？

　　Posted by: 藍槐at June 28, 2006 11:51 AM

　　LVS目前應該還是主要用于在前端針對web server進行的分布式擴充，其實用DNS輪循雖然效果差一點，但基本可以滿足要求。

　　"IPVS無法檢查到請求的内容再選擇伺服器，這就要求後端伺服器組提供相同的服務，不管請求被發送到哪一台伺服器，傳回結果都是一樣的。"這對于大部分都是動态請求的網站來說無法接受:)

　　它還有個七層交換的項目，目的就是解決這個問題，但開發的不太完善，用的也不多。

　　Posted by: Donaldat June 28, 2006 01:19 PM

　　對不起，我的網站開發經驗不是很豐富，想問一下什麼情況需要根據請求内容來選擇伺服器呢？謝謝^_^

　　Posted by: 藍槐at June 30, 2006 11:26 AM

　　例如通路使用者的短消息資料和通路文章資料有時候是放在不同的應用伺服器上處理的，這就叫根據請求内容來選擇不同的伺服器。

本文轉自

http://www.example.net.cn/2006/06/open_source_high_performance.html