CN105827567B - 服务管控方法及能力开放平台 - Google Patents

Abstract

本发明公开一种服务管控方法和能力开放平台；所述方法包括：从服务端获取服务端各个服务插件的管控信息；所述管控信息为依据所述服务插件的注册信息以及状态信息形成的信息；依据所述管控信息，确定响应服务请求的服务插件的标识信息；及向服务端发送携带有所述标识信息的服务请求。

Description

服务管控方法及能力开放平台

技术领域

本发明涉及信息处理领域的信息处理技术，尤其涉及一种服务管控方法及能力开放平台。

背景技术

随着互连网的发展，各大互联网企业都在做能力开放平台。能力开放平台将集中开放可提供服务的接口，进行资源的统一分配和流量管控，从而实现开放接口的统一管理。而能力开放平台开放的接口众多，服务复杂，要求能力开放平台具备高可用、高可扩展及高稳定性。

为了简化能力开放平台的管理，提出了一种基于模块化的OSGi架构。所述OSGi为Open Service Gateway Initiative的缩写。OSGi架构通常是面向Java 的动态模型系统，提供了基于类、模块、服务的模块化热插拔支持，提供了在线的服务加载、更新及卸载的能力。

当OSGi架构中的插件Bundle随着开发增多时，会逐步出现以下问题：程序整体运行缓慢、运行时不稳定、较难定位运行时错误、庞大程序主体发布困难。所述插件为OSGi架构中的处理模块，通常为具有独立运行处理业务逻辑的单元组件。

针对上述问题，现有技术中又提出了分布式OSGi架构，即R-OSGi架构。 R-OSGi架构包括多个满足OSGi架构的分布式组件。这些组件以JAR 的形式发布，部署容易，使用也较为便捷。所述JAR为以Java语言形成的归档文件，是一种与平台无关的文件格式，它允许将许多文件组合成一个压缩文件。

现有的分布式R-OSGi架构包括两端，分别是服务端A和客户端B。服务端A通过R-OSGi框架将服务注册到服务端A的OGSi架构上，并声明该服务为远程调用服务。服务端A的R-OSGi在服务端的操作系统上利用一个端口来创建套接字Socket监听该服务。客服端B将其本地的R-OSGi放到客户端B 的本地OSGi运行环境中。客户端B利用统一资源地址URI，通过远程调用接口调用服务端A中的服务。

在现有方法中，R-OSGi框架能够将一个独立运行的OSGi应用程序分割成若干个，并让每个独立的OSGi服务部署在自己独立领域的服务上，实现了 OSGi分布式部署，每个OSGi都具备了模块化热插拔支持，提供了在线的服务加载、更新及卸载的能力。

通常每个服务插件只有一份，每个客户端需要明确的知道所需调用服务的统一资源地址URI。如果需要替换一个服务插件，在替换的过程中将无法通过客户端为用户提供服务。如果当前的服务已挂死或宕机，当前这个服务将中断，在该服务重新启好之前，就无法通过客户端向用户提供服务。

与此同时，在现有R-OSGi框架下，服务的扩容只能通过对客户端、服务端的成对服务进行扩容，无法仅新增客户端或仅新增服务端。显然服务端的资源不能得到充分利用，服务扩容难度大；新增部署服务插件时，客户端需要针对新增服务插件配置客户端URI，客户端URI相对应的也需要进行新的开发和部署，增加了新服务部署的开发工作量，增加了新服务部署的难度和复杂度。

发明内容

有鉴于此，本发明实施例期望提供一种服务管控方法及能力开放平台，以对服务进行管控并减少选择当前不能提供服务的服务插件来响应服务请求的现象。

为达到上述目的，本发明的技术方案是这样实现的：

本发明实施例第一方面提供一种服务管控方法，所述方法包括：

从服务端获取服务端各个服务插件的管控信息；所述管控信息为依据所述服务插件的注册信息以及状态信息形成的信息；

依据所述管控信息，确定响应服务请求的服务插件的标识信息；

向服务端发送携带有所述标识信息的服务请求。

优选地，

所述依据所述管控信息，确定响应服务请求的服务插件的标识信息，包括：

依据所述服务请求，形成服务申请；

响应所述服务申请，查询所述管控信息并依据查询的结果确定响应所述服务请求的服务插件的标识信息。

优选地，

所述方法还包括：

当所述管控信息包括有新服务插件的注册信息时，依据所述新服务的注册信息形成并存储所述注册信息。

