CN102739450A

CN102739450A - 信令监测系统分布式平台架构及其处理方法

Info

Publication number: CN102739450A
Application number: CN2012102202761A
Authority: CN
Inventors: 叶春生; 车新奕; 雷果; 程涛木; 冉梦旭; 岳伟国
Original assignee: SHENZHEN BAOAD TECHNOLOGY Co Ltd
Current assignee: SHENZHEN BAOAD TECHNOLOGY Co Ltd
Priority date: 2012-06-29
Filing date: 2012-06-29
Publication date: 2012-10-17

Abstract

本发明提供了一种信令监测系统分布式平台架构及其处理方法。该平台构架包括数据传输层和业务处理层，其中：所述数据传输层包括若干通信支撑平台，业务处理层包括中心管理模块和若干通信系统业务模块。通信支撑平台主要负责中心管理模块和通信系统业务模块等之间实际的数据发送和接收。中心管理模块是一个特殊的通信系统业务模块，其主要负责管理系统中所有的通信系统业务模块，是整个信令监测的分布式平台的逻辑中心。通信系统业务模块主要负责具体的业务逻辑，为整个信令监测的分布式平台的功能支撑。本发明为通信系统业务模块提供简洁而统一的数据交互接口，具有很好的扩展性和可维护性。

Description

信令监测系统分布式平台架构及其处理方法

技术领域

本发明涉及信令监测领域，为多模块间数据交互提供了一种分布式的平台架构。

背景技术

近年来，随着通信技术的不断发展，信令监测业务发展也进入了一个迅猛发展的时代。随着信令监测业务量的不断增加，信令监测系统的复杂度也随之增加，而系统内部的数据交互的发杂度的增加尤为明显。目前基于分布式的通信系统业务模块（简称为“BPM”）间数据交互所采用的均是基于配置IP地址与侦听端口，而链路则由BPM自己维护。随着BPM数量的增加，特别是当BPM间交叉通信时，将导致的直接后果是：1）配置工作繁杂；2）配置出错率增加；3）扩展性差。

发明内容

本发明的目的是克服现有BPM间通信方式的缺陷，提供一个通用的通信支撑平台（简称为“GCP”），对所有BPM提供统一的数据交互接口。具体的数据交互工作则由GCP负责，从而为信令监测分布式平台提供一个易扩展、易维护的分布式平台框架。还提供了一种该平台构架的处理方法。

本发明采用的技术方案如下：

信令监测系统分布式平台架构，包括数据传输层和业务处理层，其中：所述数据传输层包括若干通信支撑平台，业务处理层包括中心管理模块和若干通信系统业务模块；所述通信支撑平台将与之连接的中心管理模块或通信系统业务模块的数据封装为数据包后，发送到相应的通信支撑平台；该通信支撑平台获得数据包后，将其解码并发送给与该通信支撑平台连接的中心管理模块通或信系统的业务模块。

所述通信支撑平台连接至少一个通信系统业务模块或一个中心管理模块。通信支撑平台之间通过TCP进行数据包的传输，通信支撑平台与中心管理模块或通信系统业务模块间通过Queue进行数据传输。

信令监测系统分布式平台架构的处理方法，包括如下步骤：

通信系统业务模块向中心管理模块进行注册，中心管理模块将注册成功消息返回该通信系统业务模块；中心管理模块广播全量注册消息；所有通信系统业务模块收到全量注册消息后，分别将确认消息返回给中心管理模块；此时连接通信系统业务模块和中心管理模块的各通信支撑平台之间能进行数据交互。

本发明平台架构依然是分布式的，只是在数据通信策略上提供一种新的自适应的分布式平台架构。本发明所采用的自适应的分布式平台架构以最大限度地减少繁杂的通信关系维护，为BPM提供简洁而统一的数据交互接口，具有很好的扩展性和可维护性。总之，本发明具有以下有益技术效果：

1、统一管理BPM

