电信系统架构方案

国内软件业曾有人对行业性软件进行划分，在几个较大的行业中，排行前几位的分别是：通信、电力、金融……

但从对技术的要求与和安全性的要求上来说，通信行业的计费和金融行业的交易都是并称的。因此在通信行业软件形成之初，计费就成为了通信行业的核心软件，能否有实力作计费软件成为在行业中是否具有实力的标志。于是也就形成了中国通信行业著名的“九七”工程！这是完成电信行业核心业务层面的信息化工程。

继“九七”工程之后，2001年，中国的各电信公司根据国外电信公司的信息化进程和经验，总结提出要建立中国电信公司的运营支撑系统，这个系统是基于“九七”工程外围的运营支撑业务构建起来的，如果说“九七”工程是心脏，那么运营支撑系统就是四肢！心脏是为了提供肌体的动力，四肢才可以通过各种形式来获取利益，使心脏能继续生存下去。运营支撑系统在中国电信集团公司被称为“OSS”系统，全称是“Operation Support System”，在中国移动通信集团称为“BOSS”系统，全称是“Business and Operation Support System”。

在电信集团提出构建运营支撑系统的同时，各电信分公司还在筹划构建符合自己特点的ERP系统，与此同时，基于运营支撑系统之外的各种行业业务系统也开始了开发与规划。

电信行业软件历程

一、九七工程

九七工程是中国通信行业软件最初的形象。实际上在实施九七工程的时候，中国的通信行业基本上还是一家垄断的状态，那就是中国电信！

九七工程主要解决了电信行业最迫切需要解决的交换、计费、帐务、经营等最关键的业务过程。这些业务要求实时性非常强、对准确性的要求也非常高，因为系统的每一个数据都关系到电信的直接收入。

一些国内的软件公司借着这股春风发展了起来，也有一些公司从此开始涉足软件行业。

从技术和行业的应用成熟度来说，当时进行这项工程的条件是不具备的，但是，这项工程的实施却是必须的。所以，在实施这个工程的过程中，不少系统都是多次返工，虽然达不到实际意义上的7×24，但是至少可以得到比其他方式更精确的数据信息，这也就是这项工程的一大意义了。因此，在此后，尽管1997 年早成为过去，但是九七工程这个名词却一直被沿用下来，以代表这个特殊的意义——中国电信行业的第一次信息化。

二、OSS/BOSS系统

2001年，中国移动开始规划“BOSS”系统，2002年各省移动公司分别制定了自己的“BOSS”系统的技术规范和业务规范，但是，离真正实施还有一段时间，因为中国移动还需要进行统一的规划。

在中国移动制定规范的同时，中国电信集团也不甘落后，也开始制定自己的“OSS”系统的规范和实施规划，并在其上海研究院进行相关的试验。不过，因为其工作量过大，按照初步的估计，一个省级电信公司要实现“OSS”系统的规划，至少需要五年，投入至少有3到5亿以上的资金。按照这样的估算，中国电信集团要实现全国的“OSS”规划至少就需要90亿以上的资金投入，所以，一直到现在，中国电信集团的“OSS”系统还仍然无法进入实施阶段。

其他的电信运营商，诸如中国联通、中国网通、中国铁通等公司也都在纷纷筹划自己的相关系统。

技术方案概述

一、B/S结构

随着软件技术和网络的发展，各种行业软件业几乎都在进行着B/S与C/S结构的争论和演化。虽然大家都认为B/S结构更先进一些，但是，在某些特定的行业和业务中，C/S结构的系统仍然有着非常重要的地位和不可替代的作用。

加上B/S结构产品的开发难度要远大于C/S结构的系统，调试和测试工作都要比C/S结构的产品复杂得多。在此条件下，基于成本和效益的各种方案对此有很大的影响。

经过长时间的研究和探讨，通信行业的产品在体系结构上基本达成一致：在业务操作实现领域采用B/S结构，在某些特殊的功能实现上适当地采用C/S结构。

二、多层结构选择的必然

提到体系架构的选择，电信行业的大多数业务对系统的实时性、稳定性要求都非常高，因此电信行业软件业就成了所有软件中开发难度最大的一种。

目前国际上流行的两种软件体系，都采用了多层体系来进行大中型系统和关键系统的构架。

电信行业项目的实施中，也大都采用了中间件进行整个体系的构架，在J2EE体系成型之前，大多数系统都采用C/C++进行开发，一些关键的业务实现则采用 Corba体系。随着Corba与J2EE的融合，两大对立阵营的.Net与J2EE逐渐成型，电信领域的大型系统大部分都采用了基于Java的多层体系架构。如图2所示：

Web服务器：在Web服务器上，部署的是系统的表现层，用户通过浏览器进行浏览和信息交换。

应用服务器：主要提供组件的生存支撑环境，提供业务逻辑搭建的基础。

三、体系架构的选择

目前流行的两大体系是.Net和J2EE。

由于微软的产品大都稳定性、可靠性较差，虽然上手非常容易，但这恰恰不能达到电信行业对于可靠性的基本要求，所以，从体系到产品，微软都被全部屏蔽于行业重点业务的实现之外。

J2EE体系得到了较多大型厂商的支持，同时融合了Corba对语言无关性的特征（虽然其真正的可用还需要一段时间）以及其他优势，目前已经得到了绝大多数电信公司的认可，在通信行业领域内的开发商和集成商也都纷纷附和。

四、语言的选择

对于语言的选择，新的电信行业软件做了非常慎重的考虑，既要保证效率和实时性，还要能提供足够强大的稳定性，在J2EE推出之前，包括国外的电信行业项目也大都采用C/C++开发，但是，因为C++本身所固有的问题——内存泄漏，所以，系统的稳定性总是很难得到保障。

