CN108989072A - 一种部署、管理及调用组件的方法及装置 - Google Patents

Abstract

本申请实施例公开了一种部署、管理及调用组件的方法及装置。针对每个客户端版本，在服务端部署该客户端版本对应的组件组，其中，该客户端版本对应的组件组中的各服务组件与该客户端版本的客户端中的各应用组件一一匹配。如此一来，倘若某个客户端版本下线，服务端便可以直接删除该客户端版本对应的组件组，从而使得服务端上不会囤积过多的服务组件，同时，也无须技术人员长期监控每个服务组件被调用的情况，节省了管理成本。

Description

一种部署、管理及调用组件的方法及装置

技术领域

本申请涉及互联网技术领域，尤其涉及一种部署、管理及调用组件的方法及装置。

背景技术

在互联网技术领域，出于客户端轻量化的考虑，往往将某个功能所需的组件拆分为两部分，部署在客户端的组件称为应用组件，部署在服务端的组件称为服务组件。针对客户端的每个功能，该功能对应的应用组件与该功能对应的服务组件是匹配的(如支持的序列化协议相同、代码的业务逻辑一致等)，使得客户端基于应用组件与相匹配的服务组件能够顺利实现相应的功能。

当客户端更新时，客户端的部分或全部功能会得到更新，这意味着更新的功能对应的应用组件更新。实际应用中，有些用户并不会及时更新客户端，因而会出现不同的用户使用不同版本的客户端的情形。针对这多个版本的客户端都具有的某个功能(对应多个版本的应用组件)而言，为了保证可以实现该功能，就需要在服务端部署与这多个版本的应用组件一一对应的服务组件。

图1是现有的组件部署架构示意图。如图1所示，v表示版本，A～D表示功能，客户端从v7.0更新至v8.0，客户端的应用组件A从v1.0更新到v1.1，应用组件B从v1.0更新至v1.1，应用组件C(v1.0)未更新，新增应用组件D(v1.0)。虚线连接的是同一个功能对应的相匹配的应用组件和服务组件。

如今的客户端更新非常频繁，往往需要针对每种功能，在服务端上部署该功能对应的很多版本的服务组件，这导致服务端越来越臃肿。技术人员通常将一段时间内几乎不被调用的服务组件确定为冗余的服务组件(即不被任何版本的客户端所需要的服务组件)并将其删除，但是，这会要求技术人员必须长期监控每个服务组件被调用的情况，管理成本会过高。

发明内容

本申请实施例提供一种部署、管理及调用组件的方法及装置，以解决现有的部署组件的方法容易导致服务端臃肿的问题以及现有的管理组件的方法成本过高的问题。

为解决上述技术问题，本申请实施例是这样实现的：

本申请实施例提供的一种部署组件的方法，包括：

针对每个客户端版本，确定该客户端版本的客户端中的各应用组件；

根据各应用组件，确定与各应用组件分别匹配的服务组件；

在服务端部署由确定出的各服务组件组成的组件组，以及建立该客户端版本与部署的组件组之间的对应关系。

本申请实施例提供的一种管理组件的方法，包括：

针对每个客户端版本，确定该客户端版本对应的使用状态数据；

根据所述使用状态数据，管理该客户端版本对应的组件组。

本申请实施例提供的一种调用组件的方法，包括：

接收调用请求；

根据发送所述调用请求的客户端的客户端版本，确定所述客户端版本对应的组件组；

从所述组件组中确定出所述客户端请求调用的服务组件，以供所述客户端调用。

本申请实施例提供的一种部署组件的装置，包括：

第一确定模块，针对每个客户端版本，确定该客户端版本的客户端中的各应用组件；

第二确定模块，根据各应用组件，确定与各应用组件分别匹配的服务组件；

部署模块，在服务端部署由确定出的各服务组件组成的组件组，以及建立该客户端版本与部署的组件组之间的对应关系。

本申请实施例提供的一种管理组件的装置，包括：

确定模块，针对每个客户端版本，确定该客户端版本对应的使用状态数据；

管理模块，根据所述使用状态数据，管理该客户端版本对应的组件组。

本申请实施例提供的一种调用组件的装置，包括：

接收模块，接收调用请求；

第一确定模块，根据发送所述调用请求的客户端的客户端版本，确定所述客户端版本对应的组件组；

第二确定模块，从所述组件组中确定出所述客户端请求调用的服务组件，以供所述客户端调用。

本申请实施例提供的一种部署组件的设备，包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

针对每个客户端版本，确定该客户端版本的客户端中的各应用组件；

