當Web服務器的用戶數量比較多時，通過Web服務器負載均衡來提高用戶的訪問性能，是一個比較常用的手段。如下圖所示?？梢栽谄髽I中同時設置兩臺或者兩臺以上的Web服務器，從而實現在服務期之間負載均衡。如此的話，當有一個用戶訪問某個網頁時，系統會自動挑選一臺比較空閑的服務器來應對用戶的請求?，F在主要的關鍵點是，由誰來確定，這個訪問者應該連接到哪一臺服務器呢？給用戶選擇恰當的服務器，不僅可以提高用戶的訪問性能，而且還可以提高數據的安全性。

        一、可以借助Forefront來充當裁判的角色

        在搭建服務器負載均衡環境時，很重要的一個問題就是如何來確定哪一臺服務器比較空間，或者說用戶該連接在那一臺服務器上？雖然現在不少的服務器軟件都帶有這個功能，但是如果采用Forefront安全網關產品的話，還能夠帶來一些額外的安全收益。

        如現在以上兩臺Web服務器，雖然是為了實現負載均衡來設置的。但是兩臺服務器有主次之別。如Web服務器1是主服務器，用戶不僅可以在這臺服務器上進行查詢，而且還可以更新相關的數據。而對于Web服務器來說，其是輔助查詢，一般用戶只能夠查詢，而不能夠更新。此時為了安全起見，顯然會對訪問Web服務器1的用戶進行限制。如企業內部的用戶，只能夠訪問Web服務器1。而對于外部用戶，優先訪問的是Web服務器2。當Web服務器2比較繁忙時，才允許外部用戶訪問Web服務器1。此時顯然不是簡單的Web服務器負載均衡可以實現的。要完成這個需求的話，必須要借助Forefront的幫助。從而在性能與安全之間達到一個均衡。

        如上圖所示，在Forefront安全網關的幫助下，管理員在發布執行相同角色的Web服務器時(即服務器負載均衡)，可以控制各個服務器之間的復雜均衡(即可以是完全的負載均衡，也可以是有條件的負載均衡)，從而實現入站訪問的高可用性，并提高Web服務器的安全與性能。

        二、Forefront服務器負載均衡的主要實現方式

        Forefront能夠確保負載均衡在無需中斷當前端點連接的情況下在可用Web服務器之間平均分布請求。這是微軟官方文檔上的一句原話。其實將這句話進行分解，可以找到兩個關鍵點。一是在不用斷開當前連接的情況下實現Web服務器之間的轉換。二是Web服務器之間平均分布請求這是一個相對的概念。換句話說，不可能是多臺服務器的負荷量是相等的。而是可以根據一定的規則進行調整。另外Forefront還可以檢測脫機的服務器，并實現故障轉移等相關的工作。在這里筆者結合自己的工作靜態，談談其服務器負載均衡的主要實現方式。筆者認為，在了解這些主要實現方式的時候，各位讀者主要關注其相同點與差異。因為在各位讀者自己配制時，需要根據企業的實際情況來選擇合適自己的實現方式?？偟膩碚f，Forefront的Web服務器發布負載均衡的配置難度并不大。其主要的難點還在于選擇合適企業的實現方式。

        在Forefront安全網關中，關于Web負載均衡主要有三種實現方式，分別為基于源IP的負載均衡、機遇Cookie的負載均衡和循環機制。在后續的內容中，筆者會對這三種方式進行分析，并舉例說明其主要的適用場合。希望這些內容能夠對各位選擇合適的實現方式有所幫助。

        第一種方式是基于IP的負載平衡或者IP關聯。簡單的說，這就是將客戶端的IP地址與服務器相關聯。如筆者在文章一開始就提到了一個案例。雖然兩個服務器之間的內容是相同的，但是在權限上可能有所差別。此時可以將某些特定的客戶端IP地址進行指定，其可以優先訪問哪一臺服務器，或者只允許訪問哪一臺服務器。這種方式往往有安全方面的考慮。不過需要注意的是，這種方式并不支持所有的服務器負載均衡。如根據筆者的了解，outlook客戶端就不支持這種方式。為此如果需要采用這種負載均衡的實現手段，管理員一定要事先確認，所采取的應用能夠支持這種方式。

        第二種方式是基于Cookie的負載平衡或這關聯。簡單的說，這就是指用戶會話語服務器進行關聯。這種方式有一個特點，即當重新啟動Web服務器時，會話關聯仍然可以提供可靠的關聯?；蛘哒f，Forefront 安全網關可以確保用戶在一次路由到特定應用服務器后繼續使用這個服務器。舉一個簡單的例子。如上圖所示，現在某個用戶已經連接到了Web服務器A。此時由于某種特殊情況，管理員將Web服務器A重新啟動了。在重新啟動后，會話關聯仍然可以提供可靠的關聯。為此在一些特定的應用中，往往建立采用會話關聯。如某些應用程序，特別強調會話的重要性。如淘寶網站。在淘寶網中有購物車的概念。此時即使用戶在不同的網頁之間進行切換，但是購物車中的內容能夠保證是自己剛才采購的。這主要就是會話在其中起作用。對于類似的應用，就需要采用這種機遇Cookie的負載平衡或者關聯。

        第三種方式是循環機制。這個機制主要是在Web服務器成員之間平均分布來自不同的IP地址的請求。循環機制的主要特點，是能夠確保在聯機服務器之間平均分布針對由Web應用程序的用戶請求。而且這種分布機制在故障轉移期間也能夠保持。而且當發生故障轉移時，系統能夠檢測沒有響應的服務器，并在可用服務器之間進行分布均衡。簡單的說，循環機制其會循環的檢查服務器的可用性。當發現用戶連接的某臺服務器不可用或者非常繁忙時，會馬上中斷用戶的連接，并將其連接到可用的服務器上。而不管用戶當前的會話狀態如何。這種方式有缺陷也有優點。缺陷是用戶當前會話的相關信息(如果沒有保存)則可能會丟失。因為此時相關信息還是保存在內存中。當會話強制關閉時，相關信息就會遺失。而優點是能夠提供更高的性能。如現在某個用戶在訪問某個網頁，其是連接在Web服務器1訪問的。當其轉向到另外一個網頁時，此時這個網頁的訪問量非常的大，基本上都集中在服務器1。而這個網頁的Web服務器2訪問量則比較小。在這種情況下，如果采用循環機制的話，會將這個客戶的請求重新定位到服務器2。目的就是為了給這個用戶提供更好的性能。可是問題是，現在換了一個服務器，就相當于新建了一個會話 ，原先的會話也就中斷了。其實這種情況在實際工作中也比較多建。如我們打1000號的時候，剛開始可能連接的是湖南長沙的站點(可能這個站點比較空)。然后再交接線員轉接到1000號的其他部門，此時這個1000號站點可能就不是長沙了(當轉接的目標部門比較忙時就會自動轉接到其它部門)。此時由于相關信息比較獨立，即使當前會話中斷了，丟失相關信息影響也不是很大。或者說，相對于漫長的等待時間來說，這個當前會話信息的丟失所造成的影響可以忽略不計。

        可見不同的實現方式其目的雖然相同，但是在細節上仍然有很大的差異。這導致其應用場合也有所不同?？傊?，基于IP的負載平衡或者基于Cookies的負載均衡，其主要的特點是確保用戶在一次路由到特定應用服務器后(如Web服務器1)后續訪問繼續路由到這個服務器。而循環機制的話，則可能會因為特定資源訪問量的變化，在可用的Web服務器之間進行不停的轉換。抓住這兩個主要的差異點，然后結合企業的實際情況，來判斷到底該采用哪種實現方式。