消息計(jì)費(fèi)在線接入平臺(tái)負(fù)載均衡項(xiàng)目的解決方案研究

方 軍 丘 華

（中國聯(lián)合網(wǎng)絡(luò)通信有限公司廣東省分公司，廣東 廣州 510000）

1 引言

由于總部消息計(jì)費(fèi)總體技術(shù)架構(gòu)分為總部和省分兩級(jí)，均為統(tǒng)一版本，總部部分在總部統(tǒng)一部署，省分部分在各分省部署。其中消息會(huì)話管理子系統(tǒng)主要涉及總部、省分部署。省分部署的消息控制節(jié)點(diǎn)為多套獨(dú)立的節(jié)點(diǎn)，需要前端增加負(fù)載均衡的能力。實(shí)現(xiàn)計(jì)費(fèi)消息負(fù)載均衡，能根據(jù)業(yè)務(wù)要求進(jìn)行業(yè)務(wù)級(jí)的路由，實(shí)時(shí)進(jìn)行在線和離線的切換，同時(shí)做到消息級(jí)的負(fù)載均衡，支撐后端服務(wù)分布式集群部署。

2 實(shí)施目標(biāo)

（1）新增會(huì)話級(jí)負(fù)載均衡網(wǎng)元CCR消息到省分消息計(jì)費(fèi)消息控制節(jié)點(diǎn)主機(jī)；

（2）省分部署的消息控制節(jié)點(diǎn)集群?jiǎn)喂?jié)點(diǎn)故障時(shí)，故障節(jié)點(diǎn)會(huì)話記錄快速均衡到集群；

（3）支持動(dòng)態(tài)添加省分消息計(jì)費(fèi)的消息控制節(jié)點(diǎn)；

（4）實(shí)現(xiàn)本省在線接入鏈接消息計(jì)費(fèi)系統(tǒng)，產(chǎn)生負(fù)載均衡路由調(diào)整/變化時(shí)保證DCC消息不丟失。

3 技術(shù)方案

3.1 實(shí)現(xiàn)負(fù)載均衡

核心思想：根據(jù)處理的業(yè)務(wù)量進(jìn)行負(fù)載均衡，業(yè)務(wù)量以計(jì)費(fèi)請(qǐng)求消息數(shù)與計(jì)費(fèi)應(yīng)答消息數(shù)之差作為衡量(優(yōu)先實(shí)現(xiàn)這種策略)。啟用計(jì)數(shù)器登記計(jì)費(fèi)請(qǐng)求消息數(shù)與計(jì)費(fèi)應(yīng)答消息數(shù)之差，每發(fā)送一個(gè)計(jì)費(fèi)請(qǐng)求，計(jì)數(shù)器遞增一；反之每收到一個(gè)計(jì)費(fèi)應(yīng)答，計(jì)數(shù)器遞減一。業(yè)務(wù)流程如圖1所示。

圖1 業(yè)務(wù)流程圖

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

負(fù)載均衡設(shè)備可以實(shí)現(xiàn)客戶端連接級(jí)和請(qǐng)求會(huì)話級(jí)的負(fù)載均衡，同時(shí)可以開啟DCC的會(huì)話保持功能，并根據(jù)實(shí)際生產(chǎn)情況，調(diào)試負(fù)載均衡的算法：

（1）輪詢；

（2）加權(quán)輪詢；

（3）響應(yīng)時(shí)長(zhǎng)加權(quán)。

在Diameter協(xié)議的負(fù)載均衡會(huì)根據(jù)負(fù)載均衡的計(jì)算方法，將省分接入節(jié)點(diǎn)分發(fā)到消息計(jì)費(fèi)服務(wù)器上。負(fù)載均衡流程圖如圖2所示。

圖2 負(fù)載均衡流程圖