优选地，

所述管控信息包括服务插件的标识信息；

所述管控信息还包括当前并发连接数、最大连接数、负载权值以及服务状态的至少其中之一。

本发明实施例第二方面提供一种服务管控方法，所述方法包括：

监控各服务插件的当前状态，形成状态信息；

依据所述状态信息及所述服务插件的注册信息，形成管控信息；

所述管控信息用于确定响应服务请求的服务插件。

优选地，

当检测到有新的服务插件加载时，获取所述服务插件的注册信息。

本发明实施例第三方面提供一种能力开放平台，所述能力开放平台包括客户端；

所述客户端包括第一R-OSGi框架；所述第一R-OSGi框架配置有第一服务监控单元及第一服务管控单元

所述第一服务监控单元，用于从服务端获取服务端各个服务插件的管控信息；所述管控信息为依据所述服务插件的注册信息以及状态信息形成的信息；

所述第一服务管控单元，用于依据所述管控信息，确定响应服务请求的服务插件的标识信息；

所述第一R-OSGi框架，还用于向服务端发送携带有所述标识信息的服务请求。

优选地，

所述第一R-OSGi框架还配置有服务调度单元；

所述服务调度单元，用于依据所述服务请求，形成服务申请；

所述第一服务管控单元，具体用于响应所述服务申请，查询所述管控信息并依据查询的结果确定响应所述服务请求的服务插件的标识信息。

优选地，

所述第一R-OSGi框架还配置有第一服务注册单元；

所述第一服务注册单元，用于当管控信息包括有新服务的注册信息时，依据所述新服务的注册信息形成所述注册信息，并将所述注册信息存储到所述第一服务管控单元。

本发明实施例第四方面提供一种能力开放平台，所述能力开放平台包括服务端；

所述服务端包括第二R-OSGi框架；所述第二R-OSGi框架配置有第二服务监控单元及第二服务管控单元；

所述第二服务监控单元，用于监控各服务插件的当前状态，形成状态信息；

所述第二服务管控单元，用于依据所述状态信息及所述服务插件的注册信息，形成管控信息；

所述管控信息用于确定响应服务请求的服务插件。

优选地，

所述第二R-OSGi框架还配置有第二服务注册单元；

所述第二服务注册单元，用于当检测到有新的服务插件加载时，获取所述服务插件的注册信息。

本发明实施例服务管控方法及能力开放平台，客户端在发送服务请求时，将首先根据从服务端获取的管控信息，确定出当前可响应所述服务请求的服务插件的标识信息，并使所述服务请求携带所述标识信息发送给服务端，以便服务端根据所述标识信息确定服务插件并响应所述服务请求。这样能够避免将选择不能响应服务请求的服务插件来响应所述服务请求，这样显然能够提高服务请求的响应成功率及用户使用满意度。

附图说明

图1为一种能力开放平台的结构示意图；

图2为本发明实施例所述的服务管控方法的流程示意图之一；

图3为本发明实施例所述的服务管控方法的流程示意图之二；

图4为本发明实施例所述的服务管控方法的流程示意图之三；

图5为本发明实施例所述的客户端的结构示意图之一；

图6为本发明实施例所述的客户端的结构示意图之二；

图7为本发明实施例所述的服务端的结构示意图之一；

图8为本发明实施例所述的服务端的结构示意图之二；

图9为本发明实施例所述的能力开放平台的结构示意图之一；

图10为本发明实施例所述的能力开放平台的结构示意图之二。

具体实施方式

以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。

方法实施例一：

如图2所示，本实施例提供一种服务管控方法，所述方法包括：

步骤S110：从服务端获取服务端各个服务插件的管控信息；所述管控信息为依据所述服务插件的注册信息以及状态信息形成的信息；

步骤S120：依据所述管控信息，确定响应服务请求的服务插件的标识信息；

步骤S130：向服务端发送携带有所述标识信息的服务请求。

本实施例所述的服务管控方法，可应用于能力开放平台，具体如用于以R-OSGi框架的能力开放平台的客户端。所述客户端为设置有客户端接口，所述客户端接口用于接收用户的服务请求；具体如图1中的客户端B中。

所述管控信息为提供服务的服务端对各个服务的注册信息和当前状态进行监控形成的信息。

