论文部分内容阅读
摘 要：文章提出了一种针对业务平台进行云化改造的研究方法，分析了系统现状和业务需求，设计了云化改造方案，构建了云化网络结构，实现了短彩信业务平台的虚拟化。目前，运营商传统的短彩信业务渐渐萎缩，业务数量和利润均明显下降。改造之后的云化平台能够提高网络质量和资源利用率，降低生产投入和维护成本，达到了降本增效的目的。
关键词：虚拟化;短彩信业务;降本增效;云化平台
随着移动互联网技术的`飞速发展，各类移动互联网公司和“互联网+”业务也在不断更新，移动、联通、电信等运营商受到了巨大的冲击，特别是手机终端及其系统软件向智能化、信息化的不断转变，使得运营商的短信、彩信等传统业务明显萎缩。短彩信业务忙时、闲时的负荷差距巨大，尤其在短彩信空闲时，业务平台的资源利用率较低，出现一定程度的资源浪费。
随着各大运营商整体业务的更新和发展，以及各个业务平台虚拟化改造的不断推进，近年来出现了越来越多的云化平台。将业务平台进行虚拟化改造，一方面，可以结合云资源池的特性对现有系统的软件结构进行优化;另一方面，可以节约系统资源，并达到降低维护成本、实现节能减排的目标。
1 系统现状
根据工业和信息化部近几年公布的统计结果，短彩信收发的数量在逐年下降，特别是彩信数量下降的更为明显。下面以某公司彩信业务为例，进行虚拟云化改造的分析和研究。
1.1 网络结构现状
彩信中心业务平台网络结构如图1所示，一套完整的彩信中心包括2台以上的业务处理机、数据库服务器双机、计费话单服务器双机、核心交换机双机、负载均衡器双机、防火墙双机（双机均互为冗余容灾）以及报表呈现服务器、日志查询服务器、安全接口服务器、垃圾彩信接口服务器、客服管理服务器、操作维护服务器、备份服务器等[1]。
1.2 系统结构现状
彩信中心于2008年新建了第一期工程，第一期彩信中心的系统处理能力为忙时平均20条/s，实现了彩信业务的基本功能。2008年的年底开始向天翼189用户提供彩信服务，并于2009年8月全面开通彩信业务。2010年对彩信中心的业务功能进行了升级，彩信中心的处理能力扩容至忙时平均50条/s。2011年工程改造后，彩信中心的软件处理能力扩容至忙时平均120条/s。2012年工程改造后，彩信中心软件处理能力再次扩容至忙时平均160條/s，同时，对系统软件继续升级，以满足集团和本地的相关功能需求。2014年工程改造后，彩信中心满足集团统一版本升级需求，并对彩信中心信息安全的相关接口和功能进行了改造。2015年工程根据集团统一版本升级要求，新增垃圾彩信拦截功能模块，拦截各类垃圾彩信和违规彩信，有效净化了网络环境。目前彩信中心的处理能力为180条/s。
1.3 平台设备现状
彩信中心系统平台自从2008年建成之后，仅在2015年工程中增加了2台ZXA1000服务器部署垃圾彩信拦截模块，未新增其他硬件。目前，彩信平台业务处理机为Sun Fire T2000服务器，在网运行时间较长，性能条件老化，服务器在系统忙时CPU占用率约为50%，内存占用率约为50%，业务忙时内存占用率接近80%，并且系统已占用约20%的虚拟内存（硬盘空间），系统负荷较高。此外，平台中部分型号的服务器已经停产，并且无法增加CPU和内存，当设备硬件出现故障之后再去采购新的硬件也比较困难。
2 业务需求分析
根据虚拟化技术对现网系统及设备的分析研究，计划对彩信平台进行云化改造，具体的改造要求如下：
（1）将彩信业务平台全部云化，包括对所有的处理机、网络设备、存储设备等全部进行云化，云化所需计算存储和网络资源均由资源池分配。
（2）在彩信业务平台进行云化改造的过程中，彩信业务不中断，改造之后彩信平台的业务处理能力不低180条/s。
3 云化改造部署方案
3.1 方案相关简介
彩信中心的扩容改造工程采用云化部署的方案，将彩信业务平台部署在云资源池上，并将所有的处理机、网络设备、存储设备等在资源池中进行统一划分。
云化改造之后系统的硬件容量仍为180条/s，至少需要2台虚拟机设备。从N+1容灾的角度考虑，需要3台4 C 32 G的虚拟机，并加载Suse Linux11 sp3操作系统。
3.2 配置计算
3.2.1 话务模型
对关键服务器设备进行配置时，按照平均每条彩信50 KB计算，对存储容量和系统带宽配置时也按照平均50 KB计算。
忙时彩信业务量占全天彩信业务量的比例为10%，忙天彩信业务量占全月彩信业务量的比例为5%。
彩信中心系统license限制容量是180条/s，计算如下：
忙时彩信业务量：180×3 600=648 000。
忙天彩信业务量：180×3 600÷10%=648 000 0。
忙月彩信业务量：180×3 600÷10%/5%=129 600 000。
3.2.2 彩信业务存储空间
（1）当业务处理机采用N+1方式时，内容存储设备采用网络附属存储（Network Attached Storage，NAS）架构，各个业务处理服务器共享内容存储设备上的彩信消息内容。
（2）各个业务处理机的服务器与内容存储设备相连接，当需要配置多套内容存储设备时，与各服务器的连接方式采用业务处理机服务器分组式，每组连接一个内容存储设备。
（3）当有多套内容存储设备时，可以进行叠加使用，整体处理性能也按照线性增加。 内容存储采用NAS磁阵，根据工业和信息化部出台的多媒体消息业务规范，彩信消息需要在系统内有3天的存储时间。按照平均每条彩信消息的大小50 K计算，每天10 h的忙时系数，则存储3天总计需要的磁盘空间为（考虑到30%的冗余）=3×180条/s×3 600×10%×10×50 K÷1 024÷1 024÷ 0.7=133 G
3.2.3 用户数据存储
彩信数据库存储需要两部分的空间，其中，Sybase数据库需要占用一部分基本空间，用户信息占用另外一部分数据库空间。通常Sybase数据库占用的基本空间大约为40 G;每用户的开户信息大小为4 KBytes，需要的磁盘空间=（40+4 K ×用户数÷1 024÷1 024）÷0.7
当用户数为1 100万的时候，计算出磁盘空间需求为89 G。
3.2.4 计费话单存储
每一条彩信消息都会产生1条O CDR计费话单和1条T CDR计费话单（暂不考虑投递报告话单和响应报告话单）。按照每条CDR计费话单长度220 Bytes计算，话单在线保存4倍忙月，取30%空间冗余[2]，需要的话单空间=180条/s× 3 600÷10%÷5%×2×220×4÷0.7÷1 024÷ 1 024÷1 024
=304 G
3.2.5 日志存储
在日志服务器上数据的保存分为兩部分：日志文件（包括接口日志和话单日志）的保存，话单日志的入库保存。根据规范要求，对于日志查询功能所需要的存储空间，要求应满足2个月时长的查询需求。取30%空间冗余，保存2个月日志需=180条/s×3 600÷10%÷5%×3 K×2÷1 024÷1 024÷0.7=1 060 G
3.2.6 报表存储
根据规范要求，报表原始数据需要在线保存3个月，生成的所有报表数据需要在线保存24个月。
在报表呈现服务器上的数据主要是对来自多个数据源的数据进行统一处理，并将中间结果保存，空间使用情况如下。
对数据库、各类配置数据导入报表服务器，大约预留50 G[2]。一条彩信业务对应的报表原始数据大小为1 KB，每月产生的报表原始数据大小为：忙月彩信业务量×1 KB，报表处理的原始数据保留3个月，共需：
3.3 局域网宽带计算
3.3.1彩信中心Relay/Server业务处理机服务器带宽计算
彩信中心系统内部的各个网元与以太网交换机之间，网卡出口处产生流量最大的设备为彩信中心Relay/Server业务处理机，对于带宽的要求如下：
在彩信的整个流程中，每台彩信中心Relay/Server产生的流量大小为彩信的3倍，另外，包括日志流量（3 KB/条）、内部信令（1 K）、外部信令（1 K）、投递报告（2 K）、计费流量（2 K）、网管采集流量（2 KB/条），总计每条彩信业务需要的流量=3×50 KB+3 KB+1 KB+2 KB+1 KB+2 KB+2 KB=161 KB
彩信中心Relay/Server业务处理机端口上承受的总的带宽流量=180条/s×161 KB×8（bit）÷70%÷1 024=323 M
3.3.2 广域网带宽计算
广域网带宽主要需要考虑彩信中心与移动网增值业务经营许可证（Service Provider，SP）之间、与彩信网关（Multimedia Message Service Gateway，MMSG）之间、与ENUM DNS之间、与网管系统之间、与彩信终端之间的双向通信，其他细小流量均可忽略不计，因此，可取以下话务模型：
（1）广域网以太网利用率为70%。
（2）平均每条彩信的大小为50 K Byte。
（3）点对点业务比例30%，SP业务比例为70%。
（4）全网SP业务比例40%，本地SP业务比例60%。
（5）每条业务与 综合业务管理平台（Integrated Services Management Platform，ISMP），ENUM DNS之间的查询信令流量大约2 K。
3.3.3 彩信中心系统与SP之间的带宽计算
彩信中心需要对每个接收方查询一次ENUM DNS。其中，到ENUM DNS每次请求、应答的双向数据传送为0.7 KB左右（查询消息0.2 KB，响应消息0.5 KB），由于彩信中心具有将ENUM DNS查询数据本地存储功能，因此，按照更新本地数据比例为10%计算。
（1）流入带宽的计算。
流入带宽=每秒提交消息中接收方总数×每次与ENUM DNS交互应答消息大小×8×10%÷1 024÷70%
（2）流出带宽的计算。
彩信中心需要对每个收费方查询一次ISMP/DRM。其中，到ISMP/DRM每次请求、应答消息大小为1 KB左右，则彩信中心与ISMP/DRM带宽=每秒提交消息中接收方总数×每次与ISMP÷DRM交互应答消息大小×8÷1 024÷70%
3.3.7 彩信中心下发MM带宽计算
投递报告大小以2 K计算，考虑一定的冗余（假定网络带宽利用率为70%），流出防火墙的流量=180条/s×（80 K+2 K）×8÷1 024÷70%=165 Mbps
3.3.8 广域网带宽汇总
与专网连接带宽考虑70%的利用率后所需要的流入带宽（Mb/s），考虑70%的利用率流出总带宽（Mb/s）：
4 云化改造的优点 （1）规范性：严格遵守集团公司相关的业务规范和技术规范的要求，由集团进行整体规划安排和统一建设维护。
（2）开放性：系统根据开放性的原则，采用开放的接口协议和开发平台，为用户提供开放的业务接口;设备维护和业务发展不再依赖于设备厂商，方便添加增减模块和实时升级系统[3]。
（3）成本低：相比于以前传统的维护平台，云化平台所需的现网设备要更少，因此云化平台无论是建设部署，还是维护使用的成本都很低，此外，云化平台的更新周期和使用时间也都延长了，大大降低日后的改造成本。
（4）效益高：降低了短彩信业务维护对网络和系统的消耗，提升了网络效能和利用率，稳定了系统的使用负荷，经济效益显著。
（5）自主性：随着业务的不断发展，系统平台的需求也越来越大，云化系统可以自主地增加、删除各类模块及其功能，方便系统的管理和维护。另外，虽然业务在不断发展，但是总有部分系统不能完全下线，而云化系统中各模块相对独立、方便集成，可以用最小的成本与原有系统进行对接及维护。
（6）安全性：云化系统按照电信级的应用进行设计和维护，从整体系统运行的安全策略和保密机制来设计系统的软硬件架构，采用多种安全方法、安全技术，为用户提供完善的安全保障系统[4]。
5 云化之后平台网络结构
云化之后彩信中心业务平台网络结构如图2所示。
互联网应用范围越来越广泛，通信设备自身功耗增加的同时，也增加了机房空调、电源等设施的功耗，不但提高了运营商初期的网络建设成本，而且提高了运营商日后的维护运营成本。将传统业务平台进行虚拟化之后，不再单独新增硬件设备，能有效降低能耗，节省机房空间与资源，绿色环保。
此外，云化改造之后，一方面，节约了系统资源和运维成本;另一方面，也提升了短彩信业务的效能。通过精细化管理提高综合业务的接入能力和维护能力，为网络精确运营和市场精确营销提供了服务与保障。
6 网络安全与信息安全要求
（1）有DCN网地址或者外网IP地址的系统应该纳入到网络安全和信息安全管理中，安全管理部门提供资产管理、主机合规扫描、漏洞扫描、配置核查等功能模块，要对系统进行定期检查及安全评估。
（2）所有平台及其系统（系统资源和应用资源）的网络设备配置应满足基线配置规范。系统的端口和服务等基础安全信息须进行备案，对于必须的端口要对其进行应用软件和功能用途的登记和报备，严禁开放非必要端口的开放。对操作系统、网络设备、数据库等进行安全基线配置，包括安全审计管理、系统账号管理、密码复杂度策略、关闭危险服务等，确保系统配置及使用的安全性[5]。
（3）最小化服务端口管理，对于所有系统的网络服务设置，必须遵循最小化服务原则，关闭不需要服务，减小互联网暴露面，对于危险端口，严禁对外网开放。对于必须开启的网络服务，要通过配置策略限制远程主机源地址。
（4）将所有业务平台及其系统（系统资源和应用资源）纳入集中监控系统，及时发现系统告警及故障等。通过部署流量检测系统，建立异常流量的监控及预警，防止流量攻击。
（5）安装专业的防病毒软件，及时更新病毒库，定期对系统做全面的病毒扫描，及时发现并消灭病毒。建议设置为每天自动更新病毒库，以及每周对系统做全面的病毒扫描。
（6）系统的物理安全，系统线缆布放整齐合理，符合公司机房规范。各种标签齐全，标签内容应该打印，不能手写;新建机架的配电模块应使用空气开关，严禁在集装架内随意串接、复接电源插线板或设备等。
（7）双路由双节点，系统重要传输节点要有双路由、双节点备份，满足灾难发生后数据恢复的要求，并且必须满足可以在规定时间内完成倒换转接业务的要求。
（8）系统信息安全，网站接入系统时要严格落实“先备案 后接入”的管理规定，严禁自用、自营、合作网站出现未备案先接入或备案信息不准的现象。对外发布内容时要严格落实“先审核 后发布”的管理规定，建立定期检查制度，避免不良信息的产生。
7 结语
随着QQ、微信等各种社交软件的不断出现，运营商以前传统的短彩信业务渐渐萎缩，再加上国家“降本增效”“提速降费”等政策性的压力，运营商的利润也被不断地压缩，唯有减少投入、节约成本才能可持续的发展。
将传统业务平台进行虚拟化之后，既能节约系统的运维成本，又能提高短彩信业务的效能。创新了网络支撑业务的思路，完善了业务系统平台的框架，在提高網络质量的同时也提高了用户的满意度。
[参考文献]
[1]邓云松.海南电信中兴ITV2.0平台升级到3.0平台部署[J].电脑知识与技术，2016（15）：33-36.
[2]孙旻姝.关于新建多媒体消息业务网关系统方案的研究[D].长春：吉林大学，2010.
[3]陈锦娟.宽带多媒体终端管理和业务发放平台[D].广州：华南理工大学，2012.
[4]黄根华，钟声伟.分布式存储系统在通信运营商云计算资源池的应用研究[J].通讯世界，2017（16）：48-49.
[5]黄筱芬.重庆银行短信业务系统的设计与实现[D].成都：电子科技大学，2014.
Abstract：In this paper， a research method for the transformation of the business platform is proposed. The present situation of the system and the business requirement are analyzed， and the cloud-based transformation scheme is designed， and the cloud-based network structure is constructed， and the virtualization of the short-message service platform is realized. At present， the traditional short multimedia message service of the operator is gradually shrinking， and the number and profit of the service are obviously reduced. After the transformation， the cloud-based platform can improve the network quality and the resource utilization ratio， reduce the production investment and the maintenance cost， and achieve the purpose of reducing the cost and increasing efficiency.
Key words：virtualization; short and multimedia message service; cost reduction and efficiency increase; cloud-based platform
关键词：虚拟化;短彩信业务;降本增效;云化平台
随着移动互联网技术的`飞速发展，各类移动互联网公司和“互联网+”业务也在不断更新，移动、联通、电信等运营商受到了巨大的冲击，特别是手机终端及其系统软件向智能化、信息化的不断转变，使得运营商的短信、彩信等传统业务明显萎缩。短彩信业务忙时、闲时的负荷差距巨大，尤其在短彩信空闲时，业务平台的资源利用率较低，出现一定程度的资源浪费。
随着各大运营商整体业务的更新和发展，以及各个业务平台虚拟化改造的不断推进，近年来出现了越来越多的云化平台。将业务平台进行虚拟化改造，一方面，可以结合云资源池的特性对现有系统的软件结构进行优化;另一方面，可以节约系统资源，并达到降低维护成本、实现节能减排的目标。
1 系统现状
根据工业和信息化部近几年公布的统计结果，短彩信收发的数量在逐年下降，特别是彩信数量下降的更为明显。下面以某公司彩信业务为例，进行虚拟云化改造的分析和研究。
1.1 网络结构现状
彩信中心业务平台网络结构如图1所示，一套完整的彩信中心包括2台以上的业务处理机、数据库服务器双机、计费话单服务器双机、核心交换机双机、负载均衡器双机、防火墙双机（双机均互为冗余容灾）以及报表呈现服务器、日志查询服务器、安全接口服务器、垃圾彩信接口服务器、客服管理服务器、操作维护服务器、备份服务器等[1]。
1.2 系统结构现状
彩信中心于2008年新建了第一期工程，第一期彩信中心的系统处理能力为忙时平均20条/s，实现了彩信业务的基本功能。2008年的年底开始向天翼189用户提供彩信服务，并于2009年8月全面开通彩信业务。2010年对彩信中心的业务功能进行了升级，彩信中心的处理能力扩容至忙时平均50条/s。2011年工程改造后，彩信中心的软件处理能力扩容至忙时平均120条/s。2012年工程改造后，彩信中心软件处理能力再次扩容至忙时平均160條/s，同时，对系统软件继续升级，以满足集团和本地的相关功能需求。2014年工程改造后，彩信中心满足集团统一版本升级需求，并对彩信中心信息安全的相关接口和功能进行了改造。2015年工程根据集团统一版本升级要求，新增垃圾彩信拦截功能模块，拦截各类垃圾彩信和违规彩信，有效净化了网络环境。目前彩信中心的处理能力为180条/s。
1.3 平台设备现状
彩信中心系统平台自从2008年建成之后，仅在2015年工程中增加了2台ZXA1000服务器部署垃圾彩信拦截模块，未新增其他硬件。目前，彩信平台业务处理机为Sun Fire T2000服务器，在网运行时间较长，性能条件老化，服务器在系统忙时CPU占用率约为50%，内存占用率约为50%，业务忙时内存占用率接近80%，并且系统已占用约20%的虚拟内存（硬盘空间），系统负荷较高。此外，平台中部分型号的服务器已经停产，并且无法增加CPU和内存，当设备硬件出现故障之后再去采购新的硬件也比较困难。
2 业务需求分析
根据虚拟化技术对现网系统及设备的分析研究，计划对彩信平台进行云化改造，具体的改造要求如下：
（1）将彩信业务平台全部云化，包括对所有的处理机、网络设备、存储设备等全部进行云化，云化所需计算存储和网络资源均由资源池分配。
（2）在彩信业务平台进行云化改造的过程中，彩信业务不中断，改造之后彩信平台的业务处理能力不低180条/s。
3 云化改造部署方案
3.1 方案相关简介
彩信中心的扩容改造工程采用云化部署的方案，将彩信业务平台部署在云资源池上，并将所有的处理机、网络设备、存储设备等在资源池中进行统一划分。
云化改造之后系统的硬件容量仍为180条/s，至少需要2台虚拟机设备。从N+1容灾的角度考虑，需要3台4 C 32 G的虚拟机，并加载Suse Linux11 sp3操作系统。
3.2 配置计算
3.2.1 话务模型
对关键服务器设备进行配置时，按照平均每条彩信50 KB计算，对存储容量和系统带宽配置时也按照平均50 KB计算。
忙时彩信业务量占全天彩信业务量的比例为10%，忙天彩信业务量占全月彩信业务量的比例为5%。
彩信中心系统license限制容量是180条/s，计算如下：
忙时彩信业务量：180×3 600=648 000。
忙天彩信业务量：180×3 600÷10%=648 000 0。
忙月彩信业务量：180×3 600÷10%/5%=129 600 000。
3.2.2 彩信业务存储空间
（1）当业务处理机采用N+1方式时，内容存储设备采用网络附属存储（Network Attached Storage，NAS）架构，各个业务处理服务器共享内容存储设备上的彩信消息内容。
（2）各个业务处理机的服务器与内容存储设备相连接，当需要配置多套内容存储设备时，与各服务器的连接方式采用业务处理机服务器分组式，每组连接一个内容存储设备。
（3）当有多套内容存储设备时，可以进行叠加使用，整体处理性能也按照线性增加。 内容存储采用NAS磁阵，根据工业和信息化部出台的多媒体消息业务规范，彩信消息需要在系统内有3天的存储时间。按照平均每条彩信消息的大小50 K计算，每天10 h的忙时系数，则存储3天总计需要的磁盘空间为（考虑到30%的冗余）=3×180条/s×3 600×10%×10×50 K÷1 024÷1 024÷ 0.7=133 G
3.2.3 用户数据存储
彩信数据库存储需要两部分的空间，其中，Sybase数据库需要占用一部分基本空间，用户信息占用另外一部分数据库空间。通常Sybase数据库占用的基本空间大约为40 G;每用户的开户信息大小为4 KBytes，需要的磁盘空间=（40+4 K ×用户数÷1 024÷1 024）÷0.7
当用户数为1 100万的时候，计算出磁盘空间需求为89 G。
3.2.4 计费话单存储
每一条彩信消息都会产生1条O CDR计费话单和1条T CDR计费话单（暂不考虑投递报告话单和响应报告话单）。按照每条CDR计费话单长度220 Bytes计算，话单在线保存4倍忙月，取30%空间冗余[2]，需要的话单空间=180条/s× 3 600÷10%÷5%×2×220×4÷0.7÷1 024÷ 1 024÷1 024
=304 G
3.2.5 日志存储
在日志服务器上数据的保存分为兩部分：日志文件（包括接口日志和话单日志）的保存，话单日志的入库保存。根据规范要求，对于日志查询功能所需要的存储空间，要求应满足2个月时长的查询需求。取30%空间冗余，保存2个月日志需=180条/s×3 600÷10%÷5%×3 K×2÷1 024÷1 024÷0.7=1 060 G
3.2.6 报表存储
根据规范要求，报表原始数据需要在线保存3个月，生成的所有报表数据需要在线保存24个月。
在报表呈现服务器上的数据主要是对来自多个数据源的数据进行统一处理，并将中间结果保存，空间使用情况如下。
对数据库、各类配置数据导入报表服务器，大约预留50 G[2]。一条彩信业务对应的报表原始数据大小为1 KB，每月产生的报表原始数据大小为：忙月彩信业务量×1 KB，报表处理的原始数据保留3个月，共需：
3.3 局域网宽带计算
3.3.1彩信中心Relay/Server业务处理机服务器带宽计算
彩信中心系统内部的各个网元与以太网交换机之间，网卡出口处产生流量最大的设备为彩信中心Relay/Server业务处理机，对于带宽的要求如下：
在彩信的整个流程中，每台彩信中心Relay/Server产生的流量大小为彩信的3倍，另外，包括日志流量（3 KB/条）、内部信令（1 K）、外部信令（1 K）、投递报告（2 K）、计费流量（2 K）、网管采集流量（2 KB/条），总计每条彩信业务需要的流量=3×50 KB+3 KB+1 KB+2 KB+1 KB+2 KB+2 KB=161 KB
彩信中心Relay/Server业务处理机端口上承受的总的带宽流量=180条/s×161 KB×8（bit）÷70%÷1 024=323 M
3.3.2 广域网带宽计算
广域网带宽主要需要考虑彩信中心与移动网增值业务经营许可证（Service Provider，SP）之间、与彩信网关（Multimedia Message Service Gateway，MMSG）之间、与ENUM DNS之间、与网管系统之间、与彩信终端之间的双向通信，其他细小流量均可忽略不计，因此，可取以下话务模型：
（1）广域网以太网利用率为70%。
（2）平均每条彩信的大小为50 K Byte。
（3）点对点业务比例30%，SP业务比例为70%。
（4）全网SP业务比例40%，本地SP业务比例60%。
（5）每条业务与 综合业务管理平台（Integrated Services Management Platform，ISMP），ENUM DNS之间的查询信令流量大约2 K。
3.3.3 彩信中心系统与SP之间的带宽计算
彩信中心需要对每个接收方查询一次ENUM DNS。其中，到ENUM DNS每次请求、应答的双向数据传送为0.7 KB左右（查询消息0.2 KB，响应消息0.5 KB），由于彩信中心具有将ENUM DNS查询数据本地存储功能，因此，按照更新本地数据比例为10%计算。
（1）流入带宽的计算。
流入带宽=每秒提交消息中接收方总数×每次与ENUM DNS交互应答消息大小×8×10%÷1 024÷70%
（2）流出带宽的计算。
彩信中心需要对每个收费方查询一次ISMP/DRM。其中，到ISMP/DRM每次请求、应答消息大小为1 KB左右，则彩信中心与ISMP/DRM带宽=每秒提交消息中接收方总数×每次与ISMP÷DRM交互应答消息大小×8÷1 024÷70%
3.3.7 彩信中心下发MM带宽计算
投递报告大小以2 K计算，考虑一定的冗余（假定网络带宽利用率为70%），流出防火墙的流量=180条/s×（80 K+2 K）×8÷1 024÷70%=165 Mbps
3.3.8 广域网带宽汇总
与专网连接带宽考虑70%的利用率后所需要的流入带宽（Mb/s），考虑70%的利用率流出总带宽（Mb/s）：
4 云化改造的优点 （1）规范性：严格遵守集团公司相关的业务规范和技术规范的要求，由集团进行整体规划安排和统一建设维护。
（2）开放性：系统根据开放性的原则，采用开放的接口协议和开发平台，为用户提供开放的业务接口;设备维护和业务发展不再依赖于设备厂商，方便添加增减模块和实时升级系统[3]。
（3）成本低：相比于以前传统的维护平台，云化平台所需的现网设备要更少，因此云化平台无论是建设部署，还是维护使用的成本都很低，此外，云化平台的更新周期和使用时间也都延长了，大大降低日后的改造成本。
（4）效益高：降低了短彩信业务维护对网络和系统的消耗，提升了网络效能和利用率，稳定了系统的使用负荷，经济效益显著。
（5）自主性：随着业务的不断发展，系统平台的需求也越来越大，云化系统可以自主地增加、删除各类模块及其功能，方便系统的管理和维护。另外，虽然业务在不断发展，但是总有部分系统不能完全下线，而云化系统中各模块相对独立、方便集成，可以用最小的成本与原有系统进行对接及维护。
（6）安全性：云化系统按照电信级的应用进行设计和维护，从整体系统运行的安全策略和保密机制来设计系统的软硬件架构，采用多种安全方法、安全技术，为用户提供完善的安全保障系统[4]。
5 云化之后平台网络结构
云化之后彩信中心业务平台网络结构如图2所示。
互联网应用范围越来越广泛，通信设备自身功耗增加的同时，也增加了机房空调、电源等设施的功耗，不但提高了运营商初期的网络建设成本，而且提高了运营商日后的维护运营成本。将传统业务平台进行虚拟化之后，不再单独新增硬件设备，能有效降低能耗，节省机房空间与资源，绿色环保。
此外，云化改造之后，一方面，节约了系统资源和运维成本;另一方面，也提升了短彩信业务的效能。通过精细化管理提高综合业务的接入能力和维护能力，为网络精确运营和市场精确营销提供了服务与保障。
6 网络安全与信息安全要求
（1）有DCN网地址或者外网IP地址的系统应该纳入到网络安全和信息安全管理中，安全管理部门提供资产管理、主机合规扫描、漏洞扫描、配置核查等功能模块，要对系统进行定期检查及安全评估。
（2）所有平台及其系统（系统资源和应用资源）的网络设备配置应满足基线配置规范。系统的端口和服务等基础安全信息须进行备案，对于必须的端口要对其进行应用软件和功能用途的登记和报备，严禁开放非必要端口的开放。对操作系统、网络设备、数据库等进行安全基线配置，包括安全审计管理、系统账号管理、密码复杂度策略、关闭危险服务等，确保系统配置及使用的安全性[5]。
（3）最小化服务端口管理，对于所有系统的网络服务设置，必须遵循最小化服务原则，关闭不需要服务，减小互联网暴露面，对于危险端口，严禁对外网开放。对于必须开启的网络服务，要通过配置策略限制远程主机源地址。
（4）将所有业务平台及其系统（系统资源和应用资源）纳入集中监控系统，及时发现系统告警及故障等。通过部署流量检测系统，建立异常流量的监控及预警，防止流量攻击。
（5）安装专业的防病毒软件，及时更新病毒库，定期对系统做全面的病毒扫描，及时发现并消灭病毒。建议设置为每天自动更新病毒库，以及每周对系统做全面的病毒扫描。
（6）系统的物理安全，系统线缆布放整齐合理，符合公司机房规范。各种标签齐全，标签内容应该打印，不能手写;新建机架的配电模块应使用空气开关，严禁在集装架内随意串接、复接电源插线板或设备等。
（7）双路由双节点，系统重要传输节点要有双路由、双节点备份，满足灾难发生后数据恢复的要求，并且必须满足可以在规定时间内完成倒换转接业务的要求。
（8）系统信息安全，网站接入系统时要严格落实“先备案 后接入”的管理规定，严禁自用、自营、合作网站出现未备案先接入或备案信息不准的现象。对外发布内容时要严格落实“先审核 后发布”的管理规定，建立定期检查制度，避免不良信息的产生。
7 结语
随着QQ、微信等各种社交软件的不断出现，运营商以前传统的短彩信业务渐渐萎缩，再加上国家“降本增效”“提速降费”等政策性的压力，运营商的利润也被不断地压缩，唯有减少投入、节约成本才能可持续的发展。
将传统业务平台进行虚拟化之后，既能节约系统的运维成本，又能提高短彩信业务的效能。创新了网络支撑业务的思路，完善了业务系统平台的框架，在提高網络质量的同时也提高了用户的满意度。
[参考文献]
[1]邓云松.海南电信中兴ITV2.0平台升级到3.0平台部署[J].电脑知识与技术，2016（15）：33-36.
[2]孙旻姝.关于新建多媒体消息业务网关系统方案的研究[D].长春：吉林大学，2010.
[3]陈锦娟.宽带多媒体终端管理和业务发放平台[D].广州：华南理工大学，2012.
[4]黄根华，钟声伟.分布式存储系统在通信运营商云计算资源池的应用研究[J].通讯世界，2017（16）：48-49.
[5]黄筱芬.重庆银行短信业务系统的设计与实现[D].成都：电子科技大学，2014.
Abstract：In this paper， a research method for the transformation of the business platform is proposed. The present situation of the system and the business requirement are analyzed， and the cloud-based transformation scheme is designed， and the cloud-based network structure is constructed， and the virtualization of the short-message service platform is realized. At present， the traditional short multimedia message service of the operator is gradually shrinking， and the number and profit of the service are obviously reduced. After the transformation， the cloud-based platform can improve the network quality and the resource utilization ratio， reduce the production investment and the maintenance cost， and achieve the purpose of reducing the cost and increasing efficiency.
Key words：virtualization; short and multimedia message service; cost reduction and efficiency increase; cloud-based platform