传统信令监测系统的BPM间数据交互多采用通过IP地址与端口直接进行数据交换，其IP地址信息和端口信息只对于直接通信的进程可见，没有一个统一的信息汇总机制。这种方式不利于BPM数据的汇总与BPM的统一管理，特别是当系统中所有BPM都需要增加一些共有的控制功能时，涉及到的所有BPM都需要编写自己的接收控制命令的通信接口，导致开发工作特别大。而信令监测系统的分布式系统的CMM将系统中所有的BPM信息进行汇总，方便对BPM进行集中统一的管理；同时，当需要增加一些通用的控制功能时，只需要在CMM中增加相应的接口，并将命令传递给相关的BPM，而BPM则只需要做相应的逻辑处理即可，在减轻了需求变更引起的成本的同时，也增强了系统的扩展性。

2、统一而简洁的BPM交互接口

传统信令监测系统的BPM通常都是自己维护复杂数据链路，BPM间的数据流的拆/组包工作也需要BPM进行维护。由于确保BPM间复杂的数据链路的稳定性与数据流的拆/组包工作本身就是一种很繁杂的工作，需要投入较多的精力。而信令监测系统的分布式系统中的GCP则对BPM间的数据链路稳定性和数据流的拆/组工作进行了封装，提供统一而简洁的BPM交互接口。当BPM需要与其他BPM进行数据交互时，只需把格式化的消息包放入GCP提供的接口，消息即可到达发送端的BPM。

3、分层机制降低BPM间的耦合性

传统信令监测系统BPM通常集各种处理逻辑于一身，使得BPM复杂度较高，当其中一个BPM的处理逻辑发生变化时，可能影响与其相关的BPM。这种BPM间的较高的逻辑耦合性不利于适应需求的变更，一旦需要发生变更，则可能涉及到各BPM中较多的处理逻辑。而信令监测系统的分布式系统对系统进行了分层处理，GCP负责数据交互、消息及流量统计等较为底层的数据传输处理，BPM则仅负责业务相关的逻辑处理。这种分层机制可以较明显地简化传统BPM的处理逻辑，使得BPM仅专注于业务逻辑的处理。

4、GCP提供稳定的数据交互平台

传统信令监测系统BPM集业务逻辑处理与数据传输处理于一身，因此每一个BPM的业务逻辑处理与数据传输处理的稳定性都会影响到整个系统的稳定性。而信令监测系统的分布式系统中的GCP则对数据传输处理进行了统一的封装，整个系统中的所有数据传输处理都有一个（或多个）GCP负责，只要确保GCP稳定就可以确保整个信令监测系统的分布式系统中的数据传输处理的稳定，从而为BPM提供一个稳定的数据交互平台。

5、GCP提供灵活而高效的数据交互机制

传统信令监测系统BPM间由于相互独立，因此导致BPM间的数据交互需要跨越两个（或多个）模块，这种传输模式不仅灵活性较差，且无法为多个逻辑联系紧密的BPM的数据交互提供高效的数据交互机制。而信令监测系统的分布式系统为系统的灵活性与数据交互的高效性提供了支撑。一个GCP支持加载一个或多个BPM，为系统提供了较强的灵活性。由于提供了同一个GCP加载多个BPM的功能支撑，因此可以将逻辑联系紧密的多个BPM挂载至同一个GCP下，这种GCP的内部数据交互机制确保了数据交互的高效性。

6、系统提高了较强的自适应能力

传统信令监测系统中只有存在数据交互的BPM才会共享各自的相关信息，定制性较强。这种模式下，当数据流向发生较大改变时，涉及的BPM将都需做相应的调整，从而带来了额外的开发与调整成本。而信令监测系统的分布式系统为提供了较强的自适应能力，系统中的每个BPM都对应一个唯一的ModID，当数据流发生改变时，只需要重新制定接收BPM的ModID即可。另外，当系统中的BPM信息发生变化时，加载该BPM的GCP则会通知CMM，而CMM会根据收到的新信息更新其维护的全量BPM信息；之后CMM会把更新后的全量BPM信息以广播的方式通知所有的GCP。也就是说每个GCP均保留着一份最新的全量的BPM信息，这种机制就为系统较强的自适应能力提供了保障。

7、系统良好的扩展性和易维护性

传统信令监测系统由于BPM的独立性导致扩展和维护成本均较高，尤其是当需要增加一个全新的BPM时，扩展引起的成本更是尤为昂贵。同时，由于业务逻辑处理与数据传输处理集中交织与BPM，导致后期维护的复杂度和成本均比较高。而信令监测系统的分布式系统提出了一种通用的数据交互架构，新增一个全新的BPM时，只需使用GCP提供的统一的接口即可实现稳定的数据传输处理，而BPM则仅实现业务处理。这种分层模式对于系统维护与问题快速排查都相对容易，因为GCP和BPM各司其职，很容易把问题锁定到GCP或BPM；同时，这种分层模式也为系统的扩展性提供了良好的支撑。

