CN108243012B - 在线计费系统ocs中计费应用处理系统、方法及装置 - Google Patents

Abstract

本发明实施例公开了一种在线计费系统OCS中计费应用处理系统、方法及装置。系统包括：云应用管理装置和计费应用状态管理装置；云应用管理装置，用于根据OCS中计费应用之间的依赖关系，构建至少一个编排组合；计费应用状态管理装置，用于获取OCS中计费应用的状态信息和标识信息，并根据标识信息从云应用管理装置中获取编排组合，根据编排组合和状态信息依次调用对应的docker容器，以对接对应的计费应用；其中，docker容器为对计费应用docker化处理获取的。本发明实施例采用分布式资源管理框架mesos+云应用的架构，基于OCS中计费应用之间的依赖关系，构建编排组合，并基于编排组合对计费进程进行可顺序编排管理，与现有技术采用的mesos+marathon架构相比，避免产生批量错单的问题。

Description

在线计费系统OCS中计费应用处理系统、方法及装置

技术领域

本发明实施例涉及通信技术领域，具体涉及一种在线计费系统OCS中计费应用处理系统、方法及装置。

背景技术

目前在线计费模式逐步取代传统的离线计费模式成为主流，其部署流程参见图1，在线计费应用进程在物理机上部署包括：1、Dcc Proxy进程121：实现接受网元设备发来的DCC计费消息；2、消息编解码应用进程122：实现是消息信令的识别和解码转义；3、欠费控制进程INBOSS123，及时控制用户使用防止欠费；4、总线调度应用124:作为消息转发进程(和后续的ts2结合)；5、反算进程125：实现对解码后信令的批价处理。

现有在线计费系统采用“网元110-物理机120”组网模式，网元与物理机是1对1模式交互，每一对网元与物理机都是独立运行，如图1。目前在线计费系统一共有20台物理机，两两主机互为主备，在线计费应用程序与物理机的操作系统版本捆绑。程序升级时，需要同时更新20台主机上的程序版本，保证各版本一致性。如果从整个计费系统看，在线计费主机、离线计费主机数量已经超过60台。

为改善应用部署环境，采取传统的Mesos+Marathon架构将在线计费(OCS)应用纳入容器化部署的方案如图2所示，包括：平台即服务PASS管理平台290、Mesos210+Marathon250架构、分布式应用程序协调服务zookeeper230、多个服务220和多个docker容器240以及物理机资源260、虚拟机资源270、基础设施即服务IAAS资源280等。

在实现本发明实施例的过程中，发明人发现这种传统的Mesos+Marathon架构下，仅能实现BOSS各应用两点之间的调用关联，而BOSS系统多使用C++语言编写，处理过程有状态化；应用关系复杂，经常需要互相依赖、互相配置、互相发现，形成了链状、环状、网状的结构，可见传统的Mesos+Marathon架构容易产生批量错单。

发明内容

本发明实施例的一个目的是解决现有Mesos+Marathon架构下，容易出现批量错单的问题。

本发明实施例提出了一种在线计费系统OCS中计费应用处理系统，包括：云应用管理装置和计费应用状态管理装置；

所述云应用管理装置，用于根据OCS中计费应用之间的依赖关系，构建至少一个编排组合；

所述计费应用状态管理装置，用于获取OCS中计费应用的状态信息和标识信息，并根据所述标识信息从所述云应用管理装置中获取与所述标识信息对应的编排组合，根据所述编排组合和所述状态信息依次调用对应的docker容器，以对接对应的计费应用；

其中，所述docker容器为对计费应用docker化处理获取的。

可选的，所述计费应用状态管理装置包括：状态采集模块和状态管理模块；

所述状态采集模块，设置在OCS的计费应用的物理主机上，用于采集计费应用的状态信息和标识信息，并上报至状态管理模块；

所述状态管理模块，用于根据所述标识信息从所述云应用管理装置获取编排组合，并根据所述编排组合和所述状态信息对接对应的计费应用。

可选的，所述状态采集模块，还用于根据所述状态信息判断计费应用的资源使用状态，并将资源使用状态发送至所述状态管理模块；

相应地，所述状态管理模块，还用于根据所述资源使用状态为计费应用分配可用资源或者回收计费应用的可用资源。

可选的，还包括：资源管理平台；

