消息計費在線接入平臺負載均衡項目的解決方案研究

方 軍 丘 華

（中國聯合網絡通信有限公司廣東省分公司，廣東 廣州 510000）

1 引言

由于總部消息計費總體技術架構分為總部和省分兩級，均為統一版本，總部部分在總部統一部署，省分部分在各分省部署。其中消息會話管理子系統主要涉及總部、省分部署。省分部署的消息控制節點為多套獨立的節點，需要前端增加負載均衡的能力。實現計費消息負載均衡，能根據業務要求進行業務級的路由，實時進行在線和離線的切換，同時做到消息級的負載均衡，支撐后端服務分布式集群部署。

2 實施目標

（1）新增會話級負載均衡網元CCR消息到省分消息計費消息控制節點主機；

（2）省分部署的消息控制節點集群單節點故障時，故障節點會話記錄快速均衡到集群；

（3）支持動態添加省分消息計費的消息控制節點；

（4）實現本省在線接入鏈接消息計費系統，產生負載均衡路由調整/變化時保證DCC消息不丟失。

3 技術方案

3.1 實現負載均衡

核心思想：根據處理的業務量進行負載均衡，業務量以計費請求消息數與計費應答消息數之差作為衡量(優先實現這種策略)。啟用計數器登記計費請求消息數與計費應答消息數之差，每發送一個計費請求，計數器遞增一；反之每收到一個計費應答，計數器遞減一。業務流程如圖1所示。

圖1 業務流程圖

算法實現：負載均衡模塊對每個計費請求消息進行負載均衡選擇消息計費節點的時候，先判斷是否能直接路由，如相同會話相同號碼發往同一個節點，不能對所有消息計費節點的計數器排序選擇最小的發送。特別地，如果有新節點添加進來，這個算法也不需要重置計數器；采用計費請求消息數與計費應答消息數之差作為計數器的值，可能由于業務量少或者某個主機處理能力比較快而相對比較集中地把計費請求發送到一個主機節點上，為了避免這種情況，在負載均衡模塊實現的時候，當存在多個計數器都是最小值的時候，通過隨機函數計算選擇某個節點。

負載均衡設備可以實現客戶端連接級和請求會話級的負載均衡，同時可以開啟DCC的會話保持功能，并根據實際生產情況，調試負載均衡的算法：

（1）輪詢；

（2）加權輪詢；

（3）響應時長加權。

在Diameter協議的負載均衡會根據負載均衡的計算方法，將省分接入節點分發到消息計費服務器上。負載均衡流程圖如圖2所示。

圖2 負載均衡流程圖

（1）Diameter握手進程，CER請求到負載均衡設備,負載均衡設備根據輪詢的算法消息計費Server 1，同時在CER/CEA中，在server的HOST ID可透傳給client，負載均衡設備也可以替換。

（2）第二個Diameter CCR請求發送到負載均衡設備，負載均衡設備解析Session-id=y，是一個新的請求，那么負載均衡設備會根據輪詢的算法，把請求送到Proxy Server 2。在這里負載均衡設備是把Diameter協議中的AVP作為Session-id的值作為與后臺服務器會話的標準。

（3）假設負載均衡設備收到第三個CCR請求，解析其Session-id=x,也是一個新的請求，那么根據負載均衡的算法，發到消息計費Server 1。

（4）收到第四個CCR請求，解析其AVPSession-id=y，那么根據AVP會話保持原則，負載到消息計費Server 2。

（5）收到第五個CCR請求，解析其AVPSession-id=x，那么根據AVP會話保持原則，負載到消息計費Server 1。

（6）收到第六個CCR請求，解析其AVPSession-id=y，那么根據AVP會話保持原則，負載到消息計費Server 2。

（7）由于Diameter協議是異步協議，所以來自Server的響應也是異步的。

（8）負載均衡設備不會透傳DWR/DWA，而由負載均衡設備分別回應。

（9）當網元發出DPR，負載均衡設備把請求廣播到所有消息計費Server服務器，如果只是消息計費Server端發起DPR請求，那么負載均衡設備只是響應這個Server服務器，不會影響其他的網元請求以及Server服務器。

3.2 實現系統自動應急響應

業務流程如圖3所示。

圖3 系統自動應急流程圖

（1）負載均衡模塊通過定期Health Check Request心跳健康檢查偵測后臺消息計費服務器是否正常；

（2）網元請求端正常發送DCC請求，負載均衡模塊按照輪詢的負載均衡方式分發到消息計費Server 1節點上處理；

（3）此時消息計費Server 1服務器節點失效；

（4）負載均衡設備定期Health Check心跳健康檢查偵測消息計費Server 1節點失效，將該信息反饋給云化管理平臺；

（5）云化管理平臺得知消息計費Server 1節點失效，準備啟用消息計費Server 2節點；

（6）云化管理平臺停止服務器消息計費Server 1節點，釋放相關資源，并將此節點從消息計費動態云化資源池中移除；

（7）云化管理平臺啟用服務器消息計費Server 2節點，并完成業務可用性驗證；

（8）同一個會話新接續DCC請求達到負載均衡設備，不會再分發到失效的消息計費Server 1節點，而是分發到Proxy動態云化資源池中有效的消息計費Server 2節點處理；新會話的DCC請求到達負載均衡設備，也分發到Proxy動態云化資源池有效的消息計費Server 2節點處理。

3.3 實現在線動態擴容

