浪潮BOSS系统的组成及技术体系研讨

HYPERLINK浪潮BOSS系统的组成及技术体系

..........................................................................摘要本文简要介绍浪潮BOSS系统的组成和主要采用的技术，如大型数据库技术、中间件技术、并行处理技术、IPC技术、组件技术、实时数据库技术、SAN技术等

关键词BOSS中间件三层结构实时数据库组件SAN

1引言

近几年，移动通信业取得了飞速的发展，各种新业务层出不穷，市场竞争剧烈，随着加入WTO的临近，这种竞争必然会进入白热化状态，可是现存的分散的计费系统、业务系统、帐务系统等，无论从功能和性能上都难以适应市场的变化。为了适应市场的不断发展和激烈竞争，提高服务水平和服务质量，增强对新业务的支撑能力和反应速度，满足客户需求的不断变化和发展，中国移动通信公司在今年上半年组织各省公司、各系统集成商联合制订规定了中国移动BOSS系统（Business&OperationSupportSystem，业务运营支撑系统）的业务规范和技术规范。

中国移动BOSS系统从功能上涵盖了计费、结算、帐务、业务及客服等方面，规范指出BOSS系统的建设应作为一个有机整体进行统筹的规划和考虑，对各种业务功能进行集中、统一的规划和整合，使中国移动的BOSS系统成为一体化的、信息资源充分共享的支撑系统。

LCBOSS是浪潮齐鲁软件公司集多年在通信领域做计费、结算、营业、帐务、客服等系统经验的基础上研发成功的。LCBOSSV1.0.0采用了多项计算机领域最新技术，完全满足中国移动制定的BOSS系统规范，符合中国移动集团公司的"三个特征、两个能力、一个综合"要求。本文拟就LCBOSS的组成和使用的主要技术展开介绍。

2LCBOSS系统架构

LCBOSSV1.0.0是基于数据中心的，三层/多层架构体系的移动业务支撑系统。逻辑上BOSS系统分为基于数据中心的数据层、业务逻辑层、表示接入层，见图1：

图1BOSS系统逻辑结构

2.1数据层

数据层几乎含盖了BOSS系统的所有数据。数据层中数据是分类存储的，大致可分为计费详单、统计详单、计费基础数据、客户资料、资源管理数据、营业网点资料、帐务数据、结算数据、1860/1861动态数据、客户交易数据、反欺诈数据、操作日志、统计分析数据、配置管理数据、决策支持数据、数据仓库等。这些数据是统一规划的、对象命名统一、数据是冗余最小、集中存放、高度安全可靠的，在其上面可以开展各种业务，它们基本上与具体应用无关，组成了BOSS系统的核心--数据中心，见图2。数据中心的具体存储方式和载体，可采用SAN（StorageAreaNetwork）技术、分布式数据库技术等。数据中心的硬件可支持IBM、HP、SUN、COMPAQ等知名公司的主流Unix主机系统和存储设备，数据中心中能方便地增加主机和存储设备，且设备的型号和生产厂家不受限制。在大型数据库的选型上，数据中心能够支持Oracle、Sybase、Informix、Db2、SqlServer等大型关系（对象）型数据库；数据中心中选用的数据库即可是其中的一种数据库，也可以多种数据库混合使用；即单事例数据库、并行数据库、数据库的混合。从维护角度考虑，数据中心选用的主机和数据库技术型号不宜太多，否则维护起来较为困难。

图2数据中心在图2中可见，每类数据并不是一定要建一套数据库；一类或几类数据可公用一套数据库，通过表空间和属主进行区分；一类数据可以存放于几个数据库中，但尽可能使用一套数据库以方便操作；一类数据在一个节点中无法完成处理时，推荐使用并行数据库（如OracleOPS）或按某种规则将数据分布到多个数据库中。

不同类型的数据在阵列上使用的RAID级别也可不一样，如计费详单数据不仅要求有快的写速度（入库、实时累计、预付费处理），而且要求快的读速度（实时累计、集中查询），存储期长，这时可选用RAID10(RAID0+1);而对于统计详单，则其主要操作为读，存储期相对较短（1~2个月），另外为节省投资考虑，可选用RAID5。

2.2业务逻辑层

业务逻辑层，是基于数据中心的BOSS系统的各种业务实体存在的层面。在业务层，逻辑上分为计费系统、营业系统、帐务系统、结算系统、大客户管理系统、信用度管理系统、客服系统、统计系统、综合查询系统、接口系统、反欺诈系统、催费系统、决策支持系统等，这些业务系统基于数据中心，采用面向对象的思想和组件化开发。所有这些系统逻辑上是相对独立的，它们或它们的一部分可分布于一台或多台主机上，用户可选择其中的一种或几种，也可修改或增加新的业务系统，来完善自己的系统。2.3表示接入层