（1）Diameter握手進(jìn)程，CER請(qǐng)求到負(fù)載均衡設(shè)備,負(fù)載均衡設(shè)備根據(jù)輪詢的算法消息計(jì)費(fèi)Server 1，同時(shí)在CER/CEA中，在server的HOST ID可透?jìng)鹘oclient，負(fù)載均衡設(shè)備也可以替換。

（2）第二個(gè)Diameter CCR請(qǐng)求發(fā)送到負(fù)載均衡設(shè)備，負(fù)載均衡設(shè)備解析Session-id=y，是一個(gè)新的請(qǐng)求，那么負(fù)載均衡設(shè)備會(huì)根據(jù)輪詢的算法，把請(qǐng)求送到Proxy Server 2。在這里負(fù)載均衡設(shè)備是把Diameter協(xié)議中的AVP作為Session-id的值作為與后臺(tái)服務(wù)器會(huì)話的標(biāo)準(zhǔn)。

（3）假設(shè)負(fù)載均衡設(shè)備收到第三個(gè)CCR請(qǐng)求，解析其Session-id=x,也是一個(gè)新的請(qǐng)求，那么根據(jù)負(fù)載均衡的算法，發(fā)到消息計(jì)費(fèi)Server 1。

（4）收到第四個(gè)CCR請(qǐng)求，解析其AVPSession-id=y，那么根據(jù)AVP會(huì)話保持原則，負(fù)載到消息計(jì)費(fèi)Server 2。

（5）收到第五個(gè)CCR請(qǐng)求，解析其AVPSession-id=x，那么根據(jù)AVP會(huì)話保持原則，負(fù)載到消息計(jì)費(fèi)Server 1。

（6）收到第六個(gè)CCR請(qǐng)求，解析其AVPSession-id=y，那么根據(jù)AVP會(huì)話保持原則，負(fù)載到消息計(jì)費(fèi)Server 2。

（7）由于Diameter協(xié)議是異步協(xié)議，所以來自Server的響應(yīng)也是異步的。

（8）負(fù)載均衡設(shè)備不會(huì)透?jìng)鱀WR/DWA，而由負(fù)載均衡設(shè)備分別回應(yīng)。

（9）當(dāng)網(wǎng)元發(fā)出DPR，負(fù)載均衡設(shè)備把請(qǐng)求廣播到所有消息計(jì)費(fèi)Server服務(wù)器，如果只是消息計(jì)費(fèi)Server端發(fā)起DPR請(qǐng)求，那么負(fù)載均衡設(shè)備只是響應(yīng)這個(gè)Server服務(wù)器，不會(huì)影響其他的網(wǎng)元請(qǐng)求以及Server服務(wù)器。

3.2 實(shí)現(xiàn)系統(tǒng)自動(dòng)應(yīng)急響應(yīng)

業(yè)務(wù)流程如圖3所示。

圖3 系統(tǒng)自動(dòng)應(yīng)急流程圖

（1）負(fù)載均衡模塊通過定期Health Check Request心跳健康檢查偵測(cè)后臺(tái)消息計(jì)費(fèi)服務(wù)器是否正常；

（2）網(wǎng)元請(qǐng)求端正常發(fā)送DCC請(qǐng)求，負(fù)載均衡模塊按照輪詢的負(fù)載均衡方式分發(fā)到消息計(jì)費(fèi)Server 1節(jié)點(diǎn)上處理；

（3）此時(shí)消息計(jì)費(fèi)Server 1服務(wù)器節(jié)點(diǎn)失效；

（4）負(fù)載均衡設(shè)備定期Health Check心跳健康檢查偵測(cè)消息計(jì)費(fèi)Server 1節(jié)點(diǎn)失效，將該信息反饋給云化管理平臺(tái)；

（5）云化管理平臺(tái)得知消息計(jì)費(fèi)Server 1節(jié)點(diǎn)失效，準(zhǔn)備啟用消息計(jì)費(fèi)Server 2節(jié)點(diǎn)；