所述管控信息可以包括两部分；一部分为静态的注册信息，另一部分为动态的状况信息。所述注册信息可包括可提供的服务、每个服务的标识信息或获取服务的服务地址；所述服务地址可为统一资源地址URL。每一个服务支持的并发连接数；每个服务的负载权重。所述负载权重为每个服务的负载值。具体如服务A和服务B为两余额查询服务；若服务A的负重权重为2；服务B的负载权重为1；则所述服务A可提供的负载量是所述服务B的负载量的两倍。

所述状态信息可包括当前每一个服务的最大并发连接数、当前并发连接数、负载权值以及服务状态等信息。所述服务状态可包括停用状态、加载状态、卸载状态以及启用状态等。

在步骤S120中根据所述管控信息，可以确定出哪一个服务当前可用，或者到一个服务地址中获取该服务。具体如服务C支持的最大连接数为10；若当前已经建立了10个连接，则此时继续发送服务请求将不被响应；故在本实施例中所述客户端可以延迟发送所述服务请求或拒绝所述服务请求。

在具体实现时，服务端提供同一种类型的服务不止一个服务；在本实施例中一个服务通常由一个服务插件来实现。具体如，在服务端提供缴费查询服务的服务插件有2个，分别是服务插件c和服务插件d；每一个服务支持的连接数为N；N为正整数。

在步骤S120中依据所述管控信息确定出，其中，服务插件c的当前并发连接数为N，则服务c不能在建立服务连接，为用户提供缴费查询服务；但是发现此时服务插件d的当前并发连接数小于N，可以为用户提供缴费查询服务，则此时，确定出响应所述服务请求的服务插件为服务插件d，获取服务插件d 的标识信息，将所述服务插件d的标识信息携带在所述服务请求中发送给服务端。由服务端的服务插件d提供缴费查询服务。此处，服务插件d的标识信息可以为所述服务插件d提供服务的统一资源地址或域名地址等具有标识性作用的信息。

在具体实现时，所述管控信息还可以是对所述注册信息和状态信息进行处理之后的汇总信息。具体如，当前服务插件d配置的连接数为N个，当前已用了n个连接；所述管控信息包括的服务插件d的可用连接数为N-n个。

作为本实施例的进一步改进，所述步骤S120可包括：

依据所述服务请求，形成服务申请；

响应所述服务申请，查询所述管控信息并依据查询的结果确定响应所述服务请求的服务插件的标识信息。

当所述客户端接口接收到用户设备发送的服务请求之后，依据所述服务请求形成一个服务申请；并根据所述服务申请查询所述管控信息，确定出响应所述服务请求的服务插件。本实施例在上一实施例的基础上，进一步确定了如何进行响应服务请求的服务插件的确定，具有实现简便的优点。

显然本实施例所述服务管控方法，可以很好的避免依据所述管控信息，确定出哪些服务插件出现挂死或宕机状况，某一服务插件出现挂死或宕机状况时，就不会被确定为响应服务请求的服务插件，从而解决了现有技术中在不知道服务插件当前状况信息的情况下，导致向已经出现挂死或宕机的服务插件请求服务，导致服务请求没有响应的问题。

所述方法还包括：

当管控信息包括有新服务的注册信息时，依据所述新服务的注册信息形成并存储所述注册信息。

在本实施例中当服务端有记载新服务插件的注册信息时，将会呈现在所述管控信息中，客户端通过所述管控信息将确定出服务端当前有哪些服务插件，这些服务插件能够提供哪些服务，每一个服务的支持的连接数等信息。客户端通过从服务端获取所述管控信息，简便的知道了服务端有新增服务插件，显然服务端新增了服务插件，但是客户端的结构并没有发生相应的变化，显然简化了工作人员在能力开放平台上部署服务的难度，同时也简化了能力开放平台的服务配置的，能力开放平台的服务扩容更加简便，服务端的资源能够得到更为有效的利用。

在具体实现时，服务端上配置有R-OSGi框架，所述R-OSGi框架配置有多个服务插件；每一个服务插件都能提供一个对应的服务。

所述R-OSGi框架上还配置有Socket监听接口；在所述步骤S110中，客户端通过定时的扫描所述Socket监听接口，可以获得所述管控信息。在具体实现时，一个服务端会对应多台客户端；若干个客户端可以采用轮询的方式扫描所述Socket监听接口，以获得所述管控信息。