在接入层，用户或操作者可通过PC机、手机终端、手持电脑等通过语音、Web/Wap界面、Gui界面等进行接入，根据权限和工作分工来完成不同业务和操作。整个BOSS系统的三层结构如图3所示：

图3BOSS系统的三层结构

2.4BOSS子系统的划分

图4BOSS子系统划分

BOSS系统包括以上子系统，逻辑上各子系统相互独立。

采集子系统负责各种话单的采集（含出访话单）；

计费子系统负责话单预处理，各种话单、各种品牌、各种用户的计费，处理话单级的各种优惠，计费详单入库，错单、重单处理，该子系统还包括预付费用户实时扣费、高额处理、与用户级有关的累计、预付费数据下发、计费稽核、内存影像实时监控等，其话单按打电话时间按号段和月份分表存放；

帐务子系统负责手机用户的出帐、收费、地市间业务结算、省公司、地市公司费用平衡、代收结算等；

统计子系统包括提供各种报表所需的基础统计数据，包括部分结算数据，其话单根据计费系统的话单入库时间按号段和月份分表存放；

结算子系统主要处理省际漫游结算、国际漫游结算、省际漫游结算地市分摊、国际漫游结算地市分摊、省内漫游结算、漫游结算对帐、与公网结算等；

省中心前台Gui/Web界面提供管理、操作界面，以图形界面和Web界面方式提供系统管理、用户管理、参数管理，详单、报表等的查询、打印等功能，它访问计费、帐务、结算、统计等系统的数据；

营业子系统主要负责开户、销户、卡源管理、号源管理、收费等各种功能；

联机指令子系统负责实时停开机、与HLR、AUC等接口；

内部数据接口负责计费子系统与统计子系统和结算子系统的计费后详单转发、计费子系统与营业和客服系统接口、与集团公司帐务中心的接口；

流水号发生器子系统主要用来生成营业子系统、帐务子系统、客服子系统等所需要的业务流水号

外部数据接口负责与银行代收费系统、缴费卡系统、短信中心、OA系统、MIS、财务系统、INTERNET服务、IP认证计费系统、ISP、ASP运营商、语音信箱平台、WAP平台、其它增值业务平台;

系统管理与监控负责操作系统、数据库、应用程序、网络、主机、存储设备等的管理与监控；

客服子系统负责通过CTI、Internet、传真等技术手段等进行业务受理、查询服务、客户交费、推介咨询、申告投诉、客户建议、终端维修、信息发布和预约服务等。2.5系统网络示意图

图5BOSS系统网络示意图

3LCBOSS系统关键技术介绍

3.1大型关系（对象）数据库技术3.1.1数据库结构选择

根据用户的数据量和硬件选择情况，数据库结构可分以下几种（以Oracle举例，Informix、Sybase、DB2等数据库类似）。

3.1.1.1单事例数据库系统

在这种配置下，服务器上只运行一个数据库事例，各个数据库进程共用共享内存和存储系统，其处理能力和扩充能力受运行该数据库事例的服务器性能限制，用户可通过增加CPU的个数、增加内存等来增加数据库的能力，但这些资源的扩充毕竟是有限的，当服务器达到最大能力无法扩充时，只能通过更换更大的计算机来解决，原有投资不易得到保护，这种方式适合于数据量较小的中小省份。这种方式的好处是：应用软件容易设计，管理起来方便，对中小数据量效率较高。在一期和二期的计费系统中，许多省使用的是这种模式（图6）。

图6单事例数据库系统

3.1.1.2多事例并行数据库系统

这种方式由多个节点（每个节点可简单看作一台服务器）组成，每个节点上只运行一个数据库事例，每个事例在自己的节点内使用相同的共享内存，所有的数据库事例共享一套存储系统，其处理能力和扩充能力都较强，用户可通过增加节点数的方式来增加数据库的能力，原有投资能得到较好保护，这种方式适合于数据量较大的大中省份。这种方式的好处是：处理能力强、易扩充、单点故障时其数据可通过其它节点来存取、管理较方便、投资保护好，可进一步开发数据仓库进行数据挖掘等。其不好的地方是：应用软件及相应的表结构设计复杂，设计不好、各节点间的锁冲突使性能很难得到应有发挥，需要相应的硬件（如IBMSP等）和软件（HACMP等）来支持。在三期设计中，山东等省份采用了这种模式（图7）。