所述资源管理平台，用于为所述云应用管理装置提供可供分配的资源，或者接收所述云应用管理装置退回的资源；

相应地，所述云应用管理装置，还用于在接收到OCS发送的申请资源的请求时，从所述资源管理平台为所述OCS申请可用资源，或者在OCS停止运行后将所述可用资源退回所述资源管理平台。

可选的，还包括：镜像库；

所述镜像库，用于存储计费应用对应的docker镜像，以支撑计费应用对应的docker容器。

本发明实施例提出了一种在线计费系统OCS中计费应用的处理方法，包括：

获取计费应用的状态信息和标识信息；

根据所述计费应用的标识信息从预建立数据库中查找获取与所述标识信息对应的编排组合，所述预建立数据库中存有标识信息和编排组合之间的对应关系；

根据所述编排组合和所述状态信息依次调用对应的docker容器，以对接对应的计费应用；

其中，所述编排组合为根据计费应用之间的依赖关系建立的。

可选的，在根据所述计费应用的标识信息从预建立数据库中查找获取与所述标识信息对应的编排组合之前，所述方法还包括：

对OCS中的计费应用进行docker化处理，获取计费应用对应的docker容器；

根据计费应用之间的依赖关系，对计费应用对应的docker容器进行编排处理，获取至少一个编排组合；

将所述至少一个编排组合存入预建立数据库。

可选的，所述根据所述编排组合和所述状态信息依次调用对应的docker容器包括：

根据所述状态信息中携带的功能信息选取对应的docker容器；

根据所述编排组合中的拓扑排序依次为计费应用调用选取的docker容器。

可选的，所述方法还包括：

根据所述状态信息中携带的资源使用信息为计费应用分配可用资源或者回收计费应用的可用资源。

本发明实施例提出了一种在线计费系统OCS中计费应用的处理模块，包括：

获取模块，用于获取计费应用的状态信息和标识信息；

查找模块，用于根据所述计费应用的标识信息从预建立数据库中查找获取与所述标识信息对应的编排组合，所述预建立数据库中存有标识信息和编排组合之间的对应关系；

调用模块，用于根据所述编排组合和所述状态信息依次调用对应的docker容器，以对接对应的计费应用；

其中，所述编排组合为根据计费应用之间的依赖关系建立的。

由上述技术方案可知，本发明实施例提出的在线计费系统OCS中计费应用处理系统、方法及装置采用分布式资源管理框架mesos+云应用的架构，并基于OCS中计费应用之间的依赖关系，构建编排组合，并基于编排组合对计费进程进行可顺序编排管理，与现有技术采用的mesos+marathon架构相比，避免产生批量错单的问题。。

附图说明

通过参考附图会更加清楚的理解本发明的特征和优点，附图是示意性的而不应理解为对本发明进行任何限制，在附图中：

图1示出了现有在线计费应用部署的流程示意图；

图2示出了现有的mesos+marathon架构的结构示意图；

图3示出了本发明实施例提出的在线计费系统OCS中计费应用处理系统的结构示意图；

图4示出了本发明实施例提出的在线计费系统OCS中计费应用处理系统的结构示意图；

图5a和图5b示出了有向无环图对应的拓扑排序的关系示意图；

图6示出了本发明实施例提出的在线计费系统OCS中计费应用处理方法的流程示意图；

图7示出了本发明实施例提出的在线计费系统OCS中计费应用处理方法中建库的流程示意图；

图8示出了本发明实施例提出的在线计费系统OCS中计费应用处理装置的结果示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

图3示出了本发明实施例提出的在线计费系统OCS中计费应用处理系统的结构示意图，参见图3，该系统包括：云应用管理装置110和计费应用状态管理装置120，其中；

所述云应用管理装置110，用于根据OCS中计费应用之间的依赖关系，构建至少一个编排组合；其中，依赖关系用于描述两个“元素”(计费应用、类、用例等)之间的语义连接关系；

基于这种两两之间的关系，可根据要实现的功能构建一个或多个编排组合。