根据各应用组件，确定与各应用组件分别匹配的服务组件；

部署由确定出的各服务组件组成的组件组，以及建立该客户端版本与部署的组件组之间的对应关系。

本申请实施例提供的一种管理组件的设备，包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

针对每个客户端版本，确定该客户端版本对应的使用状态数据；

根据所述使用状态数据，管理该客户端版本对应的组件组。

本申请实施例提供的一种调用组件的设备，包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

接收调用请求；

根据发送所述调用请求的客户端的客户端版本，确定所述客户端版本对应的组件组；

从所述组件组中确定出所述调用请求所要调用的服务组件，以供所述客户端调用。

由以上本申请实施例提供的技术方案可见，在本申请实施例中，针对每个客户端版本，在服务端部署该客户端版本对应的组件组，其中，该客户端版本对应的组件组中的各服务组件与该客户端版本的客户端中的各应用组件一一匹配。如此一来，倘若某个客户端版本下线，服务端便可以直接删除该客户端版本对应的组件组，从而使得服务端上不会囤积过多的服务组件，同时，也无须技术人员长期监控每个服务组件被调用的情况，节省了管理成本。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是现有的组件部署架构示意图；

图2是本申请实施例提供的一种部署组件的流程图；

图3是本申请实施例提供的组件部署架构示意图；

图4是现有的另一种组件部署架构示意图；

图5是本申请实施例提供的一种管理组件的方法流程图；

图6是本申请实施例提供的一种调用组件的方法流程图；

图7是本申请实施例提供的一种部署组件的装置示意图；

图8是本申请实施例提供的一种管理组件的装置示意图；

图9是本申请实施例提供的一种调用组件的装置示意图；

图10是本申请实施例提供的一种部署组件的设备示意图；

图11是本申请实施例提供的一种管理组件的设备示意图；

图12是本申请实施例提供的一种调用组件的设备示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

图2是本申请实施例提供的一种部署组件的方法流程图，包括以下步骤：

S201：针对每个客户端版本，确定该客户端版本的客户端中的各应用组件。

本方法的执行主体可以是服务器或由多个服务器构成的集群。

在本申请实施例中，确定该客户端版本的客户端中的各应用组件，具体可以是确定该客户端版本的客户端中的每个应用组件的配置信息。其中，应用组件的配置信息具体可以包含两个方面的信息：1、应用组件对应的功能；2、应用组件的版本信息，如支持的序列化协议(Json、protobuf等)、代码的业务逻辑、要求的参数或格式等。可见，不同功能的应用组件的配置信息是不同的，功能相同却版本不同的应用组件的配置信息也是不同的。

服务器可以获取每个客户端版本对应的配置文件，每个客户端版本对应的配置文件中记载了该客户端版本的客户端中的各应用组件的配置信息。每个客户端版本对应的配置文件可以是维护客户端的技术人员提供的，也可以是服务器从每个客户端版本的客户端对应的电子文件夹中直接获取的。

进一步地，服务器可以在每个客户端版本准备上线时，获取该客户端版本对应的配置文件，以确定该客户端版本的客户端中的各应用组件；也可以一并获取已经上线的若干客户端版本分别对应的配置文件，以确定每个上线的客户端版本的客户端中的各应用组件。

S202：根据各应用组件，确定与各应用组件分别匹配的服务组件。

如前所述，相匹配的应用组件与服务组件对应同一功能，且业务逻辑一致、支持的序列化协议相同、要求的参数或格式均相同等。

因此，在本申请实施例中，服务器在确定了该客户端版本的客户端中的各应用组件的配置信息之后，就可以确定与各应用组件分别匹配的服务组件。

其中，服务器可以根据各应用组件，依据预先设置的组件生成规则，生成与各应用组件分别匹配的服务组件；也可以根据各应用组件，发出配置请求，以请求技术人员配置与各应用组件分别匹配的服务组件；还可以根据各应用组件，在预先存储的若干服务组件中，选择出与各应用组件分别匹配的服务组件。

S203：在服务端部署由确定出的各服务组件组成的组件组，以及建立该客户端版本与部署的组件组之间的对应关系。

在本申请实施例中，针对每个客户端版本，服务器将确定出的与该客户端版本的客户端中的各应用组件一一匹配的服务组件组成组件组，将之部署在服务端。此外，服务器还可以建立该组件组与该客户端版本的对应关系，具体而言，可建立并保存该组件组的组标识与该客户端版本的版本标识之间的对应关系。