附图说明

图1为信令监测的分布式平台的架构示意图；

图2为信令监测的分布式平台的逻辑功能结构图；

图3为信令监测的分布式平台的消息流程示意图;

图4为信令监测的分布式平台的内部交互消息流程示意图。

具体实施方式

本发明提供一种的基于模块化概念的信令监测的分布式平台架构，该架构是一种分层模块化结构，其整体的架构示意图如图1所示。该平台架构包括GCP、BPM和中心管理模块（简称为“CMM”）。整个架构中包含一个CMM和多个BPM，其中CMM与BPM都必须依赖于GCP存在，也就是说每个CMM/BPM都对应一个GCP。GCP负责CMM和BPM间、BPM和BPM间的数据交互； CMM负责管理BPM，保存所有BPM的IP地址、侦听端口和ModID等的全量信息，并当全量信息发生变更时，通知所有的BPM对应的GCP；BPM则负责信令监测的业务处理。其中BPM启动时，需要配置指定自身BPM模块的IP地址、侦听端口及全局唯一的模块号（简称为“ModID”），BPM的GCP启动时会报告自己的IP地址、侦听端口和ModID的信息给CMM，而CMM也会将整个系统中所有BPM的GCP的全量的IP地址、侦听端口和ModID等信息反馈给本地的BPM对应的GCP，在其需要与其他BPM进行交互时，就可以根据这些全量信息建立相应的链路，进行数据的传输，即指定数据接收BPM的ModID即可完成相应的数据交互功能。

本发明实施方法中按层次将系统划分为两层：数据传输层和业务处理层数据传输层包括若干GCP，业务处理层包括CMM和若干BPM。而按照逻辑功能划分则可将系统划分为三类功能模块：GCP、BPM和CMM，其中CMM为一个特殊的，其逻辑功能结构图如图2所示。

如图1所示，本发明实施提到的信令监测的分布式平台架构主要由GCP、CMM和BPM三个部分组成。下面分别介绍三个部分的功能。

一、 GCP

GCP位于信令监测的分布式平台架构的最底层，主要负责BPM和CMM等之间实际的数据发送和接收。

GCP封装BPM数据交互过程中所涉及的数据传输细节，其不能单独存在，必须通过统一的接口加载BPM或CMM才能实现其特定的功能或服务。GCP提供的数据交互流程有两种方式，分别为：BPM->GCP --- GCP->BPM方式，如图2所示；BPM->GCP->BPM方式，如图4所示。为保证数据交互的可靠性，GCP间的实现则通过TCP（Transfer Control Protocol，传输控制协议）进行数据交互，而GCP与BPM间则通过Queue（队列）来进行数据的传递。GCP通过一系列接口对BPM服务，其中最终的两个接口为：SendMsg和OnMsg，其中SendMsg用于消息的发送，OnMsg用于消息的接收。

二、CMM

CMM位于信令监测的分布式平台中的GCP之上，是一个特殊的BPM，其主要负责管理系统中所有的BPM，是整个信令监测的分布式平台的逻辑中心。

CMM中记录有系统中所有BPM的IP地址、侦听端口和ModID等一系列全量注册信息，并为BPM提供注册信息更新通知、数据/消息分段、命令分发等功能，使得对系统中的BPM的管理更为便捷，同时也增强了信令监测的分布式平台的自适应能力。其中，CMM中涉及的最重要的两个功能分别是BPM注册功能和信息更新通知功能。BPM注册功能是指BPM启动时首先会到CMM进行注册，报告自身的IP地址、侦听端口及ModID；信息更新通知功能是指当CMM记录的全量BPM信息发生变化或更新时，CMM则会将更新后的全量BPM信息通知所有的GCP，以便GCP能正确地进行数据的分发，交互流程如图2所示。

三、BPM

BPM位于信令监测的分布式平台中的GCP之上，其主要负责具体的业务逻辑，为整个信令监测的分布式平台的功能支撑。

