LAMP確實是一個非常優秀的架構，秉承着自由，開放，高效，易用的設計理念。
但是，本文不打算探討LAMP，網上有很多介紹LAMP的資料。
這裏，想給大家介紹另一個在LAMP上衍生出來的，以提升性能爲主要目的的開源網站架構。
1, 選擇高性能 OS
首先，不難理解，任何一個server最底層的支撐還是OS，而OS的選擇，主要包括 Unix, Windows server, Linux, BSD等等。
其中，開源的OS，有Linux, BSD及部分unix。從目前使用情況來看，linux還是網站首選OS之一。
但是，Linux由於其自由的特點，也給選擇產生了一些不便 - 發行版太多。
現有的主流版本包括 red hat(RHEL), ubuntu, 紅旗, opensuse, debian等。
其中，每一個發行版都有自己的特色，比如RHEL的穩定，ubuntu的易用，紅旗的中文支持很棒等。
但要以性能爲主，又兼顧穩定，易用性，以上都不是最佳選擇。
這裏推薦一個發行版，它是一個極限性能，加高度可定製，優化的 Linux - gentoo。
gentoo的性能優化是從kernel源碼編譯就開始入手了，通過選擇不同的源碼包，可以適應於不同的應用場景。
(不同內核介紹: http://imkenwu.javaeye.com/blog/168906 )
舉個經典的例子：國內，douban.com 在定製優化過的 gentoo 上跑的web服務器最高一天支撐了 2500 萬pv。
http://www.dbanotes.net/arch/douban_web_server.html
這種流量，哪怕是提供純靜態的內容，也是很恐怖的。
而支持這種大流量的，除了server本身，最關鍵的就是高度精簡的OS了。
所以，綜上所述，高性能網站推薦使用可優化，定製的 gentoo 作爲載體。
2, 選擇高性能 web server
Apache是 LAMP 架構最核心的 web server， 開源，模塊豐富，功能強大，穩定是它的絕對優勢。
在美國前100個網站中，有49%的使用apache。可見其影響力。
但是，有利有弊，apache的致命缺陷，就是多於臃腫，強大的功能，一定會帶來性能上的損耗。
面對這種情形，在市場上，有一支異軍突起，那就是更輕量級的 web server - lighty(lighttpd)。
官方爲它定義的口號是 fly light。
它具有非常低的內存開銷，cpu佔用率低，效能好，以及豐富的模塊支持等特點。
這讓他在短時間內佔據了14%以上的市場份額。並且有越來越多的人開始選擇使用lighty作爲前端 web server。
到這裏爲之，其實高性能 web server 非 lighty 莫屬。但更棒的是，依靠 gentoo 的高度定製化，我們還可以
進一步提升 lighty 的性能潛力-那就是定製 lighty。
3，選擇高性能 database
數據庫是任何網站走動態化內容展現及業務數據存儲的保障。
市面上的開源數據庫主要有 mysql , postgresql , berkeley db, sqlite 等。
其中，對比一下，
mysql ： 多線程，多處理器，高性能，5.0以上支持事務，豐富數據類型和sql語法，跨平臺。
postgresql ： 面向對象，集成web，支持事務，使用進程，速度略慢於mysql.
berkeley db ： 嵌入式，數據操作通過接口完成，跨語言。
sqlite ： 與php集成，支持ACID特性，支持大併發量，庫鎖。
從上面的對比中，不難看出，mysql 應該是性能，穩定性與功能性的綜合之選。
4，選擇高性能 script language
能與 lighty 結合的腳本語言，主要有 ruby, php, python, perl。方式主要是通過 fast-cgi 來訪問。
只從性能角度對比幾種語言:
不難看出，python 是此次測試中，性能最好的腳本語言。
動態處理方面有絕對優勢。對比 php ， 前者，可以更快的渲染輸出內容，並由經lighty， 高速flush緩存到瀏覽器。
值得一提的是， douban.com 也是使用 python 作爲應用服務器。
最便宜的高負載網站架構
關鍵字: 高負載 高性能 架構 網站LVS是基於IP虛擬分發的規則, 不同於apache,squid這些7層基於http協議的反向代理軟件, 前者在性能上能得到更好的保證！
另外, 後者在處理http header信息時, 會顯得很被動.
開源, 高性能, 這不就是我們所需要的嗎?
另外, 針對大訪問量, 還可以使用DNS輪詢+LVS集羣.
當然, 比起硬件均衡負載, 單點故障的風險會更大.
2，squid 做前端靜態頁面緩存, 包括 css, javascript
squid 是業內公認的優秀代理服務器，其緩存能力更讓許多高負載網站青睞！（比如新浪，網易等）
使用他, 通過本機內存+ 磁盤的集羣存儲方案, 能夠起到很好的加速作用!
使用squid, 也是大部分網站的節約成本之道.
3, lighttpd 提供圖片, css, javascript 服務. 做到靜態與動態分離.
採用lighttpd, 而不使用apache, 是因爲它對靜態內容的響應速度高於apache一到三倍.
這對於高負載網站是夢寐以求的.
加上, 在其前端部署了squid, 真正做到了, 超高命中率, 超快響應速度.
3，apache 用來處理php, url重定向, url過濾, 防洪水攻擊等等.
apache是業內主流http服務器，比較看重它的穩定性, 擴展性.
使用它, 製作一些推廣頁面, 一些需要快速開發的頁面, 最好不過了.
最重要的是, 它可以使用mod_jk或mod_proxy對複雜業務請求的進行代理.
比如, 將用戶註冊, 代理給jboss, 用java開發.
需要提一下的是, apache的module開發.
一句話 - 非常實用.
你可以只用apache提供的類庫, 就能很方便的開發一個http的日誌處理模塊.
另外, 它也可以與squid 集成, 從而, 形成一條很完美的加速鏈.
4，JBOSS 用來處理含複雜的業務邏輯與充當JAVAEE容器的角色
JBOSS是red hat旗下的優秀中間件產品，在java開源領域小有名氣，並且完全支持j2ee規範的，功能非常強大
使用他，既能保證業務流程的規範性，又可以節省開支（免費的）
java的優勢, 就不多說了.
5，mysql數據庫
使用mysql數據庫，單機達到百萬級別的數據存儲，及快速響應，應該是沒問題的.
如果網站本身訪問增長很快, 可以考慮mysql 集羣.
從而獲得高伸縮性, 高訪問性能.
不管是通過 master+slaver的主從結構.還是根據業務進行分表.
mysql的集羣特性, 都是網站首選的.
6，memcache作爲分佈式緩存
基於中央存放的緩存載體, 一般都需要集羣.
基於c寫的memcache, 可以很自豪的頂起高性能緩存的帽子.
它幾乎可以緩存任何數據. 包括 html, java對象, 文件等等.
重要的是, 它給jboss, apache等服務器實現高效的緩存方案, 提供了有力的保證.
LVS
======================================
.....
apache mod_jk / mod_proxy+ jboss
apache mod_jk / mod_proxy+ jboss
.....
squid + lighttpd
squid + lighttpd
....
=================================
....
mysql + memcache
mysql + memcache
......
================================
Internet的快速增長使多媒體網絡服務器，特別是Web服務器， 面對的訪問者數量快速增加，網絡服務器需要具備提供大量併發訪問服務的能力。 例如Yahoo每天會收到數百萬次的訪問請求，因此對於提供大負載Web服務的服務器來講，CPU、I/O處理能力很快會成爲瓶頸。
簡單的 提高硬件性能並不能真正解決這個問題，因爲單臺服務器的性能總是有限的，一般來講，一臺PC服務器所能提供的併發訪問處理能力大約爲1000個，更爲高檔 的專用服務器能夠支持3000-5000個併發訪問，這樣的能力還是無法滿足負載較大的網站的要求。尤其是網絡請求具有突發性，當某些重大事件發生時，網 絡訪問就會急劇上升，從而造成網絡瓶頸，例如在網上發佈的克林頓彈劾書就是很明顯的例子。必須採用多臺服務器提供網絡服務，並將網絡請求分配給這些服務器 分擔，才能提供處理大量併發服務的能力。
當使用多臺服務器來分擔負載的時候，最簡單的辦法是將不同的服務器用在不同的方面。 按提供的內容進行分割時，可以將一臺服務器用於提供新聞頁面，而另一臺用於提供遊戲頁面；或者可以按服務器的功能進行分割，將一臺服務器用於提供靜態頁面 訪問，而另一些用於提供CGI等需要大量消耗資源的動態頁面訪問。然而由於網絡訪問的突發性，使得很難確定那些頁面造成的負載太大，如果將服務的頁面分割 的過細就會造成很大浪費。事實上造成負載過大的頁面常常是在變化中的，如果要經常按照負載變化來調整頁面所在的服務器，那麼勢必對管理和維護造成極大的問 題。因此這種分割方法只能是大方向的調整，對於大負載的網站，根本的解決辦法還需要應用負載均衡技術。
負載均衡的思路下多臺 服務器爲對稱方式，每臺服務器都具備等價的地位，都可以單獨對外提供服務而無須其他服務器的輔助。然後通過某種負載分擔技術，將外部發送來的請求均勻分配 到對稱結構中的某一臺服務器上，而接收到請求的服務器都獨立迴應客戶機的請求。由於建立內容完全一致的Web服務器並不複雜，可以使用服務器同步更新或者 共享存儲空間等方法來完成，因此負載均衡技術就成爲建立一個高負載Web站點的關鍵性技術。
- 基於特定服務器軟件的負載均衡
很 多網絡協議都支持“重定向”功能，例如在HTTP協議中支持Location指令，接收到這個指令的瀏覽器將自動重定向到Location指明的另一個 URL上。由於發送Location指令比起執行服務請求，對Web服務器的負載要小的多，因此可以根據這個功能來設計一種負載均衡的服務器。任何時候 Web服務器認爲自己負載較大的時候，它就不再直接發送回瀏覽器請求的網頁，而是送回一個Locaction指令，讓瀏覽器去服務器集羣中的其他服務器上 獲得所需要的網頁。
在這種方式下，服務器本身必須支持這種功能，然而具體實現起來卻有很多困難，例如一臺服務器如何能保證它重 定向過的服務 器是比較空閒的，並且不會再次發送Location指令？Location指令和瀏覽器都沒有這方面的支持能力，這樣很容易在瀏覽器上形成一種死循環。因 此這種方式實際應用當中並不多見，使用這種方式實現的服務器集羣軟件也較少。有些特定情況下可以使用CGI（包括使用FastCGI或mod_perl擴 展來改善性能）來模擬這種方式去分擔負載，而Web服務器仍然保持簡潔、高效的特性，此時避免Location循環的任務將由用戶的CGI程序來承擔。
- 基於DNS的負載均衡
由 於基於服務器軟件的負載均衡需要改動軟件，因此常常是得不償失，負載均衡最好是在服務器軟件之外來完成，這樣才能利用現有服務器軟件的種種優勢。最早的負 載均衡技術是通過DNS服務中的隨機名字解析來實現的，在DNS服務器中，可以爲多個不同的地址配置同一個名字，而最終查詢這個名字的客戶機將在解析這個 名字時得到其中的一個地址。因此，對於同一個名字，不同的客戶機會得到不同的地址，他們也就訪問不同地址上的Web服務器，從而達到負載均衡的目的。
![]()
例如如果希望使用三個Web服務器來回應對www.exampleorg.org.cn的HTTP請求，就可以設置該域的DNS服務器中關於該域的數據包括有與下面例子類似的結果：
www1 IN A 192.168.1.1
www2 IN A 192.168.1.2
www3 IN A 192.168.1.3
www IN CNAME www1
www IN CNAME www2
www IN CNAME www3
此後外部的客戶機就可能隨機的得到對應www的不同地址，那麼隨後的HTTP請求也就發送給不同地址了。
DNS 負載均衡的優點是簡單、易行，並且服務器可以位於互聯網的任意位置上，當前使用在包括Yahoo在內的Web站點上。然而它也存在不少缺點，一個缺點是爲 了保證DNS數據及時更新，一般都要將DNS的刷新時間設置的較小，但太小就會造成太大的額外網絡流量，並且更改了DNS數據之後也不能立即生效；第二點 是DNS負載均衡無法得知服務器之間的差異，它不能做到爲性能較好的服務器多分配請求，也不能瞭解到服務器的當前狀態，甚至會出現客戶請求集中在某一臺服 務器上的偶然情況。
- 反向代理負載均衡
使用代理 服務器可以將請求轉發給內部的Web服務器，使用這種加速 模式顯然可以提升靜態網頁的訪問速度。因此也可以考慮使用這種技術，讓代理服務器將請求均勻轉發給多臺內部Web服務器之一上，從而達到負載均衡的目的。 這種代理方式與普通的代理方式有所不同，標準代理方式是客戶使用代理訪問多個外部Web服務器，而這種代理方式是多個客戶使用它訪問內部Web服務器，因 此也被稱爲反向代理模式。
實現這個反向代理能力並不能算是一個特別複雜的任務，但是在負載均衡中要求特別高的效率，這樣實現起 來就不是十分 簡單的了。每針對一次代理，代理服務器就必須打開兩個連接，一個爲對外的連接，一個爲對內的連接，因此對於連接請求數量非常大的時候，代理服務器的負載也 就非常之大了，在最後反向代理服務器會成爲服務的瓶頸。例如，使用Apache的mod_rproxy模塊來實現負載均衡功能時，提供的併發連接數量受 Apache本身的併發連接數量的限制。一般來講，可以使用它來對連接數量不是特別大，但每次連接都需要消耗大量處理資源的站點進行負載均衡，例如搜尋。
使 用反向代理的好處是，可以將負載均衡和代理服務器的高速緩存技術結合在一起，提供有益的性能，具備額外的安全性，外部客戶不能直接訪問真實的服務器。並且 實現起來可以實現較好的負載均衡策略，將負載可以非常均衡的分給內部服務器，不會出現負載集中到某個服務器的偶然現象。
- 基於NAT的負載均衡技術
網 絡地址轉換爲在內部地址和外部地址之間進行轉換，以便具備內部地址的計算機能訪問外部網絡，而當外部網絡中的計算機訪問地址轉換網關擁有的某一外部地址 時，地址轉換網關能將其轉發到一個映射的內部地址上。因此如果地址轉換網關能將每個連接均勻轉換爲不同的內部服務器地址，此後外部網絡中的計算機就各自與 自己轉換得到的地址上服務器進行通信，從而達到負載分擔的目的。
![]()
地 址轉換可以通過軟件方式來實現，也可以通過硬件方式來實現。使用硬件方式進行操作一般稱爲交換，而當交換必須保存TCP連接信息的時候，這種針對OSI網 絡層的操作就被稱爲第四層交換。支持負載均衡的網絡地址轉換爲第四層交換機的一種重要功能，由於它基於定製的硬件芯片，因此其性能非常優秀，很多交換機聲 稱具備400MB-800MB的第四層交換能力，然而也有一些資料表明，在如此快的速度下，大部分交換機就不再具備第四層交換能力了，而僅僅支持第三層甚 至第二層交換。
然而對於大部分站點來講，當前負載均衡主要是解決Web服務器處理能力瓶頸的，而非網絡傳輸能力，很多站點的互聯網連接帶寬總共也不過10MB，只有極少的站點能夠擁有較高速的網絡連接，因此一般沒有必要使用這些負載均衡器這樣的昂貴設備。
使 用軟件方式來實現基於網絡地址轉換的負載均衡則要實際的多，除了一些廠商提供的解決方法之外，更有效的方法是使用免費的自由軟件來完成這項任務。其中包括 Linux Virtual Server Project中的NAT實現方式，或者本文作者在FreeBSD下對natd的修訂版本。一般來講，使用這種軟件方式來實現地址轉換，中心負載均衡器存 在帶寬限制，在100MB的快速以太網條件下，能得到最快達80MB的帶寬，然而在實際應用中，可能只有40MB-60MB的可用帶寬。
- 擴展的負載均衡技術
上 面使用網絡地址轉換來實現負載分擔，毫無疑問所有的網絡連接都必須通過中心負載均衡器，那麼如果負載特別大，以至於後臺的服務器數量不再在是幾臺、十幾 臺，而是上百臺甚至更多，即便是使用性能優秀的硬件交換機也回遇到瓶頸。此時問題將轉變爲，如何將那麼多臺服務器分佈到各個互聯網的多個位置，分散網絡負 擔。當然這可以通過綜合使用DNS和NAT兩種方法來實現，然而更好的方式是使用一種半中心的負載均衡方式。
在這種半中心的負載均衡方式下，即當客戶請求發送給負載均衡器的時候，中心負載均衡器將請求打包併發送給某個服務器，而服務器的迴應請求不再返回給中心負載均衡器，而是直接返回給客戶，因此中心負載均衡器只負責接受並轉發請求，其網絡負擔就較小了。
上圖來自Linux Virtual Server Project，爲他們使用IP隧道實現的這種負載分擔能力的請求/迴應過程，此時每個後臺服務器都需要進行特別的地址轉換，以欺騙瀏覽器客戶，認爲它的迴應爲正確的迴應。
同樣，這種方式的硬件實現方式也非常昂貴，但是會根據廠商的不同，具備不同的特殊功能，例如對SSL的支持等。
由於這種方式比較複雜，因此實現起來比較困難，它的起點也很高，當前情況下網站並不需要這麼大的處理能力。
比 較上面的負載均衡方式，DNS最容易，也最常用，能夠滿足一般的需求。但如果需要進一步的管理和控制，可以選用反向代理方式或NAT方式，這兩種之間進行 選擇主要依賴緩衝是不是很重要，最大的併發訪問數量是多少等條件。而如果網站上對負載影響很厲害的CGI程序是由網站自己開發的，也可以考慮在程序中自己 使用Locaction來支持負載均衡。半中心化的負載分擔方式至少在國內當前的情況下還不需要。
web集羣服務的負載均衡方案選擇與實現
web應用服務器集羣系統，是由一羣同時運行同一個web應用的服務器組成的集羣系統，在外界看來，就像是一個服務器一樣。爲了均衡集羣服務器的負載，達到優化系統性能的目的，集羣服務器將衆多的訪問請求，分散到系統中的不同節點進行處理。從而實現了更高的有效性和穩定性，而這也正是基於Web的企業應用所必須具備的特性。
高可靠性可以看作爲系統的一種冗餘設定。對於一個特定的請求，如果所申請的服務器不能進行處理的話，那麼其他的服務器能不能對之進行有效的處理呢？對於一個高效的系統，如果一個Web服務器失敗的話，其他的服務器可以馬上取代它的位置，對所申請的請求進行處理，而且這一過程對用戶來說，要儘可能的透明，使用戶察覺不到！
穩定性決定了應用程序能否支持不斷增長的用戶請求數量，它是應用程序自身的一種能力。穩定性是影響系統性能的衆多因素的一種有效的測量手段，包括機羣系統所能支持的同時訪問系統的最大用戶數目以及處理一個請求所需要的時間。
在現有衆多的均衡服務器負載的方法中，廣泛研究並使用的是以下兩個方法：
- DNS負載平衡的方法RR-DNS(Round-Robin Domain Name System)
- 負載均衡器
以下，我們將就這兩種方法進行討論。
DNS輪流排程 RR-DNS(Round-Robin Domain Name System)
域名服務器（Domain Name Server）中的數據文件將主機名字映射到其IP地址。當你在瀏覽器中鍵入一個URL時（例如：www.loadbalancedsite.com），瀏覽器則將請求發送到DNS，要求其返回相應站點的IP地址，這被稱爲DNS查詢。當瀏覽器獲得該站點的IP地址後，便通過該IP地址連接到所要訪問的站點，將頁面展現在用戶面前。
域名服務器（DNS）通常包含一個單一的IP地址與該IP地址所映射的站點的名稱的列表。在我們上面所假象的例子中，www.loadbalancedsite.com 這個站點的映射IP地址爲203.24.23.3。
爲了利用DNS均衡服務器的負載，對於同一個站點來講，在DNS服務器中同時擁有幾個不同的IP地址。這幾個IP地址代表集羣中不同的機器，並在邏輯上映射到同一個站點名。通過我們的例子可以更好的理解這一點，www.loadbalancedsite.com將通過下面的三個IP地址發佈到一個集羣中的三臺機器上：
203.34.23.3
203.34.23.4
203.34.23.5
在本例中，DNS服務器中包含下面的映射表：
www.loadbalancedsite.com 203.34.23.3
www.loadbalancedsite.com 203.34.23.4
www.loadbalancedsite.com 203.34.23.5
當第一個請求到達DNS服務器時，返回的是第一臺機器的IP地址203.34.23.3；當第二個請求到達時，返回的是第二臺機器的IP地址203.34.23.4，以此類推。當第四個請求到達時，第一臺機器的IP地址將被再次返回，循環調用。
利用上述的DNS Round Robin技術，對於某一個站點的所有請求將被平均的分配到及羣中的機器上。因此，在這種技術中，集羣中的所有的節點對於網絡來說都是可見的。
DNS 輪流排程的優勢
DNS Round Robin的最大的優點就是易於實現和代價低廉：
- 代價低，易於建立。 爲了支持輪流排程，系統管理員只需要在DNS服務器上作一些改動，而且在許多比較新的版本的DNS服務器上已經增加了這種功能。對於Web應用來說，不需要對代碼作任何的修改；事實上，Web應用本身並不會意識到負載均衡配置，即使在它面前。
- 簡單. 不需要網絡專家來對之進行設定，或在出現問題時對之進行維護。
DNS 輪流排程的缺點
這種基於軟件的負載均衡方法主要存在兩處不足，一是不實時支持服務期間的關聯，一是不具有高可靠性。
• 不支持服務器間的一致性。服務器一致性是負載均衡系統所應具備的一種能力，通過它，系統可以根據會話信息是屬於服務器端的，還是底層數據庫級別的，繼而將用戶的請求導向相應的服務器。而DNS輪流排程則不具備這種智能化的特性。它是通過cookie、隱藏域、重寫URL三種方法中的一種來進行相似的判斷的。當用戶通過上述基於文本標誌的方法與服務器建立連接之後，其所有的後續訪問均是連接到同一個服務器上。問題是，服務器的IP是被瀏覽器暫時存放在緩存中，一旦記錄過期，則需要重新建立連接，那麼同一個用戶的請求很可能被不同的服務器進行處理，則先前的所有會話信息便會丟失。
- 不支持高可靠性。設想一個具有N個節點的集羣。如果其中的一個節點毀壞，那麼所有的訪問該節點的請求將不會有所迴應，這是任何人都不願意看到的。比較先進的路由器可以通過每隔一定的時間間隔，對節點檢查，如果有毀壞的節點，則將之從列表中去除的方法，解決這個問題。但是，由於在Internet上，ISPs將衆多的DNS存放在緩存中，以節省訪問時間，因此，DNS的更新就會變得非常緩慢，以至於有的用戶可能會訪問一些已經不存在的站點，或者一些新的站點得不到訪問。所以，儘管DNS輪流排程在一定程度上解決了負載均衡問題，但這種狀況的改變並不是十分樂觀和有效的。
除了上面介紹的輪流排程方法外，還有三種DNS負載均衡處理分配方法，將這四種方法列出如下：
Ø Round robin (RRS)： 將工作平均的分配到服務器 (用於實際服務主機性能一致)
Ø Least-connections (LCS)： 向較少連接的服務器分配較多的工作(IPVS 表存儲了所有的活動的連接。用於實際服務主機性能一致。)
Ø Weighted round robin (WRRS)： 向較大容量的服務器分配較多的工作。可以根據負載信息動態的向上或向下調整。 (用於實際服務主機性能不一致時)
Ø Weighted least-connections (WLC)： 考慮它們的容量向較少連接的服務器分配較多的工作。容量通過用戶指定的砝碼來說明，可以根據裝載信息動態的向上或向下調整。(用於實際服務主機性能不一致時)
負載均衡器
負載均衡器通過虛擬IP地址方法，解決了輪流排程所面臨的許多問題。使用了負載均衡器集羣系統，在外部看來，像是具有一個IP地址的單一服務器一樣，當然，這個IP地址是虛擬的，它映射了集羣中的每一臺機器的地址。所以，在某種程度上，負載均衡器是將整個集羣的IP地址報漏給外部網絡。
當請求到達負載均衡器時，它會重寫該請求的頭文件，並將之指定到集羣中的機器上。如果某臺機器被從集羣中移除了，請求不會別發往已經不存在的服務器上，因爲所有的機器表面上都具有同一個IP地址，即使集羣中的某個節點被移除了，該地址也不會發生變化。而且，internet上緩存的DNS條目也不再是問題了。當返回一個應答時，客戶端看到的只是從負載均衡器上所返回的結果。也就是說，客戶端操作的對象是負載均衡器，對於其更後端的操作，對客戶端來講，是完全透明的。
負載均衡器的優點
• 服務器一致性. 負載均衡器讀取客戶端發出的每一個請求中所包含的cookies或url解釋。基於所讀出的這些信息，負載均衡器就可以重寫報頭並將請求發往集羣中合適的節點上，該節點維護着相應客戶端請求的會話信息。在HTTP通信中，負載均衡器可以提供服務器一致性，但並不是通過一個安全的途徑（例如：HTTPS）來提供這種服務。當消息被加密後（SSL），負載均衡器就不能讀出隱藏在其中的會話信息。
• 通過故障恢復機制獲得高可靠性. 故障恢復發生在當集羣中某個節點不能處理請求，需將請求重新導向到其他節點時。主要有兩種故障恢復：
• 請求級故障恢復。當集羣中的一個節點不能處理請求時（通常是由於down機），請求被髮送到其他節點。當然，在導向到其他節點的同時，保存在原節點上的會話信息將會丟失。
• 透 明會話故障恢復。當一個引用失敗後，負載均衡器會將之發送到集羣中其他的節點上，以完成操作，這一點對用戶來說是透明的。由於透明會話故障恢復需要節點具 備相應的操作信息，因此爲了實現該功能，集羣中的所有節點必須具有公共存儲區域或通用數據庫，存儲會話信息數據，以提供每個節點在進行單獨進程會話故障恢 復時所需要的操作信息。
• 統計計量。既然所有的Web應用請求都必須經過負載均衡系統，那麼系統就可以確定活動會話的數量，在任何實例訪問中的活動會話的數目，應答的次數，高峯負載次數，以及在高峯期和低谷期的會話的數目，還有其他更多的。所有的這些統計信息都可以被很好的用來調整整個系統的性能。
負載均衡器的缺點
硬件路由的缺點在於費用、複雜性以及單點失敗的。由於所有的請求均是通過一個單一的硬件負載均衡器來傳遞，因此，負載均衡器上的任何故障都將導致整個站點的崩潰。
HTTPS請求的負載均衡
正如上面所提到的，很難在那些來自HTTPS的請求上進行負載均衡和會話信息維護處理。因爲，這些請求中的信息已經被加密了。負載均衡器沒有能力處理這類請求。不過，這裏有兩種方法可以解決這一問題：
- 代理網絡服務器
- 硬件SSL解碼器
代理服務器位於服務器集羣之前，首先由它接受所有的請求並對之進行解密，然後將這些處理後的請求根據頭信息重新發往相應的節點上，這種方式不需要硬件上的支持，但會增加代理服務器的額外的負擔。
硬件SSL解碼器，則是在請求到達負載均衡器之前，先經由它進行解密處理。這種方式比代理服務器的處理速度要快捷一些。但代價也高，而且實現比較複雜。Internet的規模每一百天就會增長一倍，客戶希望獲得7天24小時的不間斷可用性及較快的系統反應時間，而不願屢次看到某個站點“Server Too Busy”及頻繁的系統故障。
網絡的各個核心部分隨着業務量的提高、訪問量和數據流量的快速增長，其處理能力和計算強度也相應增大，使得單一設備根本無法承擔。在此情況下，如果扔掉 現有設備去做大量的硬件升級，這樣將造成現有資源的浪費，而且如果再面臨下一次業務量的提升，這又將導致再一次硬件升級的高額成本投入，甚至性能再卓越的 設備也不能滿足當前業務量的需求。於是，負載均衡機制應運而生。
負載均衡（Load Balance）建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。
負載均衡有兩方面的含義：首先，大量的併發訪問或數據流量分擔到多臺節點設備上分別處理，減少用戶等待響應的時間；其次，單個重負載的運算分擔到多臺節點設備上做並行處理，每個節點設備處理結束後，將結果彙總，返回給用戶，系統處理能力得到大幅度提高。
本文所要介紹的負載均衡技術主要是指在均衡服務器羣中所有服務器和應用程序之間流量負載的應用，目前負載均衡技術大多數是用於提高諸如在Web服務器、FTP服務器和其它關鍵任務服務器上的Internet服務器程序的可用性和可伸縮性。
負載均衡技術分類
目前有許多不同的負載均衡技術用以滿足不同的應用需求，下面從負載均衡所採用的設備對象、應用的網絡層次（指OSI參考模型）及應用的地理結構等來分類。
軟/硬件負載均衡
軟件負載均衡解決方案是指在一臺或多臺服務器相應的操作系統上安裝一個或多個附加軟件來實現負載均衡，如DNS Load
Balance，CheckPoint Firewall-1
ConnectControl等，它的優點是基於特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。
軟件解決方案 缺點也較多，因爲每臺服務器上安裝額外的軟件運行會消耗系統不定量的資源，越是功能強大的模塊，消耗得越多，所以當連接請求特別大的時候，軟件本身會成爲 服務器工作成敗的一個關鍵；軟件可擴展性並不是很好，受到操作系統的限制；由於操作系統本身的Bug，往往會引起安全問題。
硬件負載均衡解決方案是直接在服務器和外部網絡間安裝負載均衡設備，這種設備我們通常稱之爲負載均衡器，由於專門的設備完成專門的任務，獨立於操作系統，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。
負載均衡器有多種多樣的形式，除了作爲獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於服務器與Internet鏈接之間，有些則以兩塊網絡適配器將這一功能集成到PC中，一塊連接到Internet上，一塊連接到後端服務器羣的內部網絡上。
一般而言，硬件負載均衡在功能、性能上優於軟件方式，不過成本昂貴。
本地/全局負載均衡
負載均衡從其應用的地理結構上分爲本地負載均衡(Local Load Balance)和全局負載均衡(Global Load
Balance，也叫地域負載均衡)，本地負載均衡是指對本地的服務器羣做負載均衡，全局負載均衡是指對分別放置在不同的地理位置、有不同網絡結構的服務
器羣間作負載均衡。
本地負載均衡能有效地解決數據流量過大、網絡負荷過重的問題，並且不需花費昂貴開支購置性能卓越的服務器，充分利用 現有設備，避免服務器單點故障造成數據流量的損失。其有靈活多樣的均衡策略把數據流量合理地分配給服務器羣內的服務器共同負擔。即使是再給現有服務器擴充 升級，也只是簡單地增加一個新的服務器到服務羣中，而不需改變現有網絡結構、停止現有的服務。
全局負載均衡主要用於在一個多區域擁有自己服務器的站點，爲了使全球用戶只以一個IP地址或域名就能訪問到離自己最近的服務器，從而獲得最快的訪問速度，也可用於子公司分散站點分佈廣的大公司通過Intranet（企業內部互聯網）來達到資源統一合理分配的目的。
全局負載均衡有以下的特點：
實現地理位置無關性，能夠遠距離爲用戶提供完全的透明服務。
除了能避免服務器、數據中心等的單點失效，也能避免由於ISP專線故障引起的單點失效。
解決網絡擁塞問題，提高服務器響應速度，服務就近提供，達到更好的訪問質量。
網絡層次上的負載均衡
針對網絡上負載過重的不同瓶頸所在，從網絡的不同層次入手，我們可以採用相應的負載均衡技術來解決現有問題。
隨着帶寬增加，數據流量不斷增大，網絡核心部分的數據接口將面臨瓶頸問題，原有的單一線路將很難滿足需求，而且線路的升級又過於昂貴甚至難以實現，這時就可以考慮採用鏈路聚合（Trunking）技術。
鏈路聚合技術（第二層負載均衡）將多條物理鏈路當作一條單一的聚合邏輯鏈路使用，網絡數據流量由聚合邏輯鏈路中所有物理鏈路共同承擔，由此在邏輯上增大了鏈路的容量，使其能滿足帶寬增加的需求。
現代負載均衡技術通常操作於網絡的第四層或第七層。第四層負載均衡將一個Internet上合法註冊的IP地址映射爲多個內部服務器的IP地址，對每次 TCP連接請求動態使用其中一個內部IP地址，達到負載均衡的目的。在第四層交換機中，此種均衡技術得到廣泛的應用，一個目標地址是服務器羣VIP（虛擬 IP，Virtual IP address）連接請求的數據包流經交換機，交換機根據源端和目的IP地址、TCP或UDP端口號和一定的負載均衡策略，在服務器IP和VIP間進行映 射，選取服務器羣中最好的服務器來處理連接請求。
第七層負載均衡控制應用層服務的內容，提供了一種對訪問流量的高層控制方式，適合對HTTP服務器羣的應用。第七層負載均衡技術通過檢查流經的HTTP報頭，根據報頭內的信息來執行負載均衡任務。
第七層負載均衡優點表現在如下幾個方面：
通過對HTTP報頭的檢查，可以檢測出HTTP400、500和600系列的錯誤信息，因而能透明地將連接請求重新定向到另一臺服務器，避免應用層故障。
可根據流經的數據類型（如判斷數據包是圖像文件、壓縮文件或多媒體文件格式等），把數據流量引向相應內容的服務器來處理，增加系統性能。
能根據連接請求的類型，如是普通文本、圖象等靜態文檔請求，還是asp、cgi等的動態文檔請求，把相應的請求引向相應的服務器來處理，提高系統的性能及安全性。
第七層負載均衡受到其所支持的協議限制（一般只有HTTP），這樣就限制了它應用的廣泛性，並且檢查HTTP報頭會佔用大量的系統資源，勢必會影響到系統的性能，在大量連接請求的情況下，負載均衡設備自身容易成爲網絡整體性能的瓶頸。
負載均衡策略
在實際應用中，我們可能不想僅僅是把客戶端的服務請求平均地分配給內部服務器，而不管服務器是否宕機。而是想使Pentium III服務器比Pentium II能接受更多的服務請求，一臺處理服務請求較少的服務器能分配到更多的服務請求，出現故障的服務器將不再接受服務請求直至故障恢復等等。
選擇合適的負載均衡策略，使多個設備能很好的共同完成任務，消除或避免現有網絡負載分佈不均、數據流量擁擠反應時間長的瓶頸。在各負載均衡方式中，針對不同的應用需求，在OSI參考模型的第二、三、四、七層的負載均衡都有相應的負載均衡策略。
負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：一、負載均衡算法，二、對網絡系統狀況的檢測方式和能力。
考慮到服務請求的不同類型、服務器的不同處理能力以及隨機選擇造成的負載分配不均勻等問題，爲了更加合理的把負載分配給內部的多個服務器，就需要應用相應的能夠正確反映各個服務器處理能力及網絡狀態的負載均衡算法：
輪循均衡（Round Robin）：每一次來自網絡的請求輪流分配給內部中的服務器，從1至N然後重新開始。此種均衡算法適合於服務器組中的所有服務器都有相同的軟硬件配置並且平均服務請求相對均衡的情況。
權 重輪循均衡（Weighted Round
Robin）：根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：服務器A的權值被設計成1，B的權值是
3，C的權值是6，則服務器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器得到更多的使用率，避免低性能的
服務器負載過重。
隨機均衡（Random）：把來自網絡的請求隨機分配給內部中的多個服務器。
權重隨機均衡（Weighted Random）：此種均衡算法類似於權重輪循算法，不過在處理請求分擔時是個隨機選擇的過程。
響 應速度均衡（Response
Time）：負載均衡設備對內部各服務器發出一個探測請求（例如Ping），然後根據內部中各服務器對探測請求的最快響應時間來決定哪一臺服務器來響應客
戶端的服務請求。此種均衡算法能較好的反映服務器的當前運行狀態，但這最快響應時間僅僅指的是負載均衡設備與服務器間的最快響應時間，而不是客戶端與服務
器間的最快響應時間。
最少連接數均衡（Least
Connection）：客戶端的每一次請求服務在服務器停留的時間可能會有較大的差異，隨着工作時間加長，如果採用簡單的輪循或隨機均衡算法，每一臺服
務器上的連接進程可能會產生極大的不同，並沒有達到真正的負載均衡。最少連接數均衡算法對內部中需負載的每一臺服務器都有一個數據記錄，記錄當前該服務器
正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的服務器，使均衡更加符合實際情況，負載更加均衡。此種均衡算法適合長時處理
的請求服務，如FTP。
處理能力均衡：此種均衡算法將把服務請求分配給內部中處理負荷（根據服務器CPU型號、CPU數量、內存大
小及當前連接數等換算而成）最輕的服務器，由於考慮到了內部服務器的處理能力及當前網絡運行狀況，所以此種均衡算法相對來說更加精確，尤其適合運用到第七
層（應用層）負載均衡的情況下。
DNS響應均衡（Flash
DNS）：在Internet上，無論是HTTP、FTP或是其它的服務請求，客戶端一般都是通過域名解析來找到服務器確切的IP地址的。在此均衡算法
下，分處在不同地理位置的負載均衡設備收到同一個客戶端的域名解析請求，並在同一時間內把此域名解析成各自相對應服務器的IP地址（即與此負載均衡設備在
同一位地理位置的服務器的IP地址）並返回給客戶端，則客戶端將以最先收到的域名解析IP地址來繼續請求服務，而忽略其它的IP地址響應。在種均衡策略適
合應用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。
儘管有多種的負載均衡算法可以較好的把數據流量分配給服務器去負載，但如 果負載均衡策略沒有對網絡系統狀況的檢測方式和能力，一旦在某臺服務器或某段負載均衡設備與服務器網絡間出現故障的情況下，負載均衡設備依然把一部分數據 流量引向那臺服務器，這勢必造成大量的服務請求被丟失，達不到不間斷可用性的要求。所以良好的負載均衡策略應有對網絡故障、服務器系統故障、應用服務故障 的檢測方式和能力：
Ping偵測：通過ping的方式檢測服務器及網絡系統狀況，此種方式簡單快速，但只能大致檢測出網絡及服務器上的操作系統是否正常，對服務器上的應用服務檢測就無能爲力了。
TCP Open偵測：每個服務都會開放某個通過TCP連接，檢測服務器上某個TCP端口（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。
HTTP URL偵測：比如向HTTP服務器發出一個對main.html文件的訪問請求，如果收到錯誤信息，則認爲服務器出現故障。
負載均衡策略的優劣除受上面所講的兩個因素影響外，在有些應用情況下，我們需要將來自同一客戶端的所有請求都分配給同一臺服務器去負擔，例如服務器將客
戶端註冊、購物等服務請求信息保存的本地數據庫的情況下，把客戶端的子請求分配給同一臺服務器來處理就顯的至關重要了。有兩種方式可以解決此問題，一是根
據IP地址把來自同一客戶端的多次請求分配給同一臺服務器處理，客戶端IP地址與服務器的對應信息是保存在負載均衡設備上的；二是在客戶端瀏覽器
cookie內做獨一無二的標識來把多次請求分配給同一臺服務器處理，適合通過代理服務器上網的客戶端。
還有一種路徑外返回模式 （Out of Path
Return），當客戶端連接請求發送給負載均衡設備的時候，中心負載均衡設備將請求引向某個服務器，服務器的迴應請求不再返回給中心負載均衡設備，即繞
過流量分配器，直接返回給客戶端，因此中心負載均衡設備只負責接受並轉發請求，其網絡負擔就減少了很多，並且給客戶端提供了更快的響應時間。此種模式一般
用於HTTP服務器羣，在各服務器上要安裝一塊虛擬網絡適配器，並將其IP地址設爲服務器羣的VIP，這樣才能在服務器直接回應客戶端請求時順利的達成三
次握手。
負載均衡實施要素
負載均衡方案應是在網站建設初期就應考慮的問題，不過有時隨着訪問流量
的爆炸性增長，超出決策者的意料，這也就成爲不得不面對的問題。當我們在引入某種負載均衡方案乃至具體實施時，像其他的許多方案一樣，首先是確定當前及將
來的應用需求，然後在代價與收效之間做出權衡。
針對當前及將來的應用需求，分析網絡瓶頸的不同所在，我們就需要確立是採用哪一類的負載均衡技術，採用什麼樣的均衡策略，在可用性、兼容性、安全性等等方面要滿足多大的需求，如此等等。
不管負載均衡方案是採用花費較少的軟件方式，還是購買代價高昂在性能功能上更強的第四層交換機、負載均衡器等硬件方式來實現，亦或其他種類不同的均衡技術，下面這幾項都是我們在引入均衡方案時可能要考慮的問題：
性
能：性能是我們在引入均衡方案時需要重點考慮的問題，但也是一個最難把握的問題。衡量性能時可將每秒鐘通過網絡的數據包數目做爲一個參數，另一個參數是均
衡方案中服務器羣所能處理的最大併發連接數目，但是，假設一個均衡系統能處理百萬計的併發連接數，可是卻只能以每秒2個包的速率轉發，這顯然是沒有任何作
用的。
性能的優劣與負載均衡設備的處理能力、採用的均衡策略息息相關，並且有兩點需要注意：一、均衡方案對服務器羣整體的性能，這是響應客戶端連接請求速度的關
鍵；二、負載均衡設備自身的性能，避免有大量連接請求時自身性能不足而成爲服務瓶頸。
有時我們也可以考慮採用混合型負載均衡策略來提升服務器羣的總體性能，如DNS負載均衡與NAT負載均衡相結合。另外，針對有大量靜態文檔請求的站點，也
可以考慮採用高速緩存技術，相對來說更節省費用，更能提高響應性能；對有大量ssl/xml內容傳輸的站點，更應考慮採用ssl/xml加速技術。
可
擴展性：IT技術日新月異，一年以前最新的產品，現在或許已是網絡中性能最低的產品；業務量的急速上升，一年前的網絡，現在需要新一輪的擴展。合適的均衡
解決方案應能滿足這些需求，能均衡不同操作系統和硬件平臺之間的負載，能均衡HTTP、郵件、新聞、代理、數據庫、防火牆和
Cache等不同服務器的負載，並且能以對客戶端完全透明的方式動態增加或刪除某些資源。
靈活性：均衡解決方案應能靈活地提供不同的應用需求，滿足應用需求的不斷變化。在不同的服務器羣有不同的應用需求時，應有多樣的均衡策略提供更廣泛的選擇。
可
靠性：在對服務質量要求較高的站點，負載均衡解決方案應能爲服務器羣提供完全的容錯性和高可用性。但在負載均衡設備自身出現故障時，應該有良好的冗餘解決
方案，提高可靠性。使用冗餘時，處於同一個冗餘單元的多個負載均衡設備必須具有有效的方式以便互相進行監控，保護系統儘可能地避免遭受到重大故障的損失。
易管理性：不管是通過軟件還是硬件方式的均衡解決方案，我們都希望它有靈活、直觀和安全的管理方式，這樣便於安裝、配置、維護和
監控，提高工作效率，避免差錯。在硬件負載均衡設備上，目前主要有三種管理方式可供選擇：一、命令行接口（CLI：Command Line
Interface），可通過超級終端連接負載均衡設備串行接口來管理，也能telnet遠程登錄管理，在初始化配置時，往往要用到前者；二、圖形用戶接
口（GUI：Graphical User Interfaces），有基於普通web頁的管理，也有通過Java Applet
進行安全管理，一般都需要管理端安裝有某個版本的瀏覽器；三、SNMP（Simple Network Management
Protocol，簡單網絡管理協議）支持，通過第三方網絡管理軟件對符合SNMP標準的設備進行管理。
負載均衡配置實例
DNS負載均衡
DNS負載均衡技術是在DNS服務器中爲同一個主機名配置多個IP地址，在應答DNS查詢時，DNS服務器對每個查詢將以DNS文件中主機記錄的IP地
址按順序返回不同的解析結果，將客戶端的訪問引導到不同的機器上去，使得不同的客戶端訪問不同的服務器，從而達到負載均衡的目的。
DNS負載均衡的優點是經濟簡單易行，並且服務器可以位於internet上任意的位置。但它也存在不少缺點：
爲了使本DNS服務器和其他DNS服務器及時交互，保證DNS數據及時更新，使地址能隨機分配，一般都要將DNS的刷新時間設置的較小，但太小將會使DNS流量大增造成額外的網絡問題。
一旦某個服務器出現故障，即使及時修改了DNS設置，還是要等待足夠的時間（刷新時間）才能發揮作用，在此期間，保存了故障服務器地址的客戶計算機將不能正常訪問服務器。
DNS負載均衡採用的是簡單的輪循負載算法，不能區分服務器的差異，不能反映服務器的當前運行狀態，不能做到爲性能較好的服務器多分配請求，甚至會出現客戶請求集中在某一臺服務器上的情況。
要給每臺服務器分配一個internet上的IP地址，這勢必會佔用過多的IP地址。
判斷一個站點是否採用了DNS負載均衡的最簡單方式就是連續的ping這個域名，如果多次解析返回的IP地址不相同的話，那麼這個站點就很可能採用的就
是較爲普遍的DNS負載均衡。但也不一定，因爲如果採用的是DNS響應均衡，多次解析返回的IP地址也可能會不相同。不妨試試Ping一下
www.yesky.com，www.sohu.com，www.yahoo.com
現假設有三臺服務器來應對www.test.com的請求。在採用BIND 8.x DNS服務器的unix系統上實現起來比較簡單，只需在該域的數據記錄中添加類似下面的結果：
www1 IN A 192.1.1.1
www2 IN A 192.1.1.2
www3 IN A 192.1.1.3
www IN CNAME www1
www IN CNAME www2
www IN CNAME www3
在NT下的實現也很簡單，下面詳細介紹在win2000 server下實現DNS負載均衡的過程，NT4.0類似：
打開“管理工具”下的“DNS”，進入DNS服務配置控制檯。
打 開相應DNS
服務器的“屬性”，在“高級”選項卡的“服務器選項”中，選中“啓用循環”複選框。此步相當於在註冊表記錄HKEY_LOCAL_MACHINE/
SYSTEM/CurrentControlSet/Services/DNS/Parameters中添加一個雙字節制值（dword值）
RoundRobin，值爲1。
打開正向搜索區域的相應區域（如test.com），新建主機添加主機 (A) 資源記錄，記錄如下：
www IN A 192.1.1.1
www IN A 192.1.1.2
www IN A 192.1.1.3
在這裏可以看到的區別是在NT下一個主機名對應多個IP地址記錄，但在unix下，是先添加多個不同的主機名分別對應個自的IP地址，然後再把這些主機賦同一個別名（CNAME）來實現的。
在此需要注意的是，NT下本地子網優先級會取代多宿主名稱的循環複用，所以在測試時，如果做測試用的客戶機IP地址與主機資源記錄的IP在同一有類掩碼範圍內，就需要清除在“高級”選項卡“服務器選項”中的“啓用netmask排序”。
NAT負載均衡
NAT（Network Address Translation
網絡地址轉換）簡單地說就是將一個IP地址轉換爲另一個IP地址，一般用於未經註冊的內部地址與合法的、已獲註冊的Internet
IP地址間進行轉換。適用於解決Internet
IP地址緊張、不想讓網絡外部知道內部網絡結構等的場合下。每次NAT轉換勢必會增加NAT設備的開銷，但這種額外的開銷對於大多數網絡來說都是微不足道
的，除非在高帶寬有大量NAT請求的網絡上。
NAT負載均衡將一個外部IP地址映射爲多個內部IP地址，對每次連接請求動態地轉換爲一個內部服務器的地址，將外部連接請求引到轉換得到地址的那個服務器上，從而達到負載均衡的目的。
NAT負載均衡是一種比較完善的負載均衡技術，起着NAT負載均衡功能的設備一般處於內部服務器到外部網間的網關位置，如路由器、防火牆、四層交換機、專用負載均衡器等，均衡算法也較靈活，如隨機選擇、最少連接數及響應時間等來分配負載。
NAT負載均衡可以通過軟硬件方式來實現。通過軟件方式來實現NAT負載均衡的設備往往受到帶寬及系統本身處理能力的限制，由於NAT比較接近網絡的低
層，因此就可以將它集成在硬件設備中，通常這樣的硬件設備是第四層交換機和專用負載均衡器，第四層交換機的一項重要功能就是NAT負載均衡。
下面以實例介紹一下Cisco路由器NAT負載均衡的配置：
現有一臺有一個串行接口和一個Ethernet接口的路由器，Ethernet口連接到內部網絡，內部網絡上有三臺web服務器，但都只是低端配置，爲
了處理好來自Internet上大量的web連接請求，因此需要在此路由器上做NAT負載均衡配置，把發送到web服務器合法Internet
IP地址的報文轉換成這三臺服務器的內部本地地址。 其具體配置過程如下：
做好路由器的基本配置，並定義各個接口在做NAT時是內部還是外部接口。
然後定義一個標準訪問列表（standard access list），用來標識要轉換的合法IP地址。
再定義NAT地址池來標識內部web服務器的本地地址，注意要用到關鍵字rotary，表明我們要使用輪循（Round Robin）的方式從NAT地址池中取出相應IP地址來轉換合法IP報文。
最後，把目標地址爲訪問表中IP的報文轉換成地址池中定義的IP地址。
相應配置文件如下：
interface Ethernet0/0
ip address 192.168.1.4 255.255.255.248
ip nat inside
!
interface Serial0/0
ip address 200.200.1.1 255.255.255.248
ip nat outside
!
ip access-list 1 permit 200.200.1.2
!
ip nat pool websrv 192.168.1.1 192.168.1.3 netmask 255.255.255.248 type rotary
ip nat inside destination list 1 pool websrv 
反向代理負載均衡
普通代理方式是代理內部網絡用戶訪問internet上服務器的連接請求，客戶端必須指定代理服務器,並將本來要直接發送到internet上服務器的連接請求發送給代理服務器處理。
反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的連接請求，然後將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現爲一個服務器。
反向代理負載均衡技術是把將來自internet上的連接請求以反向代理的方式動態地轉發給內部網絡上的多臺服務器進行處理，從而達到負載均衡的目的。
反向代理負載均衡能以軟件方式來實現，如apache mod_proxy、netscape
proxy等，也可以在高速緩存器、負載均衡器等硬件設備上實現。
反向代理負載均衡可以將優化的負載均衡策略和代理服務器的高速緩存技術結合在一起，提升靜態網頁的訪問速度，提供有益的性能；由於網絡外部用戶不能直接訪
問真實的服務器，具備額外的安全性（同理，NAT負載均衡技術也有此優點）。
其缺點主要表現在以下兩個方面：
反向代理是處於OSI參考模型第七層應用的，所以就必須爲每一種應用服務專門開發一個反向代理服務器，這樣就限制了反向代理負載均衡技術的應用範圍，現在一般都用於對web服務器的負載均衡。
針對每一次代理，代理服務器就必須打開兩個連接，一個對外，一個對內，因此在併發連接請求數量非常大的時候，代理服務器的負載也就非常大了，在最後代理服務器本身會成爲服務的瓶頸。
一般來講，可以用它來對連接數量不是特別大，但每次連接都需要消耗大量處理資源的站點進行負載均衡，如search。
下面以在apache
mod_proxy下做的反向代理負載均衡爲配置實例：在站點www.test.com，我們按提供的內容進行分類，不同的服務器用於提供不同的內容服
務，將對http://www.test.com/news的訪問轉到IP地址爲192.168.1.1的內部服務器上處理，對http:
//www.test.com/it的訪問轉到服務器192.168.1.2上，對http://www.test.com/life的訪問轉到服務器
192.168.1.3上，對http://www.test.com/love的訪問轉到合作站點http://www.love.com上，從而減輕
本apache服務器的負擔，達到負載均衡的目的。
首先要確定域名www.test.com在DNS上的記錄對應apache服務器接口上具有internet合法註冊的IP地址，這樣才能使internet上對www.test.com的所有連接請求發送給本臺apache服務器。
在本臺服務器的apache配置文件httpd.conf中添加如下設置：
proxypass /news http://192.168.1.1
proxypass /it http://192.168.1.2
proxypass /life http://192.168.1.3
proxypass /love http://www.love.com
注意，此項設置最好添加在httpd.conf文件“Section 2”以後的位置，服務器192.168.1.1-3也應是具有相應功能的www服務器，在重啓服務時，最好用apachectl configtest命令檢查一下配置是否有誤.
混合型負載均衡
在有些大型網絡，由於多個服務器羣內硬件設備、各自的規模、提供的服務等的差異，我們可以考慮給每個服務器羣採用最合適的負載均衡方式，然後又在這多個
服務器羣間再一次負載均衡或羣集起來以一個整體向外界提供服務（即把這多個服務器羣當做一個新的服務器羣），從而達到最佳的性能。我們將這種方式稱之爲混
合型負載均衡。此種方式有時也用於單臺均衡設備的性能不能滿足大量連接請求的情況下。
下圖展示了一個應用示例，三個服務器羣針對各自的特點，分別採用了不同的負載均衡方式。當客戶端發出域名解析請求時，DNS服務器依次把它解析成三個服務器羣的VIP，如此把客戶端的連接請求分別引向三個服務器羣，從而達到了再一次負載均衡的目的。
在圖中大家可能注意到，負載均衡設備在網絡拓樸上，可以處於外部網和內部網絡間網關的位置，也可以和內部服務器羣處於並行的位置，甚至可以處於內部網絡或internet上的任意位置，特別是在採用羣集負載均衡時，根本就沒有單獨的負載均衡設備。
服務器羣內各服務器只有提供相同內容的服務纔有負載均衡的意義，特別是在DNS負載均衡時。要不然，這樣會造成大量連接請求的丟失或由於多次返回內容的不同給客戶造成混亂。
所以，如圖的這個示例在實際中可能沒有多大的意義，因爲如此大的服務內容相同但各服務器羣存在大量差異的網站並不多見。 但做爲一個示例，相信還是很有參考意義的.
具體是這樣的：
一般情況的LB是，一臺APP應用宕機或故障，均衡器會自動將請求轉發到其他服務器處理！這樣能最大程度保證應用穩定！
但是，我的想法是，如果前端均衡負載服務器自己宕機了，怎麼辦？
是不是該在那臺服務器上設置一個每隔多少秒查看均衡器負載情況的小程序！
如果有問題，直接將DNS轉到備份均衡負載服務器上？類似心跳檢測！
另外，一般均衡負載都有設置最大承載量，這個量到上限了怎麼辦？！
還有均衡負載羣集，感覺怎麼樣？
不知道大家有更好的辦法沒 ？