CMP要正確路由，首先要能識別每個鏈路是來自Proxy、FEP-CF、會話管理Session_Manager還是CMP管理客戶端。這個和CMP在與它們建立連接時，是客戶端還是服務端有關系。如果CMP是它們的客戶端，鏈路的建立是CMP的主動行為，對于CMP識別這個鏈路是不存在問題的；但如果CMP是服務端，這個鏈路就要識別。根據系統目前的業務情況，CMP要支持：

（1）DCC協議：數據業務、語音業務、增值會話業務、WLAN業務

（2）SMPP+協議：短信業務

（3）SGIP協議：增值事件業務

支持同種協議時，相關流程如圖4所示。

圖4 在線動態擴容流程圖

（1）網元請求端正常發送DCC請求，負載均衡設備按照輪詢的負載均衡方式分發到消息計費Server 1節點上處理；

（2）負載均衡設備定期反饋Proxy負載信息至云化管理平臺；

（3）云化管理平臺檢測Proxy負載是否超過設定閾值，如果超過閾值，則需要啟動新Proxy資源節點；

（4）云化管理平臺啟動新資源節點消息計費Server 3；

（5）云化管理平臺要求負載均衡設備驗證并反饋新節點消息計費Server 3的可用性；

（6）云化管理平臺根據反饋信息判斷新節點是否可用；如果可用，通知負載均衡設備將新節點消息計費Server 3加入到Proxy云化資源池中；

（7）新會話請求按負載均衡方式分發到原有效消息計費Server 2節點處理；

（8）另一個新會話請求按負載均衡方式分發到新啟用的消息計費Server 3節點處理。

3.4 在線版本升級過程實現

集群中的CF應用版本升級有幾種方式：

（1）Proxy全業務切離線，再升級應用版本（手工方式）；

（2）CMP支持設置節點升級模式（后續說明這個模式），手工逐一停節點，再升級應用，啟動應用（手工方式）；

（3）CMP自動升級方式。

進入節點升級模式時，CMP斷開該節點的連接，會把該節點的會話記錄設置為故障，需要同步到其它節點，CMP啟動一個新的后臺進程進行升級，當CMP完成升級，該節點以一個新節點添加的方式重新加入集群中。升級完成分單節點完成和整個集群完成。升級過程的狀態，比如升級完成了幾個節點，還有幾個節點的信息，CMP需要提供信息顯示。一個節點的應用在升級過程中大概需要耗時100ms，這跟不同的應用啟動時間有關。總之，能提供新節點的添加命令，就能通過手工逐一升級每個節點的應用。

升級說明：

（1）升級模式修改為離線控制模式，因為消息計費系統的升級時會造成CCA返回錯誤碼；

（2）保留升級模式的部分手工操作命令，并能配合Proxy進行離線容災機制的切換。

在線升級流程如圖5所示。

圖5 在線版本升級流程圖

（1）云化管理平臺啟動Proxy版本升級過程；

（2）云化管理平臺卸載部分在線資源節點到空閑資源池中；

（3）云化管理平臺向空閑資源池中可用的節點發送Proxy新版本升級指令；

（4）安裝新版本Proxy應用；

（5）啟用新版本Proxy應用；

（6）云化管理平臺要求負載均衡設備激活并反饋新版本節點的可用性；

（7）云化管理平臺要求負載均衡設備卸載舊版本Proxy節點；

（8）負載均衡設備發起并停止舊版本Proxy節點。

3.5 實現在線會話離線

系統由Proxy模塊向網元提供服務端口，同時具備對網元計費請求進行“在線”“離線”方式的切換。Proxy以SOCK客戶端的方式連接fep_ctrl模塊，在SOCK鏈路異常、無法通信的情況下，就會進行離線切換，連接到offline_cf模塊。實現從系統層面、業務層面、網絡物理層面綜合考慮，三者在滿足特定的條件都要進行離線切換：

（1）當Proxy與fep_ctrl之間的鏈路不可達，把消息計費該節點業務全部切到離線；

（2）當消息計費系統處理業務出現故障時把當前會話切換到離線。

4 方案創新和先進

本項目通過實現計費消息負載均衡，能根據業務要求進行業務級的路由，實時進行在線和離線的切換，同時做到消息級的負載均衡，支撐后端服務分布式集群部署。

（1）負載均衡：Proxy和負載均衡設備接合，實現消息負載均衡的功能，能把CCR消息均衡等發送到后端的多個節點，減輕某個節點因業務量過大支撐不住的情況。

（2）實時容災：當后端集群中某個節點出現問題時，Proxy能及時對該節點進行遷離線，不影響用戶使用感知，當后端節點恢復正常后能實時遷回在線。

（3）高效運維：支持通過直觀的Web界面進行系統監控和管理，能及時監控業務量，并根據業務相求進行業務類型路由，能及時監控返回碼來確定業務是否正常。

作為消息計費省分控制節點的前置分發服務節點，通過負載均衡技術應用，提供快速的自動擴容改造、故障節點會話均衡管理、節點動態擴縮、在線版本升級等服務，每套計費負載均衡產品滿足：CCR消息平均時延小于50ms，同時并發4萬每秒CCR，計費負載均衡設備按主備部署容災。

在業務正常(每百萬有效用戶全部業務1000caps)情況下，系統消息處理響應時間達到如下響應性能要求（70%的負荷）：

（1）95%消息量響應時長小于20ms；

（2）98%消息量響應時長小于30ms；

（3）99.9%消息量響應時長小于45ms；

（4）99.999%消息量響應時長小于100ms。

有效保障業務不間斷無縫接駁計費，至今系統保證100%無故障運營，系統自修復率為100%，效果顯著。