ADC產品（應用交付控制器）主要實現負載均衡、應用和協議優化、安全防護等功能，其目的是實現服務器和應用系統的高可靠可用性。其中負載均衡功能是ADC的基本功能也是最重要的功能，但是基本不代表簡單，在實際使用中，我們總是會發現用了負載均衡設備，但負載均衡並不均衡的現象。
爲什麼負載會不均衡呢？請讓我們從技術角度來仔細探討，相信大家會有清晰的認識。
欲要實現服務器分配均衡，大家第一個想到的選項是什麼？很多人肯定回答是算法，沒錯，是負載分配的算法，但一臺負載均衡設備提供了很多的算法，具體算法應該如何選擇呢？
我的回答是具體需求具體考慮，我們來一一討論。
負載均衡的分配算法分爲靜態算法、動態算法以及根據具體需求特定分發三大類。
靜態算法包含論詢，比例（權重）等。
動態算法包含最小連接數，最快響應速度等
具體需求特定分發則包含各種各樣的情況，例如針對某些源IP，分發到指定的服務器，針對某些請求內容，分發到指定的服務器等。
配置過負載均衡設備的人最熟悉的算法應該是輪詢（Round Robin：對每個新建連接依次分發到服務組中的每臺服務器）。輪詢是靜態算法，也是大家配置設備時，往往會默認選擇的算法。輪詢的結果是每臺服務器上連接的總數是一致的，但服務器的硬件和軟件性能可能會不同，導致服務器當前處理能力差別很大，也就是服務器的負載差別很大，而隨着分發到服務器的用戶連接越來越多，導致某些性能差的服務器上當前處理的連接數越積越多，最終將導致該服務器崩潰，而其他服務器卻相對空閒，這顯然不是客戶想看到的。
這個時候有人會考慮選擇比例（Ratio）, 例如兩臺服務器一臺性能是另一臺的兩倍，那麼在分發的時候設定一個比例2:1，性能高的服務器分發到的連接數是性能低服務器的兩倍。但是比例算法仍然是一個靜態算法，比例的設定取決於人的經驗感知，不能代表設備的真正負載和性能，導致實際的運行結果仍然會有比較大的偏差，服務器負載仍然不均衡。
通過上面可以看出，靜態算法無法實時感知服務器的運行狀態，是一種比較死板的算法，無法動態調整。因此對於處理起來比較複雜的應用，最好是考慮動態的算法，例如最小連接數（Least Connection：ADC實時統計當前每臺服務器上的連接數，新的連接將傳遞給當前連接數最少的服務器），上面說過，輪詢是保證每臺服務器處理過的總連接數是均衡的，而最小連接數與輪詢恰好相反，最小連接數是保證每臺服務器當前正在處理的連接數是均衡的，這種動態算法反映了服務器的性能情況，例如服務器1當前正在處理的連接數爲50，服務器2爲49, 那麼下一個新建連接會發給服務器2，此時兩臺服務器都是50, 假設服務器1處理比較慢，服務器2處理比較快，那麼下一時刻可能服務器2的當前連接數又變得比服務器1少，結果新建連接會繼續發給服務器2。所以從總數上來看，服務器2處理過的連接數會遠遠高於服務器1，但正在處理的連接數總是均衡的。
還有一種動態算法是最快響應速度（Fastest Response : 新的連接傳遞給那些響應最快的服務器）。這種算法把新建連接總是發送給響應最快的服務器，它的表現是，各臺服務器上的總連接數和當前連接數從統計上都不一致，但是處理的連接數最多的那臺，肯定是性能最好的服務器。
通過以上的分析，通過配置最優的負載均衡算法看似能夠保證服務器的負載均衡，但實際上還不夠，現實中有很多情況會導致服務器的負載失衡。有以下幾種情況：
1）應用無需配會話保持的情況，ADC設備把連接均衡分發到服務器，但是某些連接訪問量比較大，有些連接訪問量比較小，導致的結果是服務器上連接數看似均衡，但服務器負載差別比較大。
解決辦法：基於請求來分發，用戶訪問的最小顆粒度是請求而不是連接（一個連接中可能有N個請求），如果基於請求來分發，自然可以更深一步來均衡服務器的負載。
2）應用需要配置會話保持的情況，很多應用都需要配置會話保持，假設配置的是源IP會話保持，那麼同一個源IP的所有連接都會保持在一臺服務器上，假設某些源IP訪問量特別大，某些源IP訪問量比較少，就會導致某些服務器負載比較高，某些又比較低？尤其是某些用戶的地址在出口是做了NAT的，ADC設備看到的源IP是這個NAT IP，但後面其實有很多個用戶在訪問，會導致服務器連接數不均衡，並且負載差別很大。
解決辦法：
a）採用基於Cookie的會話保持，Cookie會話保持主要用於HTTP協議的應用，使得每隔客戶端帶着相同Cookie的會話纔會分發並保持在一臺服務器上，它可以細分開同一源IP的多個連接，所以可以使得服務器的負載更均衡。
b）基於session-id的會話保持，有些客戶端不支持Cookie或者應用不支持Cookie或者使用Cookie會話保持後，服務器負載仍然不均衡，我們可以考慮採用腳本編程分析數據包的內容取得會話的session-id並以此做爲保持選項，這是一種比Cookie會話保持要求更高的保持策略，只有比較靈活的ADC設備才能實現。
c）基於用戶的某個關鍵字信息進行保持，例如手機的應用，用戶的數據包中會帶有手機號信息，通過編程分析數據包取得這個關鍵字信息進行分發和保持，將使得服務器的負載更均衡。
3）使用了各種方法負載都不均衡的情況，服務器的負載高低不僅僅跟CPU，內存的使用率高低有關係，同時也跟應用系統程序的實現細節息息相關。這裏有一個真實案例：客戶的應用部署多臺小型機，同時每臺小型機又劃分出多個虛擬機，每臺虛擬機都安裝了一個應用系統，通常負載均衡分發自然是針對這些虛擬機進行分發，但是每臺虛擬機的應用系統有一些資源使用的上限，例如每臺虛擬機最多可運行50個應用線程，結果在CPU，內存佔用並不高的情況下，線程用滿了，導致虛擬機無法繼續處理新的請求。
解決辦法：這種情況極其特殊，任何ADC設備都無法設計出標準感知應用程序是否可用的選項。但是，是否無法解決呢？還是有辦法的，一個人累不累自己最知道，應用系統自己是可以知道能否處理更多東西的，那麼辦法就是應用程序自己做一個監控，把監控的結果寫到一個文件中，ADC設備通過健康檢查的功能定時取這個文件判斷裏面的內容，如果內容指示爲不可用，那麼後續用戶的訪問將發送到其他的服務器，當檢查到該臺服務器又可用了，可以把新的用戶請求繼續發送到該臺服務器。這種方法同樣要求ADC設備能夠編程定製一個健康檢查，這也是對ADC設備的更高要求。
（wyl）.