可见，在步骤S203中，实际上是以客户端版本为标准，在服务端上部署组件组的。各组件组的关系可以是物理隔离，也可以是逻辑隔离。以下对物理隔离和逻辑隔离作进一步说明。

在互联网技术领域，通常将承载若干组件，并为这若干组件提供执行环境的设备或虚拟空间称为一个容器。在现有的组件部署架构中，如图1所示，每个客户端版本的客户端都是一个容器，例如客户端v7.0是一个容器。当然，服务端也是一个容器。

而在本申请实施例中，实际上是将服务端这一容器进一步隔离成若干与各客户端版本一一对应的容器。当隔离成的若干容器是硬件设备时，即是物理隔离；当隔离成的若干容器是虚拟空间时，即是逻辑隔离。本申请对各组件组之间是物理隔离还是逻辑隔离不作限制。

图3是本申请实施例提供的组件部署架构示意图。如图3所示，部署在服务端的各组件组与各客户端版本一一对应。并且，举例来说，客户端v7.0中的各应用组件与组件组v7.0中的各服务组件一一匹配。

通过图2所示的部署组件的方法，针对每个客户端版本，在服务端部署该客户端版本对应的组件组，其中，该客户端版本对应的组件组中的各服务组件与该客户端版本的客户端中的各应用组件一一匹配。如此一来，倘若某个客户端版本下线，服务端便可以直接删除该客户端版本对应的组件组，从而使得服务端上不会囤积过多的服务组件，同时，也无须技术人员长期监控每个服务组件被调用的情况，节省了管理成本。

此外，在现有技术中，还存在另一种组件部署架构，如图4所示。在图4中，虚线连接的应用组件与服务组件是匹配的。针对每个功能，仅在服务端部署该功能对应的一个服务组件，该服务组件的代码较为复杂，可以兼容该功能对应的多个版本的应用组件。例如，服务组件A可以兼容应用组件A(v1.0-v1.1)，倘若应用A(v1.0)支持的序列化协议为Json，应用组件A(v1.1)支持的序列化协议为protobuf，那么就要求服务组件A既可以支持Json，也可以支持protobuf。

实际上，由于图1所示的组件部署架构会造成服务端较为臃肿，对服务端的数据处理效率影响较大，因此，图4所示的组件部署架构在本技术领域更为常见。但是，当采用图4所示的组件部署架构时，由于能够兼容多个版本的应用组件的服务组件的代码必定非常复杂，技术人员需要维护每个服务组件的代码的成本是非常高的。而通过本申请实施例提供的图3所示的组件部署架构，同样可以解决技术人员维护服务组件的成本高的问题。组件组中的每个服务组件只需要与一个版本的应用组件匹配，即具有一种业务逻辑、支持一种序列化协议即可。

图5是本申请实施例提供的一种管理组件的方法流程图，包括以下步骤：

S501：针对每个客户端版本，确定该客户端版本对应的使用状态数据。

图5所示的管理组件的方法基于图3所示的组件部署架构。本方法的执行主体是服务端对应的服务器。

在本申请实施例中，客户端版本对应的使用状态数据是可以反映客户端版本使用状态的数据。客户端版本对应的使用状态数据可以是客户端版本的在线状态对应的数据或下线状态对应的数据，例如，在线状态对应的数据为1，下线状态对应的数据为0。

客户端版本对应的使用状态数据也可以是客户端版本的使用量。客户端版本的使用量具体可以是客户端版本的客户端被用户使用的频次，也可以是客户端版本的客户端单位时间内传输的数据的流量。

当然，客户端版本对应的使用状态数据还可以是其他反应客户端版本使用状态的数据，本申请对此不作限制。

S502：根据所述使用状态数据，管理该客户端版本对应的组件组。

在本申请实施例中，服务器可以根据每个客户端版本的各种类型的使用状态数据来管理该客户端版本对应的组件组。具体如何管理视业务场景而定。

例如，若所述使用状态数据是在线状态对应的数据或下线状态对应的数据，则当该客户端版本是下线状态时，服务器可以删除该客户端版本对应的组件组。

又如，若所述使用状态数据是使用量时，根据所述使用量，对承载该客户端版本对应的组件组的设备进行扩容或缩容。具体而言，可以根据所述使用量，计算承载该客户端版本对应的组件组的设备的目标容量；根据所述目标容量，对所述设备进行扩容缩容。进一步地，当所述目标容量大于所述设备的实际容量时，对所述设备进行扩容，当所述目标容量小于所述设备的实际容量时，对所述设备进行缩容。

