【摘要】 受互聯(lián)網(wǎng)OTT消息類業(yè)務沖擊,電信運營商的短信等傳統(tǒng)高價值業(yè)務下滑趨勢加劇,在此背景下,短信原有業(yè)務模型已不能適應業(yè)務發(fā)展,同時,傳統(tǒng)的擴容辦法也已不能適應運營商網(wǎng)絡(luò)轉(zhuǎn)型要求。本文對短信業(yè)務模型優(yōu)化方法進行研究,基于現(xiàn)網(wǎng)數(shù)據(jù)分析,對部分參數(shù)進行優(yōu)化調(diào)整,從實際效果看,在滿足業(yè)務需求情況下較好節(jié)省了投資。同時,也對短信平臺基于云計算進行部署的可行性進行評估,并對云化部署步驟和方案進行了研究。最后,本文對移動互聯(lián)網(wǎng)時代短信業(yè)務的發(fā)展思路進行了探討。
【關(guān)鍵字】 短信業(yè)務 模型優(yōu)化 云化部署
一、背景
隨著移動互聯(lián)網(wǎng)應用的日益豐富,特別是微信等OTT業(yè)務的飛速發(fā)展,電信運營商的短信、彩信等業(yè)務正在受到?jīng)_擊,統(tǒng)計數(shù)據(jù)顯示[1],2014年1-6月,全國移動短信業(yè)務量僅有3789億條,同比下降18%;彩信業(yè)務量僅有316億條,同比下降30.3%。移動短信業(yè)務收入持續(xù)下滑,1-6月,收入規(guī)模同比減少37.3億,除了1月份春節(jié)刺激增長以外,連續(xù)23個月出現(xiàn)負增長。
在此背景下,短信、彩信等的原有業(yè)務模型已與用戶使用習慣產(chǎn)生偏差,如按原有業(yè)務模型對平臺進行規(guī)劃和建設(shè),既與實際需求不匹配,不適應業(yè)務發(fā)展,同時也造成投資的浪費,本文將以短信平臺為例,對業(yè)務模型的優(yōu)化調(diào)整進行研究,同時,對短信平臺云化部署進行探討。
二、短信業(yè)務模型優(yōu)化
結(jié)合對某電信運營商省級公司短信中心的現(xiàn)網(wǎng)日常、節(jié)假日的數(shù)據(jù)監(jiān)測與分析,短信中心業(yè)務總量、點對點業(yè)務量、月平均每用戶點對點短信數(shù)量自2013年起呈明顯下降趨勢。
2.1原有業(yè)務模型
某電信運營商省級公司短信中心原業(yè)務模型如下:
短信中心處理能力=總用戶數(shù)×(平均每天發(fā)送短消息條數(shù)+平均每天接收短消息條數(shù))×忙時集中比系數(shù)/3600×節(jié)假日放大系數(shù)。
2.2調(diào)整后業(yè)務模型及效果
由上文分析可以看出:
由于受到互聯(lián)網(wǎng)OTT消息類業(yè)務的沖擊,短信業(yè)務量處于下滑的趨勢,并且這一趨勢會逐漸加劇;
平均每天發(fā)送短消息條數(shù)、平均每天接收短消息條數(shù)因用戶短信量減少,應根據(jù)實際情況做調(diào)整;
短信平常日期業(yè)務量處于下降趨勢,僅受節(jié)假日影響點對點短信量會發(fā)生劇增,但考慮到在節(jié)假日時將會關(guān)閉SP群發(fā)短信通道,故平時忙時業(yè)務量和節(jié)假日忙時業(yè)務量相差不大,需對節(jié)假日放大系數(shù)進行調(diào)整。
根據(jù)業(yè)務量實際情況進行分析,短信中心業(yè)務模型主要調(diào)整參數(shù)為:
節(jié)假日放大系數(shù):原取值為3,調(diào)整后為1.1;
平均每用戶每天發(fā)送短消息條數(shù):原取值為6.7,調(diào)整后為1.23;
平均每用戶每天接收短消息條數(shù):原取值為9.03,調(diào)整后為3.42。
業(yè)務模型優(yōu)化前后對比如下:
現(xiàn)有能力:6000條/秒;
原有擴容方式(達到值):11000條/秒;
優(yōu)化擴容方法(達到值):6442條/秒;
實際擴容(增量):442條/秒。
可以看出:模型優(yōu)化后,短信中心能力僅需擴容442條/秒(滿足峰值),減少擴容4558條,可節(jié)省投資約200萬元。
2.3業(yè)務模型優(yōu)化后續(xù)建議
1)基于長期歷史數(shù)據(jù)分析得到的業(yè)務模型會更加貼近實際,符合長期業(yè)務發(fā)展趨勢,故短信中心應對盡可能長時間的歷史數(shù)據(jù)進行保存(建議至少一年);同時,對日常及節(jié)假日峰值數(shù)據(jù)進行存檔,可便于驗證優(yōu)化后模型是否滿足峰值需求。
2)短信業(yè)務隨著移動互聯(lián)網(wǎng)的發(fā)展也在不斷變化,短信業(yè)務模型也建議進行周期性修正,以適應業(yè)務的迅速變化。
三、短信平臺云化方案
隨著移動互聯(lián)網(wǎng)進入高速發(fā)展期,電信運營商面臨被“管道化”,需加快網(wǎng)絡(luò)轉(zhuǎn)型。而運營商業(yè)務平臺與移動互聯(lián)網(wǎng)平臺最為相似,因此業(yè)務平臺就成為運營商向移動互聯(lián)網(wǎng)化轉(zhuǎn)型的排頭兵。通過對“BAT”三大公司企業(yè)戰(zhàn)略的分析,不難看出云平臺是共同的基礎(chǔ),云平臺符合移動互聯(lián)網(wǎng)時代的特征,用戶體驗優(yōu)、開放、低成本、可運營、業(yè)務提供快速。因此,打造業(yè)務平臺云,實現(xiàn)業(yè)務創(chuàng)新,成為電信運營商轉(zhuǎn)型的關(guān)鍵。
短信業(yè)務具有節(jié)假日等高峰期突發(fā)性明顯的特征,若處理能力不足,容易造成時延,大大降低用戶感知,造成用戶流失。隨著用戶數(shù)的增多,電信運營商一般對短信平臺相關(guān)硬件進行逐年擴容,采用傳統(tǒng)方式(非云計算),存在部署時間長、非高峰期資源利用率低、投資較高等缺點,且不符合技術(shù)發(fā)展趨勢,故可對短信平臺進行云化部署。
3.1主要模塊云化評估
1)信令前置機:信令專用設(shè)備,暫不能云化;
2)業(yè)務處理機、SMPP Server、接口機:硬件基于X86,操作系統(tǒng)基于Linux,可優(yōu)先考慮云化;
3)QAS/CDR/DB Server:承載有關(guān)系型數(shù)據(jù)庫,建議在引入分布式數(shù)據(jù)庫后,實施云化遷移。
由以上分析可知,除信令專用設(shè)備外,短信中心業(yè)務分析、接口、SMPP等全部業(yè)務均可移植在虛擬機環(huán)境運行。
3.2云化步驟及方案
對于短信平臺云化,總體方案可分三個階段進行實施:
第一階段:云化平臺搭建,主要建設(shè)內(nèi)容包括資源申請、環(huán)境搭建、軟件部署、軟件功能與壓力測試等。該階段續(xù)完成短信平臺業(yè)務處理機、接口服務器等模塊的虛擬化部署;
第二階段:云節(jié)點與現(xiàn)網(wǎng)節(jié)點雙節(jié)點試運行,主要建設(shè)內(nèi)容包括云化平臺的對外接口配置、功能配置修改、DNS分流配置、周邊網(wǎng)元配置與對接實測等;
第三階段:整體遷移云化,主要建設(shè)內(nèi)容包括數(shù)據(jù)庫遷移、應用程序配置、DNS指向與網(wǎng)絡(luò)配置調(diào)整等,由云化平臺承接業(yè)務,因平臺地址涉及眾多SP,聯(lián)調(diào)量大,建議盡量采用原地址,如云資源池建設(shè)情況無法滿足源地址攜帶的話,可選擇更改為新地址,建議更改平臺訪問方式為域名方式。
四、短信業(yè)務發(fā)展思路探討
相比微信等OTT信息服務,短信雖費用略高,但發(fā)布正式、到達較為快捷、來源可靠,使其成為多數(shù)用戶正式溝通或者獲取商家信息的首選。在具體應用中,例如支付寶的驗證碼服務,依靠短信為用戶提供實時的安全金融服務。
從某電信運營商省級公司短信中心提取數(shù)據(jù)來看,雖然點對點短信業(yè)務量呈加速下滑趨勢,但行業(yè)短信得以蓬勃發(fā)展,以2014年6月為例,用戶接受點對點短信為6404萬條,接受群發(fā)短信為3.51億條,絕大部分業(yè)務為行業(yè)短信。
針對點對點短信業(yè)務呈現(xiàn)疲軟,行業(yè)短信拉動發(fā)展的現(xiàn)狀,可以預見以后短信中心的峰值就在平時,而不會出現(xiàn)在節(jié)假日的所謂高峰。而業(yè)務的定位也應該著眼于群發(fā)和行業(yè)短信:
群發(fā)短信方面,可針對節(jié)假日,推出相應的短信促銷和套餐優(yōu)惠,針對商戶發(fā)布群發(fā)短信的優(yōu)惠套餐。
行業(yè)短信方面,在銀行、交通等行業(yè)應用中,短信起到了關(guān)鍵性的作用。對行業(yè)客戶而言,短信意味著電信運營商的一套高效安全的運營體系,包括了整個質(zhì)量管理體系和安全保障體系。事實上,OTT平臺出現(xiàn)不僅影響了消費級市場,而且對行業(yè)應用也有一定的影響,但因為行業(yè)用戶有一定的使用門檻,使得沖擊變得緩慢。因此電信運營商應更多地與行業(yè)用戶和企業(yè)用戶進行協(xié)作,為企業(yè)內(nèi)部治理和行業(yè)應用提供支持,特別是在交通、銀行、教育、天氣等政府部門和大型企事業(yè)單位,這些部門對信息發(fā)布的權(quán)威性和可達性要求較高,應著力為其提供支撐服務。