每當大型企事業(yè)單位的網(wǎng)絡系統(tǒng)業(yè)務發(fā)生諸如流量堵塞、效率緩慢、運行不暢等癥狀時，IT經(jīng)理們首先都會想到是否要再上一套負載均衡設備。誠然，作為網(wǎng)絡優(yōu)化的一件重大設備，負載均衡的確有很多突出的特性，但是否上了負載均衡業(yè)務就能高枕無憂了呢？

　　答案是：未必！

　　國內(nèi)知名應用交付廠商太一星晨的一位資深技術(shù)哥，在經(jīng)歷大量項目實踐后，對于負載均衡總結(jié)出來一套“心經(jīng)”。他指出，因為負載均衡和業(yè)務之間的調(diào)整息息相關(guān)，如果調(diào)整不好，有時上了負載的業(yè)務，反而會讓效率降低，甚至比原來更慢。

　　接下來，不妨以對業(yè)務要求最高的金融聯(lián)機交易系統(tǒng)為例，來看看上負載均衡的時候，問題都發(fā)生在哪些方面。

　　狀況一：同一服務端口開啟多個通信方式

　　金融聯(lián)機交易系統(tǒng)選擇應用交付多數(shù)是為了利用負載實現(xiàn)業(yè)務的高性能擴展和高可用。例如：

　　為了上負載，太一星晨技術(shù)哥建議將應用設備服務器設置為兩臺，端口分別為：10.112.57.21:8001、10.112.57.22:8001，兩臺服務器上都實現(xiàn)了兩種通信方式HTTP、JMS。

　　該業(yè)務模式如下：

　　HTTP連接采用短連接方式進行通信，每次請求都會重新建立連接；

　　JMS連接采用長連接進行通信，只建立一次連接。而且對該系統(tǒng)發(fā)送請求的客戶端是比較固定的，多為部署在分行的前置服務器，每個分行部署1-2臺。

　　部署完畢后，貌似完美！但好日子還沒過幾天廠商的電話就來了：負載均衡根本沒起作用！

　　通過對兩臺服務器系統(tǒng)資源的監(jiān)控，技術(shù)哥迅速發(fā)現(xiàn)是因為兩臺服務器明顯負載不均衡，所以才沒達到預期效果。

　　追本溯源，原來在做系統(tǒng)設計時，為了讓服務操作更簡單，就將對外服務端口統(tǒng)一為一個端口—這樣的方式對于關(guān)聯(lián)系統(tǒng)來說，是非常方便調(diào)用的設計。但也正因為如此，上了負載以后，負載根據(jù)端口平均分配任務—實際上兩種業(yè)務的類型是不一樣的：一種連接數(shù)很少，一種連接數(shù)很多。如此這般，經(jīng)過負載的分配，自然就導致了業(yè)務分配不均勻，從而造成了單臺服務器壓力過大。

　　經(jīng)過冷靜分析，技術(shù)哥嘗試了將JMS協(xié)議調(diào)整為HTTP協(xié)議，以及將JMS協(xié)議部署到一個新的端口，發(fā)現(xiàn)都能達到負載均衡的效果。最后選用了將協(xié)議統(tǒng)一調(diào)整為HTTP協(xié)議的方式，業(yè)務的效率“噌噌”地又上去了！

　　狀況二：壓力過大

　　有一次，太一星晨技術(shù)哥為某金融機構(gòu)部署負載均衡。在沒部署之前，調(diào)試沒有任何問題，也通過了壓力測試，而且能達到3000/秒的用戶數(shù)。但是就在技術(shù)哥上了負載產(chǎn)品后，一開始還能達到4000/秒左右，轉(zhuǎn)眼卻如洪水傾瀉，用戶數(shù)急速降低，甚至還不如沒上負載前。

　　“本來我們網(wǎng)絡沒有這么慢，現(xiàn)在加了負載均衡卻變慢了，是不是你們負載產(chǎn)品有問題??？”用戶提出了尖銳的質(zhì)疑。

　　經(jīng)過仔細觀察發(fā)現(xiàn)：壓力下，負載工作很正常，CPU也很低。但沒上負載前，后臺數(shù)據(jù)庫的CPU工作在85%左右，加了負載均衡之后，數(shù)據(jù)庫反而瞬間達到了百分之九十多，然后就居高不下了……

　　問題原因究竟在哪兒？

　　細究之下發(fā)現(xiàn)，原來這個機構(gòu)的數(shù)據(jù)庫平臺在設計之初，沒有考慮到以后需要在負載的情況下應用，現(xiàn)在經(jīng)過負載，給數(shù)據(jù)庫的壓力增加了，數(shù)據(jù)庫中某個表查詢過慢，反而導致了整個數(shù)據(jù)庫查詢效率降低，進而影響了整個系統(tǒng)。

　　所以，綜上案例可以發(fā)現(xiàn)，負載設備和客戶的應用業(yè)務是息息相關(guān)的，要想成功的部署負載均衡，并使其發(fā)揮預期的效果，除了要了解客戶需求，更要應地制宜，知己知彼才能讓負載均衡產(chǎn)品發(fā)揮出它該有的作用。