图7多事例并行数据库系统

3.1.1.3分布式数据库系统

这种方式与以上两种方式对比最大的区别是系统有多个数据库组成，每个节点上有一个数据库，数据库间通过一定的网络协议进行通讯。此种模式的好处是：处理能力强、易扩充、单点故障不影响其它数据库、各节点上业务安排较灵活、能够发挥硬件的最大处理能力，投资保护好，各节点机型可不一样甚至使用异种数据库等。其不利的地方是：由于数据分散到多个数据库中，使用起来不方便，使应用软件设计变得复杂，管理起来麻烦，对整个系统进行统计时，各节点间的通讯可能会成为瓶颈。这种方式适合于数据量较大的大中省份（图8）。

图8分布式数据库系统3.1.1.4混合型分布式数据库系统

混合型分布式数据库系统可看作是分布式数据库系统的特例，在其节点中既有单事例的数据库，也有多事例的并行数据库，它吸收了以上三种方式的优缺点，使设计更加灵活，应用软件设计较麻烦。它适合于数据量大的大中型省份，一般用在日后可能增加新业务，使数据量剧增和运行模式改变的系统中，系统扩容改造时可考虑它，BOSS系统建议采用这种方式（图9）。

图9混合型分布式数据库系统浪潮BOSS系统在设计时考虑了以上模式，支持以上四种形式的数据库系统，数据库管理系统可选用Oracle、Informix、Sybase、DB2等。

3.1.2数据库设计一般要点

数据库结构的设计是否合理，对整个系统的性能和功能有着非常大的影响，因此必须予以充分考虑。设计原则包括以下几点：

在数据库空间分配上（以oracle数据库为例，其它数据库类似）：

实现入库服务器间的负载平衡；

减少数据库之间的I/O传输；

减少对硬盘读写的I/O瓶颈；

尽可能将各类表分开；

数据和索引分开；

回滚段单独存放；

联机日志文件(onlineRedoLogfiles)在单独的盘上;

归档日志文件(ArchiveRedoLogfiles)在单独的盘上;

临时表空间在单独的盘上;

在硬件资源利用上：

尽可能充分使用多CPU，并行化作业；

尽可能使用内存等高速资源进行通信，避免磁盘I/O

在软件设计上：

尽可能使用多进程、多线程机制，并行化运行；

使用共享内存机制进行传输；

避免锁冲突3.1.3数据库管理系统产品选择

当前BOSS系统中选用的数据库管理系统产品主要是Oracle、Informix、Sybase三大数据库，在国内都有一定用户。这三种产品各有千秋，都有较强的数据处理能力，有的应用工具较全易维护，有的Web开发能力强，用户可选择其中的一种，并行环境中选Oracle的较多。由于Oracle在技术上相对更有优势，国内选择Oracle的移动公司越来越多。

由于BOSS系统的数据量很大，常常多达几个T或几十个T，建议采用多套数据库，即采用MSMD(多服务器多数据库)的分布式数据库方式，这种方式性能较好、管理风险较小。

3.2中间件技术

中间件技术是BOSS系统实现集中和三层方式的核心技术，BOSS系统中使用的中间件包括两类三种：一类是传输中间件或称为消息中间件，以IBMMQSeries和BEATuxedo/Q(MessageQ)为代表；另一类是交易中间件，分为两种：一种为以C/C++语言为基础，以BEATuxedo/T和IBMCics为代表的传统交易中间件，另一种为以J2EEJava和XML、HTML技术为依托，以BEAWeblogic、IBMWebsphere和OracleAS为代表的Web应用中间件。

中间件有一些共同的特性，它解决了与硬件和数据库的接口问题，屏蔽了网络底层复杂繁琐的编程特性，应用的部署比较方便，使设计和编码人员可以专注于具体业务的实施，提高了编码的速度，减少了开发的难度，从而软件质量有所提高。

浪潮有多年的中间件开发和使用经验，开发了BOSS专用的传输中间件和交易中间件。

3.2.1传输中间件

传输中间件在BOSS系统中主要话单采集中的传输，计费系统中不同节点或不同模块间的传输。传输中间件使用示意图图10如下：

图10中间件的使用

以上图10可以看出，节点一要把数据传到节点二，开发工作做的是发送端应用尽管把数据打成消息包放到传输队列中，而接收端只到接收队列中取就是了。传输中间件会把数据从节点一安全传到节点二，节点一到节点二间的网络协议、网络停断、操作系统不同等全由中间件自身来处理。