BPM是整个信令监测的分布式平台的功能核心，GCP和CMM都是为BPM服务的，GCP为BPM提供底层通信支撑，CMM则为BPM的统一管理提供了支撑。整个系统不能存在“IP地址+侦听端口”或ModID信息完全相同的BPM，因为这种情况会引起GCP分发数据时发生歧义，导致数据无法正确的被分发。

信令监测的分布式平台中三个功能部分缺一不可，完整地构成了信令监测的分布式系统。GCP、CMM、BPM各司其职，共同完成了信令监测系统的工作，其工作流程图如图2所示。

系统工作流程描述：

1. BPM(A)模块首先向CMM进行注册

2. CMM返回注册成功消息

3. CMM广播全量注册消息,BPM(B)这时还未启动

4. BPM(A)收到全量注册消息后,返回确认消息

5. BPM(B)启动,来CMM注册

6. CMM返回注册成功消息给BPM(B)

7. CMM广播全量注册消息

8. CMM收到回应消息,分别是:

BPM(A)返回的确认消息

BPM(B)返回的确认消息

9.现在BPM(A)的GCP和BPM(B)的GCP有了相互的IP和端口,这样就可以建立连接进行数据交互了。

接下来将分别对CMM和BPM的启动过程进行描述

CMM启动过程描述如下：

1.加载配置文件

2.监听端口

3.加载CMM

4.等待其他BPM来注册。

BPM启动过程描述如下：

1.加载配置文件

2.监听端口

3.连接CMM

4. CMM连接回来

5.向中CMM注册

6.接收CMM返回的注册成功消息

7.接收CMM返回的全量消息

8.确认CMM返回的全量消息

9.加载BPM

10.根据全量信息建立BPM需要的连接。

至此，CMM和多个BPM都已经正常运行，由于该发明重在为信令监测提供一个通用、稳定的分布式平台，数据的发送、接收以及全量信息的更新将是分布式平台中实现的最重要的功能点。下面将对着三个功能点的实现流程做进一步的描述。

BPM数据发送流程如图3所示。

详细描述如下：

1. BPM将数据交给GCP

2. GCP分析数据包头

3. GCP将数据发给对应的Sender(发送链路)

4.Sender将数据发到自己对应的链路上去。

BPM数据接收流程如图3所示。

详细描述如下：

1.Recver(接收链路)接收到数据转交给GCP

2.GCP分析数据包头

3.GCP将数据发给对应的BPM

4.BPM处理数据。

CMM全量信息的更新通知流程如图2所示。

详细描述如下：

1.CMM收到注册消息

2.CMM回应注册成功消息

3.CMM广播全量信息

4.CMM接收全量回应消息

综上所述，本发明是为多模块间数据交互提供了一种分布式的平台架构。

Claims

1.信令监测系统分布式平台架构，其特征在于，包括数据传输层和业务处理层，其中：所述数据传输层包括若干通信支撑平台，业务处理层包括中心管理模块和若干通信系统业务模块；

所述通信支撑平台将与之连接的中心管理模块或通信系统业务模块的数据封装为数据包后，发送到相应的通信支撑平台；该通信支撑平台获得数据包后，将其解码并发送给与该通信支撑平台连接的中心管理模块或通信系统业务模块。

2.根据权利要求1所述信令监测系统分布式平台架构，其特征在于：所述通信支撑平台连接至少一个通信系统业务模块或一个中心管理模块。

3.根据权利要求1所述信令监测系统分布式平台架构，其特征在于：所述通信支撑平台之间通过TCP进行数据包的传输，通信支撑平台与中心管理模块或通信系统业务模块间通过Queue进行数据传输。

4.信令监测系统分布式平台架构的处理方法，其特征在于，包括如下步骤：

通信系统业务模块向中心管理模块进行注册，中心管理模块将注册成功消息返回该通信系统业务模块；

中心管理模块广播全量注册消息；

所有通信系统业务模块收到全量注册消息后，分别将确认消息返回给中心管理模块；此时连接通信系统业务模块和中心管理模块的各通信支撑平台之间能进行数据交互。

5.根据权利要求4所述信令监测系统分布式平台架构的处理方法，其特征在于：所述全量注册消息包括IP地址、侦听端口和模块号。

6.根据权利要求4或5所述信令监测系统分布式平台架构的处理方法，其特征在于：所述中心管理模块和每个通信系统业务模块都对应一个模块号。