此处值得强调的是，在现有的部署及管理组件的方法中，客户端版本的使用量与承载客户端版本对应的服务组件的设备的容量是没有动态关联关系的。新上线的客户端版本的使用量可能会经历由小到大的增长过程，这就要求承载该客户端版本对应的各服务组件的设备的容量能够保持同幅度的增长。然而，对服务端而言，由于目前不存在可用的组件管理工具，服务端的技术人员无法获知该客户端版本对应的服务组件有哪些，也就无法对承载该客户端版本对应的各服务组件的设备进行扩容。在本申请实施例中，通过部署每个客户端版本对应的组件组，可以实现客户端版本的使用量与承载对应的组件组的设备的容量之间的动态关联。

通过图5所示的管理组件的方法，服务组件以组件组为单位进行组织，服务端能够以较粗的粒度批量管理服务端上部署的组件组中的服务组件，如删除组件组、扩容承载组件组的设备等，而不必深入到服务组件的粒度上对服务组件进行管理和维护。

图6是本申请实施例提供的一种调用组件的方法流程图，包括以下步骤：

S601：接收调用请求。

图6所示的方法基于图3所示的组件部署架构。本方法的执行主体可以是服务端对应的服务器或网关服务器。当执行主体是网关服务器时，网关服务器根据客户端发送的调用请求，路由到服务端上的某个服务组件。其中，网关服务器中存储有客户端版本与组件组之间的对应关系，并且，网关服务器可以兼容多种通信协议，如SPDY、HTTP等。如此一来，服务端不必存储客户端版本与组件组之间的对应关系，也不必兼容多种通信协议，客户端调用服务组件的效率得以提升。

在本申请实施例中，所述调用请求可以包含发送调用请求的客户端的客户端版本的版本标识和请求调用的服务组件的组件标识。其中，服务组件的组件标识可以是服务端分配给服务组件的编号，也可以是服务组件对应的功能的标识。

S602：根据发送所述调用请求的客户端的客户端版本，确定所述客户端版本对应的组件组。

S603：从所述组件组中确定出所述客户端请求调用的服务组件，以供所述客户端调用。

若不存在所述客户端版本对应的组件组，则通知所述客户端进行升级。

实际应用中，某个客户端版本可能因为存在技术漏洞而下线。而现有的部署与管理组件的方法，无法将存在技术漏洞的客户端版本对应的服务组件删除，导致恶意用户依然可以利用技术漏洞调用这些本该删除的服务组件，进行非法操作，威胁客户端的安全性。

而在本申请提供的部署与管理组件的方法中，倘若某个客户端版本下线，服务端可以将该客户端版本对应的组件组删除。如此一来，倘若已经下线的客户端版本的客户端请求调用相应的服务组件，网关服务器会根据存储的客户端版本与组件组的对应关系，确定该客户端版本对应的组件组已经被删除，无法提供组件调用服务，并通知该客户端版本的客户端进行升级。

基于图2所示的部署组件的方法，本申请实施例还对应提供了部署组件的装置，如图7所示，包括：

第一确定模块701，针对每个客户端版本，确定该客户端版本的客户端中的各应用组件；

第二确定模块702，根据各应用组件，确定与各应用组件分别匹配的服务组件；

部署模块703，在服务端部署由确定出的各服务组件组成的组件组，以及建立该客户端版本与部署的组件组之间的对应关系。

基于图5所示的管理组件的方法，本申请实施例还对应提供了管理组件的装置，如图8所示，包括：

确定模块801，针对每个客户端版本，确定该客户端版本对应的使用状态数据；

管理模块802，根据所述使用状态数据，管理该客户端版本对应的组件组。

所述使用状态数据，具体包括：在线状态对应的数据或下线状态对应的数据；

所述管理模块802，当该客户端版本是下线状态时，删除该客户端版本对应的组件组。

所述使用状态数据，具体包括：使用量；

所述管理模块802，根据所述使用量，对承载该客户端版本对应的组件组的设备进行扩容或缩容。

基于图6所示的调用组件的方法，本申请实施例还对应提供了调用组件的装置，如图9所示，包括：

接收模块901，接收调用请求；

第一确定模块902，根据发送所述调用请求的客户端的客户端版本，确定所述客户端版本对应的组件组；

第二确定模块903，从所述组件组中确定出所述客户端请求调用的服务组件，以供所述客户端调用。

所述装置还包括：通知模块904，若不存在所述客户端版本对应的组件组，则通知所述客户端版本的客户端进行升级。

基于图2所示的部署组件的方法，本申请实施例还对应提供了部署组件的设备，如图10所示。该部署组件的设备包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

针对每个客户端版本，确定该客户端版本的客户端中的各应用组件；

