基于開源平臺的高性能負載均衡集群架構實現

楊亞平

（酒泉鋼鐵<集團>有限責任公司 甘肅 嘉峪關 735100）

1 引言

某大型制造企業（以下簡稱“公司”）是國家“一五”時期規劃建設的鋼鐵聯合企業，經過數十年的建設發展，現已形成多個產業板塊協同發展的新格局。而隨著信息技術的迅速發展，企業信息化建設體系也相對成熟，由信息化所帶來的企業管理模式的變革與管理效率的提升也越來越依賴于信息系統。

2 高性能負載均衡集群架構實現必要性分析

2.1 平臺自身重要性

近年來，伴隨著企業級核心業務系統的日益完善和逐步深入，協同辦公系統作為公司日常辦公工作的統一入口，是各部門間協同工作的展示平臺，承擔著公司信息系統的最大用戶群體。它整合了企業內部信息資源，解決了企業信息孤島、業務深井等問題，提高了企業工作效率，因此協同辦公平臺在公司中的重要性日益凸顯出來。

2.2 架構對平臺穩定性的影響

早期協同辦公平臺建設初期，系統架構設計采用了業界比較成熟的負載均衡集群部署方案，架構圖見圖1，即在整個集群系統的最前端放置1臺nginx負載均衡服務器，它的主要作用是將用戶端提交的請求根據設定好的算法逐個分發到應用節點上進行處理。后端部署3臺相同環境的應用服務器，用于響應由nginx分發過來的用戶請求。這種設計思路相比最早的單節點方式在架構穩定性方面有了明顯的提升，在一定程度上也考慮到了影響系統訪問速度和穩定性的制約因素并進行了改進。

圖1 早期協同辦公平臺設計架構

不過，在平臺實際搭建過程中，硬件服務器緊缺帶來的阻礙還是未能避免。一方面，項目建設有嚴格的工期要求，絕對不能影響項目的正常推進；另一方面，還必須得保證集群架構的搭建，需要考慮如何才能兼顧好這兩方面。

通過對以上兩方面的綜合考量，將方案在原設計基礎上進行了調整，采用了在最大可能滿足硬件資源的情況下對集群環境進行壓縮的臨時性過渡方案。具體是將原設計中的nginx與應用節點1先暫時安裝部署在同一臺服務器上，這樣可以先進行其他部署和調試工作，盡量對進度不產生影響。待系統具備正式上線條件后，再將nginx負載均衡遷移分離出來單獨運行。但是直到系統正式上線，硬件服務器短缺的問題也沒有得到解決，因此nginx負載均衡遷移工作始終未能成行。后期當硬件服務器資源能正常提供時，又因為其他原因導致這個歷史遺留問題被擱置起來，這種系統架構也就一直沿用下來了，見圖2。

圖2 早期協同辦公平臺建設架構

在平臺實際運行的過程中，經常暴露出對用戶的請求響應不及時和應用節點1這臺服務器運行不穩定的問題[1]。

2.3 算法對平臺可用性的影響

傳統架構下的協同辦公平臺，用戶訪問時首先經過負載均衡服務器的nginx，nginx再根據配置的算法將請求轉發到后端的應用節點上，而nginx采用了ip_hash算法來實現負載均衡，這種算法是基于IP地址來判斷請求客戶端，缺點是來自同一客戶端的請求被固定到同一臺服務器，會導致負載不均衡，影響系統正常訪問。

綜上分析，出于對協同辦公平臺重要性和穩定性的考慮，公司決定對平臺整體進行升級改造。通過優化升級搭建高性能負載均衡集群，使協同辦公平臺存在的問題能得以改善和解決。

3 高性能負載均衡集群架構實現原理

由圖2可知，早期集群架構下的協同辦公平臺最大的不穩定因素源于最前端nginx負載均衡服務器，一旦這臺服務器宕機或故障，不論后端應用節點是否正常，整個集群將陷入癱瘓[2]，直接影響用戶訪問協同辦公平臺。另外，應用節點1與nginx負載均衡共享同一臺服務器資源，兩者之間互相干擾和影響，常常導致服務器負載居高不下。那么如何解決負載均衡分發器單點故障的風險和彌補架構的缺陷呢？因此，升級優化工作就從以下幾方面著手開展。

3.1 負載均衡集群架構優化

為了應對日益增長的訪問量，首先將原架構中應用節點1與nginx節點拆分后單獨部署，這樣就避免了兩者之間的干擾影響和資源爭用。其次將后端應用節點數量由原先的3臺擴展至6臺，繼續由nginx統一來調度分發請求，實現多個后端應用節點共同分擔和緩解高并發訪問請求的問題，減輕了整個平臺的負擔，保證了業務的連續性。

3.2 高可用架構配置實現

在集群的最前端新增加一臺負載均衡服務器，與原有nginx負載均衡服務器形成高可用主備模式。正常情況下客戶端均通過vip地址訪問，一旦master服務器出現故障，backup服務器就會自動接管IP和服務資源繼續進行請求分發工作，直到主服務器故障修復[3]。優化升級后的協同辦公平臺架構圖見圖3。

圖3 優化后的高可用負載均衡架構

那么，集群是如何判斷master服務器掛掉了呢？這就需要用到開源軟件keepalived來監測nginx服務器的狀態。

在集群最前端的兩臺nginx服務器上分別安裝keepalived軟件，keepalived會定期向集群中服務器發送icmp包，一旦master服務器宕機或出現故障，keepalived監測到后立即使用backup服務器代替master服務器的工作，并將master nginx服務器從集群中剔除[4]。當master服務器正常后keepalived會自動將服務器加入集群中，而剔除和加入集群的動作完全不需要人工進行干預，因此利用keepalived監測nginx狀態就解決了分發服務器單點故障的風險。

3.3 負載均衡算法優化

編譯安裝nginx啟用擴展功能模塊nginx-stickymodule，可以修復nginx ip_hash算法帶來的負載失衡的問題。與ip_hash不同之處在于，sticky功能是基于cookie來判斷客戶端，實現了同一個客戶端請求在同一臺服務器上的負載均衡作用，同時也避免了來自同一局域網的客戶端導致負載失衡和session丟失的情況，見圖4。

圖4 nginx sticky配置

4 結語

本文通過對早期企業協同辦公平臺運行過程中存在的問題進行剖析，針對協同辦公平臺整體架構的缺陷進行優化改造，主要改善了平臺在高并發時段響應緩慢的問題，解決了平臺的性能瓶頸，提升了平臺運行處理能力，同時也降低了系統運維風險，實現了向用戶提供不間斷信息化服務，從而更好地為企業信息化服務的目標。

基于開源平臺高性能負載均衡集群架構的實現，是公司首次在開源技術領域的探索與理論實踐，開闊了技術人員的視野，為公司其他開源信息系統的優化改造積累了豐富的經驗，同時也將公司信息化水平推向了新的高度[5]。

另外，本次主要針對面向平臺的負載均衡層和應用層進行了優化，后端數據層仍存在繼續改造提升的空間，后續可以根據協同辦公平臺運行情況，結合數據庫技術，以搭建數據庫集群為研究方向，進一步提高系統訪問速度。