3.2.2交易中间件

交易中间件在应用中起着业务代理作用，在BOSS系统中主要用在营业、客服系统和大客户量的查询、交易中，计费系统中也可采用交易中间件。

结合3.1.1介绍的几种数据库配置方式，交易中间件应用体系结构如图11所示：

图11交易中间件应用体系结构

我们的业务主要集中在交易中间件的服务中，它使开发、升级、维护非常方便。

3.3组件和插件技术

BOSS系统庞大、业务增加和变化较快，将一些业务体和技术体做成组件方式，部分组件可做成插件形式，系统的灵活性和可管理行就会有很大提高。

组件技术几乎可用于BOSS的各业务子系统中。

3.4并行处理流程

并行处理技术和架构能够充分利用多机多CPU的处理能力，使系统的扩展性和实时相应能力增强。计费子系统的并行处理架构如图12所示：

图12计费子系统的并行处理架构

3.5IPC技术

磁盘子系统是计算机中最慢的设备之一，计费系统中超大数据量又必然要与硬盘打交道，因此硬盘常常成为制约系统性能的瓶颈。我们采用了以共享内存为主的进程间通信方式，兼用消息队列、Socket、管道（pipe）等IPC机制，用信号灯机制协调通讯的同步及一致性，进程使用的基础数据表等一次性地从数据库中加载到共享内存中，避免频繁访问数据库。这样在一台计算机内部，除了进入计费系统的原始话单文件、日志文件和需传出的文件外，尽可能不与硬盘打交道，部分计算机间可用Socket网络方式直接通信，这样大大提高了计费速度，我们在预处理、划价、报表累计、实时累计、预付费、反欺诈等子系统均采用了这种方式。

3.6专用实时数据库技术

传统的通用大型关系型数据库（oracle、Informix、Sybase、db2等）是基于硬存储设备（硬盘、磁盘阵列等）的，基于一定的接口标准（如SQL92等），使用范围较广，其不少处理也在内存中进行，但数据主要存储在硬存储设备上，其处理速度和实时性有一定的限制。而这里提出的专用实时数据库，是其借鉴了通用数据库的一些管理思想，有数据结构、表、索引、日志等，可以对表中的数据进行查询、插入、更改、删除等操作，保证异常情况下数据的一致性和事物的完整性，但它的几乎所有处理都在内存中进行，速度极快，实时性很强，它可以通过与通用数据库的接口，将数据写入到数据库中，或从数据库读到内存中，它的使用范围较窄，是专用的，这里只谈专为浪潮移动实时计费结算系统设计的专用实时数据库。浪潮BOSS专用实时数据库包括以下模块：

"实时数据库的RTServer进程

IPC资源的建立、内存数据结构的建立、数据的调度、进程的加载。

"实时数据库的RTLoad进程

完成数据库的数据向内存中加载。

"实时数据库的RTAuth进程

负责实时数据库的连接认证。

"实时数据库的RTDBW进程

将变化的数据刷新到硬存储介质中。

"实时数据库的RTTI进程

记录实时数据库的事务信息，以便故障时保障事务的完整性。

"实时数据库的RTLOG进程

记录数据库的日志信息。

"实时数据库的RTRecover进程

负责数据库事务的回退。

"实时数据库的RTI进程

负责其它应用访问实时数据库的接口。

"实时数据库的RTStat进程

获取实时数据库的状态信息。3.7SAN存储技术

BOSS系统中主机和存储设备较多，生产厂家和型号也可能多种多样，怎样将这些设备互联，使系统有良好的可扩充性，减少大数据量处理时的网络带宽，SAN技术是良好的解决方案，它做到了存储的网络化，使阵列和带库类的存储设备方便地互联互通。SAN连接示意图如图13所示：

图13SAN连接示意图作者：李朝铭梁炎松

山东浪潮齐鲁软件产业股份有限公司