在具体实现时，能力开放平台中为每一个服务均建立对应的注册信息；且所述注册信息可以形成以表格的信息存储，形成服务注册表。所述服务注册表中记录该服务的注册信息。在所述服务插件运行一段时间后，将根据所述状态信息更新所述服务注册表，在所述服务注册表中增添、修改或删除对应的状态信息。此时，所述服务注册表中将包括注册信息和状态信息，即相当所述管控信息。相当于所述管控信息的所述服务注册表中将包括服务插件的标识信息、当前并发连接数、最大连接数、负载权值、负载阀值以及服务状态等信息。

方法实施例二：

如图3所示，本实施例提供一种服务管控方法，所述方法包括：

步骤S210：监控各服务插件的当前状态，形成状态信息；

步骤S220：依据所述状态信息及所述服务插件的注册信息，形成管控信息；

所述管控信息用于确定响应服务请求的服务插件。

本实施例所述的服务管控方法可应用于能力开放平台的服务端。通常所述服务端上设置有R-OSGi框架；所述R-OSGi框架配置有多个服务插件以及与所述客户端对接的接口。

在本实施例中R-OSGi框架接收到所述服务请求。所述服务请求中携带的标识信息可为提供服务请求所请求服务的统一资源地址URL。

在本实施例中所述监控各服务插件的当期状态信息包括扫描与客户端对接的端口，确定当前各个所述服务插件的连接数等信息；所述步骤S210还可包括扫描运行有服务插件的端口，根据这些端口信息可以获知对应的服务插件的当前状态是服务状态、停用状态或卸载状态等信息。具体如，所述第二服务监控单元可用于对应用程序编程接口API进行流量监控，获取所述API当前的连接数。

在具体实现时，所述服务端将接收客户端发送的服务请求，所述服务请求中将携带响应所述服务请求的服务插件的标识信息，依据所述标识信息确定所述响应服务插件的请求，并依据所述服务请求更新所述服务插件的当前信息，具体如所述服务插件当前的连接数等信息。

步骤S220中的注册信息为服务插件注册时形成的信息，通常均为所述服务插件的静态的配置信息，具体如最大连接数、负载权值及所述服务插件的服务地址等信息。

如图4所示，本实施例所述的方法还包括：

步骤S200：当检测到有新的服务插件加载时，获取所述服务插件的注册信息。

本实施例所述的方法会对每一个服务形成对应管控信息，所述管控信息用于为确定响应所述服务请求的服务插件提供依据，在本实施例中具体为用于客户端确定响应所述服务请求的服务插件提供依据，由各个客户端来确定响应对应服务请求的服务插件，这样能够减少提供服务的服务端的负载，避免服务端过于繁忙进而导致的服务请求时延大的问题。

设备实施例一：

如图5所示，本实施例提供一种能力开放平台，所述能力开放平台包括客户端；

所述客户端包括第一R-OSGi框架；所述第一R-OSGi框架配置有第一服务监控单元及第一服务管控单元

所述第一服务监控单元110，用于从服务端获取服务端各个服务插件的管控信息；所述管控信息为依据所述服务插件的注册信息以及状态信息形成的信息；

所述第一服务管控单元120，用于依据所述管控信息，确定响应服务请求的服务插件的标识信息；

所述第一R-OSGi框架，还用于向服务端发送携带有所述标识信息的服务请求。

本实施例所述第一R-OSGi框架为分布式OSGi框架，其上配置有多个插件；每一个插件可提供一种服务。如配置在所述第一R-OSGi框架上的第一服务监控插件即为构成所述第一服务监控单元110的组成结构。再比如，配置在所述第一R-OSGi框架上的第一服务管控插件即为构成所述第一服务管控单元120 的组成结构。

在具体实现时，所述客户端包括处理器、存储介质和外部通信接口；所述存储介质上存储有多个插件；所述服务端分别通过总线等内部通信接口分别与所述存储介质和所述外部通信接口相连；所述处理器通过运行所述插件，可以实现所述第一服务监控单元和所述第一管控单元的功能。所述处理器可以应用处理器AP、中央处理器CPU、微处理器MCU、数字信号处理器DSP或可编程阵列PLC等具有信息处理功能的电子元器件。所述外部通信接口包括接收用户设备发送的服务请求的通信接口，还可包括用于向服务端发送所述服务请求的通信接口。

所述第一R-OSGi框架为封装在所述客户端上的一种模块化功能实体，为各个插件提供安装空间，形成上述功能单元。

如图6所示，所述第一R-OSGi框架还配置有服务调度单元130

所述服务调度单元130，用于依据所述服务请求，形成服务申请；