例如：“基于事件的计费”功能，其中涉及到的模块包括：通用接口、计费控制模块、计费处理模块和余额管理模块，基于四者之间的依赖关系，构建与“基于事件的计费”功能对应的编排组合，四者之间的关系为：通过通用接口向计费控制模块发送基于事件的计费请求，计费控制模块建立会话，并向计费处理模块发送计费请求，计费处理模块完成计费处理过程，并向计费控制模块返回计费应答请求，然后计费控制模块向余额管理模块发送余额扣除请求，由余额管理模块完成余额扣除处理，完成扣除后余额管理模块向计费控制模块返回余额扣除请求应答。

所述计费应用状态管理装置120，与docker化的计费应用的主机群130连接，用于获取OCS中计费应用的状态信息和标识信息，并根据所述标识信息从所述云应用管理装置110中获取与所述标识信息对应的编排组合，根据所述编排组合和所述状态信息依次调用对应的docker容器，以对接对应的计费应用；

其中，所述docker容器为对计费应用docker化处理获取的；标识信息可以为计费应用的名称或者编号等。

需要说明的是，云应用管理装置110、计费应用状态管理装置120和docker化的计费应用的主机群130均装载在适用于C++应用的mesos+云应用管理平台的构架中，OCS中的计费应用被拆分为一个或者多个由关系的主机，进而构建docker化的计费应用主机群130，然后基于计费应用之间的依赖关系，对计费应用进行自由的编排组合，获取一个或者多个编排组合，进而基于编排组合实现计费应用之间的相互依赖、相互配置、相互发现的关系，避免出现计费应用无次序启动导致的批量错单的问题。

可见，本实施例采用分布式资源管理框架mesos+云应用的架构，基于OCS中计费应用之间的依赖关系，构建编排组合，并基于编排组合对计费进程进行可顺序编排管理，与现有技术采用的mesos+marathon架构相比，避免产生批量错单的问题。

图4示出了本发明实施例提出的在线计费系统OCS中计费应用处理系统的结构示意图，参见图4，该系统包括：云应用管理平台410、docker化后的主机集群420、计费应用状态管理装置430、资源管理平台440以及镜像库450，其中：

资源管理平台440，用于结合云应用管理平台410共同完成对资源的统一划分和监控，实现硬件资源根据应用变化的需求进行按需分配，提升资源的弹性伸缩能力，保证应用集群资源的高效利用。

资源管理平台440包括多个功能模块，例如：仓库管理模块、监控模块、资源管理模块等，其中，仓库管理模块用于存储资源、统计资源等，监控模块用于监测资源可分配量、已使用量、剩余量，资源进出量等。

Docker镜像仓库450(DockerRegistry)，用于存储所有计费应用对应的docker镜像。

云应用管理平台410是Docker管理核心平台，用于通过管理接口统一向云管理注册服务，提供运行资源，并实时反馈运行状态，将各计费应用形成链状、环状、网状的结构。再通过容器镜像将应用进行打包，并镜像给运维团队，为开发，测试，运维提供相同的环境，从而实现快速迭代，实现敏捷开发，快速提升系统上线效率。增加平台对容器的编排、调度、监控能力，并在BOSS平台框架层面做Docker化的适配，做到业务应用基本对Docker无感知，系统平滑的升级。

另外，资源管理平台440，用于为所述云应用管理装置提供可供分配的资源，或者接收所述云应用管理装置退回的资源；

相应地，所述云应用管理装置410，还用于在接收到OCS发送的申请资源的请求时，从所述资源管理平台440为所述OCS申请可用资源，或者在OCS停止运行后将所述可用资源退回所述资源管理平台440。

下面对云应用管理平台410进行详细说明：

云应用管理平台410包括：计费应用状态管理装置S-NRM和CPF进程顺序编排管理和监控装置其中：

计费应用状态管理装置S-NRM，用于计费应用可用性状态的管理模块，保证相互调用的有序性。C++编译的在线计费进程，不同于JAVA服务应用：需要加载动态LIB库关联各进程之间的服务接口，各关联进程需全部处于在服务状态下才可以全流程运转，否则将容易造成批量失败话单，并给予后续失败话单回收的难度。S-NRM可用于对接各计费应用的信息上报、信息保存、信息更新、信息失效、信息次序反馈等功能，其在各物理主机设立子模块NRM客户端，由NRM客户端收集上报计费应用状态信息，并上报到S-NRM管理服务端，采用“TB-TS”容器调度算法，指定共享内存块，将Docker容器内的应用通过NRM子模块向SNRM模块注册“运行状态”，通过共享队列记录进程运行状态，各进程统一查询和获取队列中的回执信息来保证依赖进程的可用性。