（6）云化管理平臺(tái)停止服務(wù)器消息計(jì)費(fèi)Server 1節(jié)點(diǎn)，釋放相關(guān)資源，并將此節(jié)點(diǎn)從消息計(jì)費(fèi)動(dòng)態(tài)云化資源池中移除；

（7）云化管理平臺(tái)啟用服務(wù)器消息計(jì)費(fèi)Server 2節(jié)點(diǎn)，并完成業(yè)務(wù)可用性驗(yàn)證；

（8）同一個(gè)會(huì)話新接續(xù)DCC請(qǐng)求達(dá)到負(fù)載均衡設(shè)備，不會(huì)再分發(fā)到失效的消息計(jì)費(fèi)Server 1節(jié)點(diǎn)，而是分發(fā)到Proxy動(dòng)態(tài)云化資源池中有效的消息計(jì)費(fèi)Server 2節(jié)點(diǎn)處理；新會(huì)話的DCC請(qǐng)求到達(dá)負(fù)載均衡設(shè)備，也分發(fā)到Proxy動(dòng)態(tài)云化資源池有效的消息計(jì)費(fèi)Server 2節(jié)點(diǎn)處理。

3.3 實(shí)現(xiàn)在線動(dòng)態(tài)擴(kuò)容

CMP要正確路由，首先要能識(shí)別每個(gè)鏈路是來自Proxy、FEP-CF、會(huì)話管理Session_Manager還是CMP管理客戶端。這個(gè)和CMP在與它們建立連接時(shí)，是客戶端還是服務(wù)端有關(guān)系。如果CMP是它們的客戶端，鏈路的建立是CMP的主動(dòng)行為，對(duì)于CMP識(shí)別這個(gè)鏈路是不存在問題的；但如果CMP是服務(wù)端，這個(gè)鏈路就要識(shí)別。根據(jù)系統(tǒng)目前的業(yè)務(wù)情況，CMP要支持：

（1）DCC協(xié)議：數(shù)據(jù)業(yè)務(wù)、語音業(yè)務(wù)、增值會(huì)話業(yè)務(wù)、WLAN業(yè)務(wù)

（2）SMPP+協(xié)議：短信業(yè)務(wù)

（3）SGIP協(xié)議：增值事件業(yè)務(wù)

支持同種協(xié)議時(shí)，相關(guān)流程如圖4所示。

圖4 在線動(dòng)態(tài)擴(kuò)容流程圖

（1）網(wǎng)元請(qǐng)求端正常發(fā)送DCC請(qǐng)求，負(fù)載均衡設(shè)備按照輪詢的負(fù)載均衡方式分發(fā)到消息計(jì)費(fèi)Server 1節(jié)點(diǎn)上處理；

（2）負(fù)載均衡設(shè)備定期反饋Proxy負(fù)載信息至云化管理平臺(tái)；

（3）云化管理平臺(tái)檢測(cè)Proxy負(fù)載是否超過設(shè)定閾值，如果超過閾值，則需要啟動(dòng)新Proxy資源節(jié)點(diǎn)；

（4）云化管理平臺(tái)啟動(dòng)新資源節(jié)點(diǎn)消息計(jì)費(fèi)Server 3；

（5）云化管理平臺(tái)要求負(fù)載均衡設(shè)備驗(yàn)證并反饋新節(jié)點(diǎn)消息計(jì)費(fèi)Server 3的可用性；

（6）云化管理平臺(tái)根據(jù)反饋信息判斷新節(jié)點(diǎn)是否可用；如果可用，通知負(fù)載均衡設(shè)備將新節(jié)點(diǎn)消息計(jì)費(fèi)Server 3加入到Proxy云化資源池中；

（7）新會(huì)話請(qǐng)求按負(fù)載均衡方式分發(fā)到原有效消息計(jì)費(fèi)Server 2節(jié)點(diǎn)處理；