Java 出现后，由于Java自身对C++的补充，稳定性方面得到了极大的提高。但，同时也发生了一个问题：因为Java需要运行在Java虚拟机上，经过这样一次解析后，其运行效率和速度都受到了很大的影响，当进行大数据量查询和统计分析的时候，Java的速度问题就很明显了。因此，在一些特殊的功能实现方面，又需要使用C/C++来进行速度的提升。

五、最终决定

通过上面的描述，我们已经基本上把电信行业软件开发的体系架构表述清楚了。图3是笔者早先完成的一个基于J2EE架构的产品开发技术框架，仅供参考：



1 J2EE实现整体设计原则与思想

该系统的设计，采用了组件化的设计思想，同时根据项目的特点，对J2EE的实现架构进行了适当的改进，使之能更适应电信目前的要求和今后扩展的需要。

系统采用J2EE体系架构进行整体结构设计，这也是国际上流行的解决大型企业应用及关键性业务应用的优秀技术。

2 功能设计

通过J2EE技术框架实现电信行业系统的所有功能。

3 体系结构

该系统必须采用多层体系结构。建议采用如图3所示的六层体系进行架构。

4 构架特点

下面按照数据库层、数据管理层、事务处理层、会话处理层、逻辑控制层、前端表现层的顺序对以上各层功能和特点进行详细的描述：

（1）数据库层

选用某种数据库，提供数据存储服务，同时，还需要提供灾难备份和恢复功能。所以，目前，电信行业内部对数据库的基本要求如下：

①支持ANSI/ISO SQL-89、ANSI/ISO SQL-92标准；

②支持中文汉字内码，符合双字节编码；

③支持主流厂商的硬件平台及操作系统平台；

④数据库系统应具有良好的伸缩性；

⑤支持主流的网络协议（如：TCP/IP、IPX/SPX、NETBIOS及混合协议）；

⑥具有良好的开放性，支持异种数据库的互访：

实现对文件数据和桌面数据库数据的访问；

实现对大型异种数据库的访问；

能够将原有异种数据库向本数据库无损失移植；

实现和高级语言互联的能力；

支持XA、ODBC 3.0、X/OpenCLI、JDBC等工业标准；

支持分布式事务及两阶段提交功能。

⑦具有支持并行操作所需的技术（如多服务器协同技术、事务处理的完整性控制技术等）；

⑧支持网络上同构或异构数据库之间数据的冗余性复制；具有多种复制功能模块（如实时复制、定时复制、双向复制、多点方式下的N向复制、复制转发，复制范围可整表复制或表中部分行复制或修改单元复制）；

⑨支持联机事务处理（OLTP），支持决策支持的建立，要求能够实现数据的快速装载、高效的并发处理和交互式查询；

⑩支持C2或以上级安全标准、多级安全控制；

支持数据库存储加密及相应冗余控制；

提供Web服务接口模块，对客户端输出协议支持HTTP2.0、SSL等；

支持联机存储和备份功能（如磁带方式、光盘方式）；

应具有强的容错能力、错误恢复能力、错误记录及预警能力；

数据库、表大小等技术参数可灵活设置，支持对多媒体数据及大数据量处理的技术需求；

应可以避免数据库死锁的出现，一旦死锁能够自动解锁；

开发工具易使用、开发效率高、维护方便；

支持多种CASE工具。

上面对数据库的各个方面都提出了要求，在电信行业内部，目前对于中小型非关键业务项目采用MS SQL Server 2000的比较多，大型项目基本上都避开微软的体系和产品，而采用Oracle和DB2作为系统的数据库选择。

（2）数据管理层

这是整个系统中唯一进行数据访问、数据控制和数据安全校验的部分，是系统中唯一与数据库交互的部分，这也从另一个层面提高了数据安全性。

另外，由于有些电信行业系统的分布地域比较广，采用这种方式有利于分布式数据的有效管理，可提高数据的利用率和有效性。

优点：专用的数据管理层屏蔽了系统的其他部分对系统数据库的直接访问，增加了系统数据的隐蔽性，提高安全性和可管理性。

具体实现的时候，可尽量采用应用服务器所提供的功能，采用容器管理实体Bean（也就是CMP Entity Bean）来开发数据管理层，这样可以降低开发人员的开发工作量，提高效率，提高组件的可重用性。而且，当数据库发生变化的时候，不需要做大量的编码，通过应用服务器本身就可以直接对这种变化做出相应的反应。

注：对于CMP和BMP的使用的基本观点是这样：对于完全新建的系统，也就是说没有老系统的存在，或者可以忽略老系统的数据库设计方式可能对新系统的数据库设计造成的影响的时候，建议采用CMP的方式来开发Entity Bean，这样就可以完全采用OO的方式从需求开始到分析设计和编码实现都依托于OO的思想进行整体的规划，系统实现也会相对比较合理。而对于不符合上述情况的系统，一般在前端流程实现和业务逻辑实现中可以考虑采用OO的过程，在数据库管理层的实现中需要考虑与前端的配合外，数据库管理层的设计和数据库层的设计建议采用面向数据的过程进行规划，否则，不仅仅用户可能会对工期不满，开发团队也将面临着数据抽取与转换的难题。

（3）事务处理层

系统中进行事务处理的主要部分。这部分将根据具体的业务逻辑和实现进行业务控制和事务处理。在业务进行变化的时候，不影响系统的其他部分。

由于有些规则和制度会因为时间和各种情况有一定的变化，因此很多业务的具体处理流程和过程都需要修改，这样的修改如果放在其他部分，就有可能影响到很多其他业务的正常开展。