计费应用状态管理装置S-NRM包括：状态采集模块NRM和状态管理模块SRM，其中：

状态采集模块NRM设置在OCS的计费应用的物理主机上，用于采集计费应用的状态信息和标识信息，并上报至状态管理模块；

状态管理模块SRM，用于根据所述标识信息从所述云应用管理装置获取编排组合，并根据所述编排组合和所述状态信息对接对应的计费应用。

不难理解的是，NRM可根据所述状态信息判断计费应用的资源使用状态，并将资源使用状态发送至所述状态管理模块；相应地，SRM可根据所述资源使用状态为计费应用分配可用资源或者回收计费应用的可用资源。

另外，云应用管理平台410还包括图3对应实施例中的云应用管理装置以及其他的功能模块，例如：任务管理模块、流程管理模块、进程管理模块、资源管理模块等；而且，SRM和NRM也可以从云应用管理平台中独立出来，以作为单独的模块设置在主机集群中，参见图4。

CPF进程顺序编排管理和监控装置，用于编排串联和异常监控，不难理解的是，计费应用存在多种实时/定时执行任务，Docker化容器后隔离性增强。

下面对编排模型进行详细说明：

本发明通过“CPF-JOB”的任务编排模型解决编排串联和异常监控问题。

具体的，“CPF-JOB”的任务编排模型将各进程形成有向无环图，由多个步骤(step)组成，前置步骤是后续步骤的充要条件，如图5a，每个步骤里面包含一个或者多个可以同时运行的流程。通过服务、流程、步骤、任务层层联动，即可以宏观的监控整体的进度，也可以精确的定位其中某个容器实例的异常。

其中，任务编排技术的有向无环图原理设计说明如下：

有向无环图(Directed Acyclic Graph,DAG)是有向图的一种，字面意思的理解就是图中没有环。常常被用来表示事件之间的驱动依赖关系，管理任务之间的调度。拓扑排序是对DAG的顶点进行排序，使得对每一条有向边(u,v)，均有u(在排序记录中)比v先出现。亦可理解为对某点v而言，只有当v的所有源点均出现了，v才能出现。

以图5a为例，该有向无环图中包括A、B、C、D、E，分别与计费应用相对应，图5a中的顶点D的邻接点A、C在D之前出现、邻接点E在D之后出现，因此，根据上述拓扑排序的原理可知，该顶点排序时拓扑顺序。而以图5b为例，由于顶点D的邻接点E比其先出现，因此该顶点排序不是拓扑排序。

可见，本实施例通过“CPF-JOB”的任务编排模型能有序地对接各计费应用的信息上报、信息保存、信息更新、信息失效、信息次序反馈等功能，避免出现批量错单的问题。

图6示出了本发明实施例提出的在线计费系统OCS中计费应用处理方法的流程示意图，参见图6，该方法包括如下步骤：

610、获取计费应用的状态信息和标识信息；

620、根据所述计费应用的标识信息从预建立数据库中查找获取与所述标识信息对应的编排组合，所述预建立数据库中存有标识信息和编排组合之间的对应关系；

630、根据所述编排组合和所述状态信息依次调用对应的docker容器，以对接对应的计费应用；

其中，所述编排组合为根据计费应用之间的依赖关系建立的。

步骤630具体包括：根据所述状态信息中携带的功能信息选取对应的docker容器；根据所述编排组合中的拓扑排序依次为计费应用调用选取的docker容器。

可见，本实施例采用分布式资源管理框架mesos+云应用的架构，基于OCS中计费应用之间的依赖关系，构建编排组合，并基于编排组合对计费进程进行可顺序编排管理，与现有技术采用的mesos+marathon架构相比，避免产生批量错单的问题。

进一步地，为了提高主机扩容的自动化程度，该方法还包括：

根据所述状态信息中携带的资源使用信息为计费应用分配可用资源或者回收计费应用的可用资源。

图7示出了本发明实施例提出的在线计费系统OCS中计费应用处理方法中建库的流程示意图，参见图7，建库包括如下步骤：

710、对OCS中的计费应用进行docker化处理，获取计费应用对应的docker容器；Docker化处理即是将计费应用及其依赖的环境打包为docker容器。

