摘要：现在OSS已经成为整个通信网的重要组成部分。随着更多网管系统、计费系统等核心OSS系统投入运营，在人们关注的业务功能得以实现的同时，支撑系统的性能问题逐渐暴露出来。本文介绍了国内支撑系统的建设现状及其性能评价，并给出了一些实用的性能调优措施。

1. 概述



运营支撑系统的建设是通信领域中的一个重要课题。运营支撑系统是指为保证通信运营企业能够高效稳定的运转，而建立起来的一系列包括软硬件支撑环境的辅助系统。支撑系统的建设经历了一个从无到有的阶段，最初的目的只是为了解决生产作业的自动化处理，建设的支撑系统也往往局限于专业的网管系统和计费处理等核心系统。而现在，电信的运营企业更加关注于从企业整体的流程的角度来规划和构建其支撑系统，希望将整个生产经营和运维管理的流程纳入支撑系统的管理。于是，很多按照职能划分的，大大小小的系统陆续建立起来。同时，由于业务的发展，原先建成的诸多核心系统也经过不断的扩容和改造升级，业务管理的范围越来越大，功能也越来越强。但就在人们关注其业务管理得以有效开展的同时，一个新的矛盾产生了，那就是，一些系统由于数据量不断增大，以及系统间频繁交互而导致了严重的性能问题。

图一

2. 支撑系统介绍

支撑系统怎么划分和建设，国际上没有一个固定的模式。一般意义上说，很多运营商在建设时参考的是TOM 模型。如图一所示。它从流程的角度描述了业务开通、业务保障和业务计量等三个方面的过程，又从纵向的角度分成网络和系统管理、服务发展和运营、客户关怀等层面来描述。

在中国，大多数的通信运营企业的支撑系统一般包含几个大的部分：即专业网管系统、资源管理系统、计费帐务系统、业务提供系统、经营决策系统等几大类。

这几类的支撑系统，架构上是符合TMN的思想。我们知道，TMN分成四层，从下往上依次为网元管理层、网络管理层、业务管理层和经营管理层。上述已经建成的支撑系统，总体上网管类的系统和资源类的系统对应于TMN的网元管理层和网络管理层；计费帐务类系统和业务提供类系统对应于TMN的业务管理层；经营决策类系统对应于TMN的经营管理层。一般而言，业务管理层的系统由于是实时的业务系统，相对来说对性能的要求高一些，效率问题比较关键；而网管类系统和经营类系统，在报表处理和报表分析方面，由于数据量比较大，也存在效率问题。

3. 系统的集成与分析

一个完整的支撑系统包括几个方面：主机、网络、数据库、应用软件、系统软件、终端、与其它系统的接口以及系统中数据。从理论上讲，这些方面的因素都有可能成为支撑系统性能的瓶颈。

主机系统是影响性能的主要因素之一。电信的支撑系统，绝大多数是采用小型机或高挡服务器做为服务器，当然也有极少数的大机的案例。这里我们只介绍比较常见的小型机系统。一般而言，象计费帐务和业务提供这样比较大的应用，对主机的处理能力都有量化的要求。通常需要按照所处理事务的规模来计算TPMC值，并根据TPMC值配置相应档次的小型机。否则将对支撑系统的处理能力和处理时限现成较大的障碍。

网络的选择和配置也有可能是影响整个系统性能的因素之一。现在的很多系统都是以本地网为单位来建设的，更有一些系统是按照大区或省集中的模式建设的。这样，大数量在异地的传送和处理对网络就会有带宽的要求。如果没有适当的冗余，在大笔业务突发的情况下，就会产生拥塞。

数据库在支撑系统中的使用已经非常普遍，但多数系统中的数据库并没有充分的优化。数据库的性能调优和参数调整，以及它的索引策略等已经越来越引起厂商和最终用户的重视，但到目前为止，对此还没有定量的评估，还处在经验调优的阶段。

应用软件的设计质量和开发质量是影响系统性能的最重要因素之一。从设计上讲，业务功能模块划分的粒度、事务处理的描述、数据库表的物理设计、热表查询策略、以及数据库约束基制等都是影响系统效率的因素。从开发上讲，算法的选择，SOL语句的使用等也都会对影响到应用的时延。

还有一个因素就是系统间的互连。单一的支撑系统运转时没有效率问题，在与其它系统连接上以后，可能就不一样了。这取决于接口设计的是否合理，还有就是系统间的相互调用，以及数据的相互锁定，都会以前的模型变得复杂，从而带来性能上的问题。

当然，系统软件的选择和配置，终端的使用，都有可能影响整体的效率，但从实际情况看，这些还都不是主要的因素。

4. 不同应用的特点及策略

前面所述，是从支撑系统的一般意义上讲的。对于某一类特定的支撑系统，因其应用特点和处理方式不尽相同，相应的性能解决方案的策略也有所不同。

例如，对于计费帐务系统来说，主要的性能压力来自两个方面。一个是出帐的时候，一个是前台收费。出帐可以用两种方式，一种是基于文件的方式，速度相对要快一些；还有一种是基于数据库的方式，速度虽不如前一种快，但安全性比较高。在每月的收费日，收费前台终端往往带来较大的压力，这是因为大数据量并发导致的性能降低。对于大数量并发的情况，一个比较好的方法是采用B/A/S或C/A/S的三层的应用体系结构。在三层结构中，由于中间件软件和应用服务器的引入，可以将表现逻辑放在瘦的客户端，将业务逻辑放在应用服务器，而数据逻辑则放在数据库服务器端。这样大数据量的访问只与中间层的应用服务器交互，而不会影响到数据库服务器，加之中间件软件提供的负载均衡的机制，使得效率得到了提升。

而对于象营业处理这样的业务处理系统，低性能主要是因为多种不同的业务处理针对有限几张热表频繁操作导致的。以97系统而言，对于规模比较大C3局，往往表现出营业窗口受理定单慢，核配线路资源速度慢，定单处理过程慢，或是报表的统计慢。这是因为在以上的几类操作中，往往是针对同一张表进行的，（而之所以是几类数据放在同一张表内存储主要则是考虑数据一致性的问题）在数据量比较大，并且同时频繁操作的时候，就会出现相互锁定的现象。对于这样的应用，可以尝试几种解决方法。方法一是可以重新考虑热表的物理存储，使其负载均匀分布在物理设备中；方法二是可以考虑数据的一定程度的冗余存储，但同时需要考虑好空间成本和数据的一致性；方法三是适当减少数据之间的约束，因为在数据库的约束机制比较多的时候，系统会牺牲大量时间做数据合法性检查，从而降低效率；方法四是建立并优化索引，这在实践中是非常有效的一种方法；方法五是优化SQL语句，使用高效代码。不过需要说明的是，以上的方法只是改善系统性能的可能的方法，并不是调优工作的充分条件。通过应用软件调优和通过数据库、网络以及主机系统的调优都是有限度的，而实际效率问题的解决则是这几方面因素的折中。当然，在应用复杂到一定程度，可能上述的方法都没有办法解决，这时就需要考虑根据需求分析，重新规划和设计，必要时应考虑将系统拆分实施。

　

5. 结束语

   动感短信、闪烁图片，让您的手机个性飞扬！
      15秒快速订短信 精彩资讯尽在“掌”握