所述第一服务管控单元120用于响应所述服务申请，查询所述管控信息并依据查询的结果确定响应所述服务请求的服务插件的标识信息。

所述第一R-OSGi框架还配置有第一服务注册单元；

所述第一服务注册单元140，用于当管控信息包括有新服务的注册信息时，依据所述新服务的注册信息形成所述注册信息，并将所述注册信息存储到所述第一服务管控单元120。所述第一服务注册单元140的组成部分可为包括安装在所述第一R-OSGi框架的第一服务注册插件。

本实施例所述的客户端可为方法实施例所述的服务管控方法提供实现硬件，且作为本实施例中所述能力开放平台的构成部件之一；同样能够起到避免选择不能提供服务的服务插件来响应所述服务请求的优点。

且本实施例中通过所述第一服务监控单元110、第一服务管控单元120、服务调度单元130等结构的配置，在所述服务端配置新的服务插件时，能够通过获知所述管控信息来实现对新的服务插件的调用，而不用在本实施例所述的客户端中配置对应的服务插件，从而简化了能力开放平台的服务扩容的工作，且能够避免客户端的性能参数局限与服务端的资源的利用。

图6所示的服务注册表即为所述依据注册信息和状态信息形成的管控信息的一种，所述管控信息由所述第一服务监控单元从服务端获取之后，通过所述第一服务注册单元140发送到所述第一服务管控单元120；在具体实现时，也可以由所述第一服务监控单元110直接发送给所述第一服务管控单元。所述第一管控单元，用于依据所述服务申请查询服务注册表，确定可以响应所述服务请求的服务插件的标识信息，并将所述标识信息通过所述服务调度单元130返回给第一R-OSGi，方便所述第一R-OSGi携带所述标识信息向服务端发送所述服务请求。

设备实施例二：

如图7所示，本实施例提供一种能力开放平台，所述能开放平台包括服务端；

所述服务端包括第二R-OSGi框架；所述第二R-OSGi框架配置有第二服务监控单元及第二服务管控单元；

第二R-OSGi框架，用于接收服务请求；

第二服务监控单元210，用于监控各服务插件的当前状态，形成状态信息；

第二服务管控单元220，用于依据所述状态信息及所述服务插件的注册信息，形成管控信息；

所述管控信息用于确定响应服务请求的服务插件。

本实施例所述第二R-OSGi框架为分布式OSGi框架，其上配置有多个插件；每一个插件可提供一种服务。如配置在所述第二R-OSGi框架上的第二服务监控插件即为构成所述第一服务监控单元210的组成结构。再比如，配置在所述第二R-OSGi框架上的第二服务管控插件即为构成所述第二服务管控单元220 的组成结构。

在具体实现时，所述客户端包括处理器、存储介质和外部通信接口；所述存储介质上存储有多个插件；所述服务端分别通过总线等内部通信接口分别与所述存储介质和所述外部通信接口相连；所述处理器通过运行所述插件，可以实现所述第二服务监控单元和所述第二管控单元的功能。所述处理器可以应用处理器AP、中央处理器CPU、微处理器MCU、数字信号处理器DSP或可编程阵列PLC等具有信息处理功能的电子元器件。

所述外部通信接口可包括用于接收客户端发送的服务请求的接收端口，还包括可包括客户端扫描获取所述管控信息的端口。所述外部通信接口可为有线接口或无线接口；所述有线接口可包括光缆接口或电缆接口；所述无线接口可包括收发天线等结构。

如图8所示，所述第二R-OSGi框架还配置有第二服务注册单元230；

所述第二服务注册单元230，用于当检测到有新的服务插件加载时，获取所述服务插件的注册信息。所述第二服务注册单元230的组成部分可为包括安装在所述第一R-OSGi框架的第二服务注册插件。

在图8中，当所述第二R-OSGi框架接收到客户单的服务请求之后，将服务请求发送到对应的服务插件来响应所述服务请求；所述第二服务监控单元 210会对所述第二R-OSGi框架进行监控，对各个服务插件的状态信息进行更新，并将所述状态更新提交到所述第二服务管控单元220中。所述第二服务注册单元230在检测到第二R-OSGi框架有加载新的服务插件时，将进行服务注册，形成注册信息存储到所述第二服务管控单元220中。