720、根据计费应用之间的依赖关系，对计费应用对应的docker容器进行编排处理，获取至少一个编排组合；

需要说明的是，计费应用之间的依赖关系可参见图5a和图5b，例如：D的启动依赖于A和C的完成，C的启动依赖于B的完成，B的启动以来于A的完成等等。

730、将所述至少一个编排组合存入预建立数据库。

需要说明的是，编排处理即为按照一定的目的一次排列，基于所要实现的功能的不同，编排处理后可能获得一个或多个编排组合，并将得到的编排组合存入库中。

可见，本实施例采用分布式资源管理框架mesos+云应用的架构，基于OCS中计费应用之间的依赖关系，构建编排组合，并基于编排组合对计费进程进行可顺序编排管理，与现有技术采用的mesos+marathon架构相比，避免产生批量错单的问题。

图8示出了本发明实施例提出的在线计费系统OCS中计费应用处理装置的结果示意图，参见图8，该装置包括：获取模块810、查找模块820和调用模块830，其中：

获取模块810，用于获取计费应用的状态信息和标识信息；

查找模块820，用于根据所述计费应用的标识信息从预建立数据库中查找获取与所述标识信息对应的编排组合，所述预建立数据库中存有标识信息和编排组合之间的对应关系；

调用模块830，用于根据所述编排组合和所述状态信息依次调用对应的docker容器，以对接对应的计费应用；

其中，所述编排组合为根据计费应用之间的依赖关系建立的。

需要说明的是，在在线计费的过程中，获取模块810实时获取OCS中计费应用的状态信息和标识信息，并将采集到的信息发送至查找模块820，由查找模块820基于有状态的计费应用标识信息查找对应的编排组合，并将查找到的编排组合发送至调用模块830，调用模块830基于接收到的编排组合一次调用对应的docker容器对接计费应用。

可见，本实施例采用分布式资源管理框架mesos+云应用的架构，基于OCS中计费应用之间的依赖关系，构建编排组合，并基于编排组合对计费进程进行可顺序编排管理，与现有技术采用的mesos+marathon架构相比，避免产生批量错单的问题。

综上所述，本发明具有如下优点：

1、探索适应于BOSS系统C++应用的Mesos+云应用管理平台定制化技术，使Docker容器中隔离服务、应用之间的互相依赖、互相配置、互相发现，避免造成计费话单处理产生批量错单。

2、计费进程可顺序编排管理和监控，并可及时发现进程异常带来风险：进程使用的资源可配置可控制，主机资源使用整体可控，可预警。

3、业务编译环境与docker宿主机解绑，新增主机、升级操作系统不在纠结。程序升级简化发布、更加安全，由后台手工模式转为界面化、流程化操作，降低出错风险；版本控制较非docker化简单；升级、回退步骤简化。

4、云平台统一搭建，对主机资源实现统一管理、监控；多维度监控方式丰富可靠：业务流程视角监控，docker维度监控保障。

在上述实施例中，对于方法实施方式，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施方式并不受所描述的动作顺序的限制，因为依据本发明实施方式，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施方式均属于优选实施方式，所涉及的动作并不一定是本发明实施方式所必须的。

而且对于方法、装置实施方式而言，由于其与系统实施方式有相似之处，所以描述的比较简单，相关之处参见系统实施方式的部分说明即可。

另外，应当注意的是，在本发明的装置的各个部件中，根据其要实现的功能而对其中的部件进行了逻辑划分，但是，本发明不受限于此，可以根据需要对各个部件进行重新划分或者组合。

本发明的各个部件实施方式可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本装置中，PC通过实现因特网对设备或者装置远程控制，精准的控制设备或者装置每个操作的步骤。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样实现本发明的程序可以存储在计算机可读介质上，并且程序产生的文件或文档具有可统计性，产生数据报告和cpk报告等，能对功放进行批量测试并统计。应该注意的是上述实施方式对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施方式。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种在线计费系统OCS中计费应用处理系统，其特征在于，包括：云应用管理装置和计费应用状态管理装置；

所述云应用管理装置，用于根据OCS中计费应用之间的依赖关系，构建至少一个编排组合；其中，所述依赖关系用于描述计费应用之间的语义连接关系；所述云应用管理装置，用于根据OCS中计费应用之间的依赖关系，构建至少一个编排组合，包括：