（8）另一個(gè)新會(huì)話請(qǐng)求按負(fù)載均衡方式分發(fā)到新啟用的消息計(jì)費(fèi)Server 3節(jié)點(diǎn)處理。

3.4 在線版本升級(jí)過程實(shí)現(xiàn)

集群中的CF應(yīng)用版本升級(jí)有幾種方式：

（1）Proxy全業(yè)務(wù)切離線，再升級(jí)應(yīng)用版本（手工方式）；

（2）CMP支持設(shè)置節(jié)點(diǎn)升級(jí)模式（后續(xù)說明這個(gè)模式），手工逐一停節(jié)點(diǎn)，再升級(jí)應(yīng)用，啟動(dòng)應(yīng)用（手工方式）；

（3）CMP自動(dòng)升級(jí)方式。

進(jìn)入節(jié)點(diǎn)升級(jí)模式時(shí)，CMP斷開該節(jié)點(diǎn)的連接，會(huì)把該節(jié)點(diǎn)的會(huì)話記錄設(shè)置為故障，需要同步到其它節(jié)點(diǎn)，CMP啟動(dòng)一個(gè)新的后臺(tái)進(jìn)程進(jìn)行升級(jí)，當(dāng)CMP完成升級(jí)，該節(jié)點(diǎn)以一個(gè)新節(jié)點(diǎn)添加的方式重新加入集群中。升級(jí)完成分單節(jié)點(diǎn)完成和整個(gè)集群完成。升級(jí)過程的狀態(tài)，比如升級(jí)完成了幾個(gè)節(jié)點(diǎn)，還有幾個(gè)節(jié)點(diǎn)的信息，CMP需要提供信息顯示。一個(gè)節(jié)點(diǎn)的應(yīng)用在升級(jí)過程中大概需要耗時(shí)100ms，這跟不同的應(yīng)用啟動(dòng)時(shí)間有關(guān)。總之，能提供新節(jié)點(diǎn)的添加命令，就能通過手工逐一升級(jí)每個(gè)節(jié)點(diǎn)的應(yīng)用。

升級(jí)說明：

（1）升級(jí)模式修改為離線控制模式，因?yàn)橄⒂?jì)費(fèi)系統(tǒng)的升級(jí)時(shí)會(huì)造成CCA返回錯(cuò)誤碼；

（2）保留升級(jí)模式的部分手工操作命令，并能配合Proxy進(jìn)行離線容災(zāi)機(jī)制的切換。

在線升級(jí)流程如圖5所示。

圖5 在線版本升級(jí)流程圖

（1）云化管理平臺(tái)啟動(dòng)Proxy版本升級(jí)過程；

（2）云化管理平臺(tái)卸載部分在線資源節(jié)點(diǎn)到空閑資源池中；

（3）云化管理平臺(tái)向空閑資源池中可用的節(jié)點(diǎn)發(fā)送Proxy新版本升級(jí)指令；

（4）安裝新版本Proxy應(yīng)用；

（5）啟用新版本Proxy應(yīng)用；

（6）云化管理平臺(tái)要求負(fù)載均衡設(shè)備激活并反饋新版本節(jié)點(diǎn)的可用性；

（7）云化管理平臺(tái)要求負(fù)載均衡設(shè)備卸載舊版本Proxy節(jié)點(diǎn)；

（8）負(fù)載均衡設(shè)備發(fā)起并停止舊版本Proxy節(jié)點(diǎn)。

3.5 實(shí)現(xiàn)在線會(huì)話離線

系統(tǒng)由Proxy模塊向網(wǎng)元提供服務(wù)端口，同時(shí)具備對(duì)網(wǎng)元計(jì)費(fèi)請(qǐng)求進(jìn)行“在線”“離線”方式的切換。Proxy以SOCK客戶端的方式連接fep_ctrl模塊，在SOCK鏈路異常、無法通信的情況下，就會(huì)進(jìn)行離線切換，連接到offline_cf模塊。實(shí)現(xiàn)從系統(tǒng)層面、業(yè)務(wù)層面、網(wǎng)絡(luò)物理層面綜合考慮，三者在滿足特定的條件都要進(jìn)行離線切換：

