應用交付技術哥講述負載均衡血淚史！

2024-04-03 20:39:07

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

    答案是：未必！

    國內知名應用交付廠商太一星晨的一位資深技術哥，在經歷大量項目實踐後，對於負載均衡總結出來一套「心經」。他指出，因為負載均衡和業務之間的調整息息相關，如果調整不好，有時上了負載的業務，反而會讓效率降低，甚至比原來更慢。

    接下來，不妨以對業務要求最高的金融聯機交易系統為例，來看看上負載均衡的時候，問題都發生在哪些方面。

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

    金融聯機交易系統選擇應用交付多數是為了利用負載實現業務的高性能擴展和高可用。例如：

     為了上負載，太一星晨技術哥建議將應用設備伺服器設置為兩臺，埠分別為：10.112.57.21:8001、10.112.57.22:8001，兩臺伺服器上都實現了兩種通信方式HTTP、JMS。
該業務模式如下：

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

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

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

     通過對兩臺伺服器系統資源的監控，技術哥迅速發現是因為兩臺伺服器明顯負載不均衡，所以才沒達到預期效果。

    追本溯源，原來在做系統設計時，為了讓服務操作更簡單，就將對外服務埠統一為一個埠——這樣的方式對於關聯繫統來說，是非常方便調用的設計。但也正因為如此，上了負載以後，負載根據埠平均分配任務——實際上兩種業務的類型是不一樣的：一種連接數很少，一種連接數很多。如此這般，經過負載的分配，自然就導致了業務分配不均勻，從而造成了單臺伺服器壓力過大。

    經過冷靜分析，技術哥嘗試了將JMS協議調整為HTTP協議，以及將JMS協議部署到一個新的埠，發現都能達到負載均衡的效果。最後選用了將協議統一調整為HTTP協議的方式，業務的效率「噌噌」地又上去了！

狀況二：壓力過大

    有一次，太一星晨技術哥為某金融機構部署負載均衡。在沒部署之前，調試沒有任何問題，也通過了壓力測試，而且能達到3000/秒的用戶數。但是就在技術哥上了負載產品後，一開始還能達到4000/秒左右，轉眼卻如洪水傾瀉，用戶數急速降低，甚至還不如沒上負載前。
「本來我們網絡沒有這麼慢，現在加了負載均衡卻變慢了，是不是你們負載產品有問題啊？」用戶提出了尖銳的質疑。

    經過仔細觀察發現：壓力下，負載工作很正常，CPU也很低。但沒上負載前，後臺資料庫的CPU工作在85%左右，加了負載均衡之後，資料庫反而瞬間達到了百分之九十多，然後就居高不下了……

    問題原因究竟在哪兒？

    細究之下發現，原來這個機構的資料庫平臺在設計之初，沒有考慮到以後需要在負載的情況下應用，現在經過負載，給資料庫的壓力增加了，資料庫中某個表查詢過慢，反而導致了整個資料庫查詢效率降低，進而影響了整個系統。

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