云应用管理装置，用于根据OCS中计费应用之间的依赖关系，根据要实现的功能构建一个或多个编排组合；所述计费应用状态管理装置，用于获取OCS中计费应用的状态信息和标识信息，并根据所述标识信息从所述云应用管理装置中获取与所述标识信息对应的编排组合，根据所述编排组合和所述状态信息依次调用对应的docker容器，以对接对应的计费应用；

其中，所述docker容器为对计费应用docker化处理获取的。

2.根据权利要求1所述的系统，其特征在于，所述计费应用状态管理装置包括：状态采集模块和状态管理模块；

所述状态采集模块，设置在OCS的计费应用的物理主机上，用于采集计费应用的状态信息和标识信息，并上报至状态管理模块；

所述状态管理模块，用于根据所述标识信息从所述云应用管理装置获取编排组合，并根据所述编排组合和所述状态信息对接对应的计费应用。

3.根据权利要求1所述的系统，其特征在于，所述状态采集模块，还用于根据所述状态信息判断计费应用的资源使用状态，并将资源使用状态发送至所述状态管理模块；

相应地，所述状态管理模块，还用于根据所述资源使用状态为计费应用分配可用资源或者回收计费应用的可用资源。

4.根据权利要求1所述的系统，其特征在于，还包括：资源管理平台；

所述资源管理平台，用于为所述云应用管理装置提供可供分配的资源，或者接收所述云应用管理装置退回的资源；

相应地，所述云应用管理装置，还用于在接收到OCS发送的申请资源的请求时，从所述资源管理平台为所述OCS申请可用资源，或者在OCS停止运行后将所述可用资源退回所述资源管理平台。

5.根据权利要求1所述的系统，其特征在于，还包括：镜像库；

所述镜像库，用于存储计费应用对应的docker镜像，以支撑计费应用对应的docker容器。

6.一种在线计费系统OCS中计费应用的处理方法，其特征在于，包括：

获取计费应用的状态信息和标识信息；

根据所述计费应用的标识信息从预建立数据库中查找获取与所述标识信息对应的编排组合，所述预建立数据库中存有标识信息和编排组合之间的对应关系；

根据所述编排组合和所述状态信息依次调用对应的docker容器，以对接对应的计费应用；

其中，所述编排组合为根据计费应用之间的依赖关系建立的；其中，所述依赖关系用于描述计费应用之间的语义连接关系；所述编排组合为根据计费应用之间的依赖关系建立的，包括：

所述编排组合为根据计费应用之间的依赖关系，根据要实现的功能构建的。

7.根据权利要求6所述的方法，其特征在于，在根据所述计费应用的标识信息从预建立数据库中查找获取与所述标识信息对应的编排组合之前，所述方法还包括：

对OCS中的计费应用进行docker化处理，获取计费应用对应的docker容器；

根据计费应用之间的依赖关系，对计费应用对应的docker容器进行编排处理，获取至少一个编排组合；

将所述至少一个编排组合存入预建立数据库。

8.根据权利要求6所述的方法，其特征在于，所述根据所述编排组合和所述状态信息依次调用对应的docker容器包括：

根据所述状态信息中携带的功能信息选取对应的docker容器；

根据所述编排组合中的拓扑排序依次为计费应用调用选取的docker容器。

9.根据权利要求6所述的方法，其特征在于，所述方法还包括：

根据所述状态信息中携带的资源使用信息为计费应用分配可用资源或者回收计费应用的可用资源。

10.一种在线计费系统OCS中计费应用的处理模块，其特征在于，包括：

获取模块，用于获取计费应用的状态信息和标识信息；

查找模块，用于根据所述计费应用的标识信息从预建立数据库中查找获取与所述标识信息对应的编排组合，所述预建立数据库中存有标识信息和编排组合之间的对应关系；

调用模块，用于根据所述编排组合和所述状态信息依次调用对应的docker容器，以对接对应的计费应用；

其中，所述编排组合为根据计费应用之间的依赖关系建立的；其中，所述依赖关系用于描述计费应用之间的语义连接关系；所述编排组合为根据计费应用之间的依赖关系建立的，包括：

所述编排组合为根据计费应用之间的依赖关系，根据要实现的功能构建的。

Images