综合上述，本实施例所述的服务端可以用于实现方法实施例一中所述的方法，同样的具有能够避免选择不能响应服务请求的服务插件来响应服务请求的问题，同样的本实施例所述的客户端还能在所述第二R-OSGi框架加载对应的服务插件后通过所述第二服务管控单元220形成的管控信息告知客户端即可，无需在服务端形成对应的服务插件，可以简化能力开放平台的服务扩能，且能避免客户端的资源局限服务端资源的利用的问题。

以下结合上述任意实施例提供几个具体示例：

如图9所示，为在现有R-OSGi基础上的改进之后形成的能力开放平台。所述能力开放平台包括客户端和服务端；客户端和服务端通过网络连接。所述网络可以为有线网或无线网。

在客户端中新增了服务调用插件(Bundle)、服务注册插件(Bundle)、服务监控插件(Bundle)、服务管控插件(Bundle)；这些插件都是安装在客户端的R-OSGi 框架上的，且这些插件均能实现热插拔。所述服务调用插件对应于上述实施例中的服务调度单元、所述服务注册插件对应于所述第一服务注册单元；所述服务监控插件(Bundle)对应于所述第一服务监控单元；所述服务管控插件(Bundle) 对应于所述第一服务管控单元。

在服务端新增了服务注册插件、服务监控插件及服务管控插件。所述服务注册插件对应于上述实施例中的第二服务注册单元；所述服务监控插件对应于上述实施例中的第二服务监控单元；所述服务管控插件对应于上述实施例中的第二服务管控单元。

现有原始R-OSGi架构在响应服务请求时，如图9中实线箭头所表示的，客户端接口接收用户设备发送的服务请求，由客户端的R-OSGi框架以远程调用的方式，将所述服务请求提交给服务端的R-OSGi框架；服务端的R-OSGi 框架将所述服务请求发送给服务插件，由服务插件远程响应所述服务请求。

在本示例中所述能力开放平台还利用在所述客户端和所述服务端上新增的插件对服务进行管控，具体的管控流程可以如图中虚线箭头所示。

服务端的服务注册插件(Bundle)，用于在服务端中的R-OSGi新增了服务插件时进行服务注册，形成服务注册表；具体如对API进行流量监控，确定所述服务端的R-OSGi是否有新增新的BundleContext类，并获取该类可支持的连接数等垂直信息。所述服务注册插件获取这些信息之后，将这些信息提交到服务端的服务管控插件，由服务管控插件进行信息处理，形成上述实施例所述的管控信息。

服务端的服务监控插件，用来实现对各个服务插件进行服务状态监控、服务连接数监控及自动注册远程服务等监控，根据监控结果服务状态监控对各个服务插件进行服务更新，并将更新的信息提交到所述服务管控插件。

在进行所述服务连接数监控时，服务端的服务监控插件可以通过服务的请求线程数的监控来确定各个服务插件当前已形成的服务连接数。

在进行所述自动注册远程服务时，服务端的服务监控插件可以扫描指定范围内的端口，来确定对应的服务插件是处于启动状态、关闭状态还是注册或卸载状态。

服务管控插件(Bundle)可用于通过一个服务注册表完成对服务插件的管控，可通过管理服务插件的注册信息和状态信息，实现对每一个管理每个服务插件的管控。所述服务注册表为依据所述注册信息和所述状态信息形成的，具体可包括当前并发连接数、最大连接数、负载权值、负载阀值、服务状态及最近调用时间等。

此外，所述服务管控插件(Bundle)还用于封装了查询当前并发连接数、最大连接数、负载权值、负载阀值、服务状态及最近调用时间等方法，以方便客户端的中的服务监控插件的扫描。

客户端的服务监控插件通过扫描服务端中的服务管控插件，获取各个服务插件的服务注册表；并更新客户端中服务注册插件中的注册服务表。

客户端的服务注册插件将所述更新后的注册服务表发送给客户端的服务管控插件。

服务调用插件(Bundle)，可用于在客户端接口接收到用户设备的服务请求，客户端需要向服务端发起服务请求时，形成服务申请并将所述服务申请发送给服务管控插件。服务管控插件通过查询所述注册服务表，可知到当前服务端哪个服务插件在提供服务及可提供服务的服务负载量等信息，可依据所述注册服务表提供的信息以及服务请求所需的服务的信息，综合确定出由哪一个服务插件来提供服务。由于客户端的服务管控插件在确定响应服务请求的服务插件时，是参照了当前服务端各服务插件的管控信息来确定的，依据预设的确定规则，显然可以避开选择已经停用的服务插件来确定响应服务请求。