附录资料：不需要的可以自行删除制定生产计划的常用方法一、图表法[例13-1]已知H公司1999年上半年（为简化，只考虑上半年）满足需求量的生产安排，见表13-5。为实现此进度安排，拟采用三种不同的综合生产计划方案。表13-5H公司1999年上半年生产进度安排单位：台序号项目名称1月2月3月4月5月6月12345678期初库存量预测需求量累计需求量保险储备量生产需要量(2)+(4)-(1）累计生产量有效工作日（天）累计工作日（天）400180018004501850185025254501500330037514253275224737511004400275100042752471275900530022585051252495225110064002751150627525120275170081004251850812523143*保险储备量=1/4预测需求量有关成本数据补充如下：生产成本=100元/件；存储费用=每月生产成本的1.5%（即每月每件1.5元）；标准工资率=每小时4元；加班费=标准工资的150%或每小时6元；缺货损失=5元/件；外协比自制昂贵而增加的费用=每件产品2元；招聘和培训费=每人200元；提前解聘损失费=每人250元；每件产品所需工时=5小时。方案1的策略：在正常工作班次下，通过增减生产工人来生产出确切的需要量。方案2的策略：固定生产工人数，工人数按6个月的平均产量来确定（（8125件×5小时/件）/（143天×8小时/天）=36人）；允许库存发生短缺，通过下月的生产来补足。方案3的策略：按生产需要量（计划量）最低的4月份来确定所需工人数，并稳定在4月份这个水平上（（850件×6月×5小时/件）/（143天×8小时/天）=22人；产量低于需求量部分通过外协来解决。计划方案见表13-6方案1：11600元方案2：7460元方案3：6182元

表13-6三种方案的计算序号月份（1）计划产量（2）所需工时(1)×5（3）每人每月工时数(天数×8)（4）所需工人数(2)/(3)（5）增加工人数（6）增加工人的支出（7）减少工人数（8）解聘损失费方案11234561850142510008501150185092507125500042505750925020017619219220018446402622295000007210000140042000614400015003500100000合计56006000月份（1）累计计划产量（2）有效生产工时（3）能力产量（4）累计能力产量（5）不足的产量（6）缺货损失（7）过剩产量（8）库存费用方案212345618503275427551256275812572006336691269127200662414401267138213821440132514402707408954716911823641056818620502840930346636111519954167合计58201640月份（1）计划产量（2）有效生产工时（3）能力产量（4）外协数量（5）外协费用方案3123456185014251000850115018504400387242244224440040488807748458458808109706511555270104019401302310105402080合计81256182表13-7三种方案的比较费用变化方案1方案2方案3变动工人数，生产确切的需要量固定工人数，变动库存量，允许缺货保持最低限度人数，不足量外协增加工人数的支出解聘损失费超储费用缺货损失外协费560060000000016405820000006182总成本1160074606182二、运输表法运输表法的基本假设是：1.每一单位计划期内正常生产能力、加班生产能力以及外协量均有一定限制；2.每一单位计划期的预测需求量是已知的；3.全部成本都与产量呈线性关系。表13-8用图表法求解的综合生产计划单位：万台计划方案计划期1计划期2计划期3计划期4未用生产能力总生产能力单位计划期期初库存0h2h3hI01正常生产rr+hr+2hr+3hR1加班生产cc+hc+2hc+3hOT1外协ss+hs+2hs+3hS12正常生产×rr+hr+2hR2加班生产×cc+hc+2hOT2外协×ss+hs+2hS23正常生产××rr+hR3加班生产××cc+hOT3外协××ss+hS34正常生产×××rR4加班生产×××cOT4外协×××sS4需求D1D2D3D4h──单位计划期内单位产品的库存成本I0──第1期期初库存r──单位产品的正常生产成本Rt──t期的正常生产能力c──单位产品的加班成本OTt──t期的加班生产能力S──单位产品的外协成本St──t期的外协生产能力Dt──t期的预测需求量

[例13-2]M公司生产某种产品，该产品的需求具有波动性，其需求预测和有关成本数据如表13-9所示。该公司现在打算根据表13-9和表13-11所列的生产能力计划来制定综合生产计划,公司现有库存为250万台。按照公司的经营方针，希望期末库存为300万台，且不允许任务积压和库存缺货。表13-9各期的需求预测值单位:万台季度1季度2季度3季度4季度合计需求30085015003002950表13-10各项成本数据项目成本单位产品的库存成本单位产品的正常生产成本单位产品的加班生产成本单位产品的外协成本0.3元/季度1.00元1.50元1.90元表13-11生产能力计划单位:万台项目1季度2季度3季度4季度正常生产450450750450加班生产909015090外协200200200200利用图表方法来解决这一问题，表13-12为该问题的解。

表13-12用图表法求解的综合生产计划单位：万台计划方案计划期1计划期2计划期3计划期4未用生产能力总生产能力单位计划期期初库存00250300.600.9002501正常生产005030400601.900450加班生产1.501.8010902.40090外协1.902.2050202.801802002正常生产×004501.301.600450加班生产×1.5080902.10090外协×1.90202002.5002003正常生产××007501.300750加班生产××501501.8001