根据各应用组件，确定与各应用组件分别匹配的服务组件；

部署由确定出的各服务组件组成的组件组，以及建立该客户端版本与部署的组件组之间的对应关系。

基于图5所示的管理组件的方法，本申请实施例还对应提供了管理组件的设备，如图11所示。该管理组件的设备包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

针对每个客户端版本，确定该客户端版本对应的使用状态数据；

根据所述使用状态数据，管理该客户端版本对应的组件组。

基于图6所示的调用组件的方法，本申请实施例还对应提供了调用组件的设备，如图12所示。该调用组件的设备包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

接收调用请求；

根据发送所述调用请求的客户端的客户端版本，确定所述客户端版本对应的组件组；

从所述组件组中确定出所述调用请求所要调用的服务组件，以供所述客户端调用。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于图10～12所示的部署组件的设备、管理组件的设备、调用组件的设备而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (15)

1.一种部署组件的方法，包括：

针对每个客户端版本，确定该客户端版本的客户端中的各应用组件；

根据各应用组件，确定与各应用组件分别匹配的服务组件；

在服务端部署由确定出的各服务组件组成的组件组，以及建立该客户端版本与部署的组件组之间的对应关系。

2.一种管理组件的方法，包括：

针对每个客户端版本，确定该客户端版本对应的使用状态数据；

根据所述使用状态数据，管理该客户端版本对应的组件组。

3.根据权利要求2所述的方法，所述使用状态数据，具体包括：在线状态对应的数据或下线状态对应的数据；

根据所述使用状态数据，管理该客户端版本对应的组件组，具体包括：

当根据所述使用状态数据，确定该客户端版本是下线状态时，删除该客户端版本对应的组件组。

4.根据权利要求2所述的方法，所述使用状态数据，具体包括：使用量；

根据所述使用状态数据，管理该客户端版本对应的组件组，具体包括：

根据所述使用量，对承载该客户端版本对应的组件组的设备进行扩容或缩容。

5.一种调用组件的方法，包括：

接收调用请求；

根据发送所述调用请求的客户端的客户端版本，确定所述客户端版本对应的组件组；

从所述组件组中确定出所述调用请求所要调用的服务组件，以供所述客户端调用。

6.根据权利要求5所述的方法，所述方法还包括：

若不存在所述客户端版本对应的组件组，则通知所述客户端进行升级。

7.一种部署组件的装置，包括：

第一确定模块，针对每个客户端版本，确定该客户端版本的客户端中的各应用组件；

第二确定模块，根据各应用组件，确定与各应用组件分别匹配的服务组件；

部署模块，在服务端部署由确定出的各服务组件组成的组件组，以及建立该客户端版本与部署的组件组之间的对应关系。

8.一种管理组件的装置，包括：

确定模块，针对每个客户端版本，确定该客户端版本对应的使用状态数据；

管理模块，根据所述使用状态数据，管理该客户端版本对应的组件组。

9.根据权利要求8所述的装置，所述使用状态数据，具体包括：在线状态对应的数据或下线状态对应的数据；

当根据所述使用状态数据，确定该客户端版本是下线状态时，删除该客户端版本对应的组件组。

10.根据权利要求8所述的装置，所述使用状态数据，具体包括：使用量；

所述管理模块，根据所述使用量，对承载该客户端版本对应的组件组的设备进行扩容或缩容。

11.一种调用组件的装置，包括：

接收模块，接收调用请求；

第一确定模块，根据发送所述调用请求的客户端的客户端版本，确定所述客户端版本对应的组件组；

第二确定模块，从所述组件组中确定出所述客户端请求调用的服务组件，以供所述客户端调用。

12.根据权利要求11所述的装置，所述装置还包括：

通知模块，若不存在所述客户端版本对应的组件组，则通知所述客户端进行升级。

13.一种部署组件的设备，包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

针对每个客户端版本，确定该客户端版本的客户端中的各应用组件；

根据各应用组件，确定与各应用组件分别匹配的服务组件；

部署由确定出的各服务组件组成的组件组，以及建立该客户端版本与部署的组件组之间的对应关系。

14.一种管理组件的设备，包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

针对每个客户端版本，确定该客户端版本对应的使用状态数据；

根据所述使用状态数据，管理该客户端版本对应的组件组。

15.一种调用组件的设备，包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

接收调用请求；

根据发送所述调用请求的客户端的客户端版本，确定所述客户端版本对应的组件组；

从所述组件组中确定出所述调用请求所要调用的服务组件，以供所述客户端调用。