如图10所示的能力开放平台的服务端包括服务端A、服务端B以及服务端 C；能力开放平台的客户端包括客户端1、客户端2以及客户端3。客户端和服务端通过网络连接。

在服务端A的R-OSGi框架上部署有两个交费服务；在服务端B的R-OSGi 框架上部署有一个交费服务和一个交费服务；在服务端C的R-OSGi框架上部署有一个交费服务。

以下结合图9和图10提供一个服务监控的示例。若当前如果发现交费服务量较大且通过监控发现服务端C比较空闲。为了更加及时的响应交费服务请求，在服务端C的R-OSGi上再新增一个交费服务，具体流程如下：

1)优化或开发新的交费服务。

2)注册新的交费服务到插件，形成交费服务插件，并配置交费服务的并发数。

3)将新的交费服务服插件打包为JAR包，并部署新插件到服务端C上。

4)客户端C中的服务监控插件，扫描所有服务，发现服务端C上的交费服务端口开启，由服务注册插件将新的交费服务注册到服务管控插件，并在客户端的服务监控插件扫描所述服务管控插件对应的接口时，将所述新的交费服务注册到客户端中。

5)客户端R-OSGi框架调用交费服务时，通过服务调度插件，形成服务申请。

6)客户端服务管控插件接收到服务申请后，检查交费服务是否为报活状态并且该交费服务的并发连接数并未达到其最大并发连接数时，确定服务端C的交费服务健康检查后，再确定服务端C交费服务插件作为本次响应交费服务请求的服务插件，获取到服务端C地址，客户端R-OSGi向服务端C上的交费服务插件进行调用请求。

7)客户端的服务调度插件收到返回报文后，向服务端发送服务请求

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (7)

1.一种服务管控方法，应用于R-OSGi框架的能力开放平台的客户端，其特征在于，所述方法包括：

从服务端获取服务端各个服务插件的管控信息；所述管控信息为依据所述服务插件的注册信息以及状态信息形成的信息；

依据所述管控信息，确定响应服务请求的服务插件的标识信息，其中，所述依据所述管控信息，确定响应服务请求的服务插件的标识信息包括：根据所述状态信息选择当前状态能够响应所述服务请求的服务插件的标识信息；

向服务端发送携带有所述标识信息的服务请求。

2.根据权利要求1所述的方法，其特征在于，

所述依据所述管控信息，确定响应服务请求的服务插件的标识信息，包括：

依据所述服务请求，形成服务申请；

响应所述服务申请，查询所述管控信息并依据查询的结果确定响应所述服务请求的服务插件的标识信息。

3.根据权利要求1所述的方法，其特征在于，

所述方法还包括：

当所述管控信息包括有新服务插件的注册信息时，依据所述新服务的注册信息形成并存储所述注册信息。

4.根据权利要求1所述的方法，其特征在于，

所述管控信息包括服务插件的标识信息；

所述管控信息还包括当前并发连接数、最大连接数、负载权值以及服务状态的至少其中之一。

5.一种能力开放平台，其特征在于，所述能力开放平台包括客户端；

所述客户端包括第一R-OSGi框架；所述第一R-OSGi框架配置有第一服务监控单元及第一服务管控单元

所述第一服务监控单元，用于从服务端获取服务端各个服务插件的管控信息；所述管控信息为依据所述服务插件的注册信息以及状态信息形成的信息；

所述第一服务管控单元，用于依据所述管控信息，确定响应服务请求的服务插件的标识信息；其中，所述第一服务管控单元，具体用于根据所述状态信息选择当前状态能够响应所述服务请求的服务插件的标识信息；

所述第一R-OSGi框架，还用于向服务端发送携带有所述标识信息的服务请求。

6.根据权利要求5所述的能力开放平台，其特征在于，

所述第一R-OSGi框架还配置有服务调度单元；

所述服务调度单元，用于依据所述服务请求，形成服务申请；

所述第一服务管控单元，具体用于响应所述服务申请，查询所述管控信息并依据查询的结果确定响应所述服务请求的服务插件的标识信息。

7.根据权利要求5或6所述的能力开放平台，其特征在于，

所述第一R-OSGi框架还配置有第一服务注册单元；

所述第一服务注册单元，用于当管控信息包括有新服务的注册信息时，依据所述新服务的注册信息形成所述注册信息，并将所述注册信息存储到所述第一服务管控单元。

Images