（1）當(dāng)Proxy與fep_ctrl之間的鏈路不可達(dá)，把消息計(jì)費(fèi)該節(jié)點(diǎn)業(yè)務(wù)全部切到離線；

（2）當(dāng)消息計(jì)費(fèi)系統(tǒng)處理業(yè)務(wù)出現(xiàn)故障時(shí)把當(dāng)前會(huì)話切換到離線。

4 方案創(chuàng)新和先進(jìn)

本項(xiàng)目通過實(shí)現(xiàn)計(jì)費(fèi)消息負(fù)載均衡，能根據(jù)業(yè)務(wù)要求進(jìn)行業(yè)務(wù)級(jí)的路由，實(shí)時(shí)進(jìn)行在線和離線的切換，同時(shí)做到消息級(jí)的負(fù)載均衡，支撐后端服務(wù)分布式集群部署。

（1）負(fù)載均衡：Proxy和負(fù)載均衡設(shè)備接合，實(shí)現(xiàn)消息負(fù)載均衡的功能，能把CCR消息均衡等發(fā)送到后端的多個(gè)節(jié)點(diǎn)，減輕某個(gè)節(jié)點(diǎn)因業(yè)務(wù)量過大支撐不住的情況。

（2）實(shí)時(shí)容災(zāi)：當(dāng)后端集群中某個(gè)節(jié)點(diǎn)出現(xiàn)問題時(shí)，Proxy能及時(shí)對(duì)該節(jié)點(diǎn)進(jìn)行遷離線，不影響用戶使用感知，當(dāng)后端節(jié)點(diǎn)恢復(fù)正常后能實(shí)時(shí)遷回在線。

（3）高效運(yùn)維：支持通過直觀的Web界面進(jìn)行系統(tǒng)監(jiān)控和管理，能及時(shí)監(jiān)控業(yè)務(wù)量，并根據(jù)業(yè)務(wù)相求進(jìn)行業(yè)務(wù)類型路由，能及時(shí)監(jiān)控返回碼來確定業(yè)務(wù)是否正常。

作為消息計(jì)費(fèi)省分控制節(jié)點(diǎn)的前置分發(fā)服務(wù)節(jié)點(diǎn)，通過負(fù)載均衡技術(shù)應(yīng)用，提供快速的自動(dòng)擴(kuò)容改造、故障節(jié)點(diǎn)會(huì)話均衡管理、節(jié)點(diǎn)動(dòng)態(tài)擴(kuò)縮、在線版本升級(jí)等服務(wù)，每套計(jì)費(fèi)負(fù)載均衡產(chǎn)品滿足：CCR消息平均時(shí)延小于50ms，同時(shí)并發(fā)4萬每秒CCR，計(jì)費(fèi)負(fù)載均衡設(shè)備按主備部署容災(zāi)。

在業(yè)務(wù)正常(每百萬有效用戶全部業(yè)務(wù)1000caps)情況下，系統(tǒng)消息處理響應(yīng)時(shí)間達(dá)到如下響應(yīng)性能要求（70%的負(fù)荷）：

（1）95%消息量響應(yīng)時(shí)長(zhǎng)小于20ms；

（2）98%消息量響應(yīng)時(shí)長(zhǎng)小于30ms；

（3）99.9%消息量響應(yīng)時(shí)長(zhǎng)小于45ms；

（4）99.999%消息量響應(yīng)時(shí)長(zhǎng)小于100ms。

有效保障業(yè)務(wù)不間斷無縫接駁計(jì)費(fèi)，至今系統(tǒng)保證100%無故障運(yùn)營，系統(tǒng)自修復(fù)率為100%，效果顯著。