专利名称：分布式服务系统、分布式服务系统的任务执行方法和装置的制作方法
技术领域：
本申请涉及通信和计算机技术领域，特别是涉及分布式服务系统、分布式服务 系统的任务执行方法和装置。
背景技术：
随着J2EE技术的发展，越来越多的服务系统都基于J2EE技术来创建。如，银 行系统、账单系统和网上购物系统等。为了使服务系统提供更高的可靠性、可扩展性和 容错性，目前基于J2EE技术的服务系统常采用分布式的集群方案。请参阅图1，其为现有技术中一种分布式服务系统的场景示意图。如图1所示， 在分布式服务系统中部署了多个应用服务器，在用户和应用服务器之间还设置了一个负 载均衡器或者代理服务器。当用户发送Web请求到负载均衡器后，负载均衡器根据服务 系统中各个应用服务器当前的负载情况，将Web请求分发到其中一个负载小的应用服务 器，由该应用服务器上的应用系统执行Web请求的任务。并且。当服务系统中一个应 用服务器执行失败时，负载均衡器将Web请求重新分发到其它应用服务器上，保证系统 的正常运行。可见，在现有的分布式服务系统中，每个应用服务器上都内置有一个完整 的应用系统以执行分配给自身的Web任务。例如，在每个应用服务器中都内置有一个销 售系统，当应用服务器1被分配一个Web请求后，由应用服务器1内置的销售系统执行 Web请求的任务。然而，发明人在研究中发现，在应用系统中，不同的业务功能对资源的需求是 不同的，例如，在销售系统中，实现计费功能时需要进行大数据量的数据统计，因此， 实现计费功能时对内存资源的需求大，而相对地，实现菜单管理时并不需要大量的内存 资源。在现有技术中，是将整个应用系统进行集群，每个应用服务器上都内置有功能相 同的应用系统，没有考虑到应用系统中不同的业务功能对资源需求的差异性，因此，这 种以整个应用系统为集群粒度的分布式服务系统比较浪费系统资源。
发明内容
为了解决上述技术问题，本申请实施例提供了分布式服务系统、分布式服务系 统的任务执行方法和装置，以节约系统资源。本申请实施例公开了如下技术方案—种分布式服务系统，包括一个任务分配器和一个应用服务器集群，其中， 所述应用服务器集群包括至少两个应用服务器，用于实现应用系统的基本配置的基本模 块分布在应用服务器集群中的每一个应用服务器上，用于实现应用系统的业务功能的各 个业务模块按照重要程度越高分布的应用服务器越多的规则，分布在应用服务器集群中 的应用服务器上；所述任务分配器上配置有各个业务模块在所述应用服务器集群中的位 置，以便当接收到用户的服务请求时，根据所述位置将服务请求分配到对应的应用服务 器上。
一种在分布式服务系统中执行任务的方法，包括接收用户的服务请求；根据 配置的应用系统中的各个业务模块在应用服务器集群中的位置，查找执行所述服务请求 的业务模块所在的应用服务器；将所述服务请求分配给查找到的应用服务器，以便由查 找到的应用服务器上的业务模块执行所述服务请求。一种在分布式服务系统中执行任务的装置，包括请求接收单元，用于接收用 户的服务请求；查找单元，用于根据配置的应用系统中的各个业务模块在应用服务器集 群中的位置，查找执行所述服务请求的业务模块所在的应用服务器；任务执行单元，用 于将所述服务请求分配给查找到的应用服务器，以便由查找到的应用服务器上的业务模 块执行所述服务请求。由上述实施例可以看出，本申请实施例改变了传统方式中对整个应用系统进行 分布式部署的模式，而是将应用系统分解为基本模块和业务模块，并基于重要程度对业 务模块进行分布式部署。这种架构为使用带来了更大的灵活性。对于重要程度高的业务 模块，例如，对于资源耗费大的业务模块或者使用频率较高的业务模块，可以采用分布 式部署的方式，而对于资源耗费小的业务模块或者使用频率较低的业务模块，可以不采 用分布式部署的方式。即，在本申请的分布式服务系统中，以业务模块为集群粒度，与 传统的以整个应用系统为集群粒度相比，可以更加有针对性地进行部署，节约了系统资 源。
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或 现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人 员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。图1为现有技术中一种分布式服务系统的场景示意图；图2为本申请一种分布式服务系统的一个实施例的结构示意图；图3为本申请一种分布式的销售系统的一个结构示意图；图4为本申请一种分布式的销售系统的另一个结构示意图；图5为本申请一种分布式服务系统的另一个实施例的结构示意图；图6为本申请一种分布式的销售系统的另一个结构示意图；图7为本申请一种在分布式服务系统中执行任务的方法的一个实施例的流程 图；图8为本申请一种在分布式服务系统中执行任务的装置的一个实施例的结构示 意图；图9为本申请的分布式服务系统中查找单元的一个结构示意图。
具体实施例方式为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申 请实施例进行详细描述。实施例一请参阅图2，其为本申请一种分布式服务系统的一个实施例的结构示意图。该分布式服务系统包括一个任务分配器201和一个应用服务器集群202，其中，应用服务 器集群202包括至少两个应用服务器，用于实现应用系统的基本配置的基本模块分布在 应用服务器集群202中的每一个应用服务器上，用于实现应用系统的业务功能的各个业 务模块按照重要程度越高分布的应用服务器越多的规则，分布在应用服务器集群202中 的应用服务器上；任务分配器201上配置有各个业务模块在所述应用服务器集群中的位 置，以便当接收到用户的服务请求时，根据所述位置将服务请求分配到对应的应用服务 器上。在本申请实施例中，将应用系统拆分成两个部分，一部分为实现应用系统的基 本配置的基本模块，另一部分为实现应用系统的业务功能的各个业务模块。其中，基本 模块分布在应用服务器集群中的每一个应用服务器上，各个业务模块按照重要程度越高 分布的应用服务器越多的规则，分布在应用服务器集群中的应用服务器上。例如，为了便于描述，假设分布式服务系统中的应用服务器集群包括4个应用 服务器，仅将销售系统拆分为实现基本配置的基本模块、实现计费功能的计费模块和实 现菜单管理功能的菜单管理模块三个模块。基本模块分布在应用服务器集群的4个应用 服务器上，对于销售系统来说，计费模块的重要程度高于菜单管理模块，因此，计费模 块分布的应用服务器要多于菜单管理模块。如，一种简单的分布方式是，将计费模块分 布在应用服务器集群中的第1-3个应用服务器上，将菜单管理模块分布在第4个应用服务 器上。请参阅图3，其为本申请一种分布式的销售系统的一个结构示意图。当然，还可 以有其它的分布方式，如，还可以根据实际的使用需要将计费模块分布在应用服务器集 群中的4个应用服务器上，将菜单管理模块分布在任意一个应用服务器上。本申请实施 例对业务模块的分布方式不再一一列举。需要说明的是，按照每个应用系统的实际业务逻辑划分业务模块，由于每一个 应用系统都具有其自身的特异性，因此，本申请实施例对业务模块具体的划分方式不进 行限定。还需要说明的是，划分后的业务模块按照重要程度越高分布的应用服务器越多 的规则，分布在应用服务器集群中的应用服务器上，由于每一个应用系统都具有其自身 的特异性，划分出的业务模块也各不相同，划分后的业务模块的重要程度在每个业务系 统中也各不相同，因此，本申请实施例对业务模块具体的分布方式也不进行限定。当 然，当划分的各个业务模块的重要程度相同是，也可以出现每个业务模块只分布在一个 应用服务器的结果，此时，每个业务模块可以与其他业务模块部署在同一个应用服务器 上，也可以单独部署在一个应用服务器上，本申请实施例对此并不限定。在本申请实施例中，任务分配器201上配置有各个业务模块在所述应用服务器 集群中的位置，以便当接收到用户的服务请求时，根据所述位置将服务请求分配到相应 的应用服务器上。如，在图3的销售系统中，当任务分配器接收到菜单管理请求时，根据各个业 务模块在应用服务器集群中的位置，获知执行菜单管理请求的菜单管理模块所在的应用 服务器为应用服务器4，将菜单管理请求分配到应用服务器4上。上述的重要程度包括业务模块被访问频率、业务模块耗费资源的程度和被其它 业务模块调用的次数中的任意一个或者任意多个的组合。
例如，业务模块被访问的频率越高，该业务模块的重要程度越高，反之，该业 务模块的重要程度越低。业务模块耗费资源的程度越大，该业务模块的重要程度越高， 反之，该业务模块的重要程度越低。业务模块被其它业务模块调用的次数越多，该业务 模块的重要程度越高，反之，该业务模块的重要程度越低。当业务模块分布在至少两个应用服务器上时，如图3中的计费模块，任务分配 器201上还配置有业务模块所在的至少两个应用服务器的选择顺序。例如，图3中的计 费模块分布在3个应用服务器上，则在图3中的任务分配器上还配置有3个应用服务器上 的选择顺序，如，当选择顺序依次为应用服务器1、应用服务器2和应用服务器3时， 如果服务系统接收到用户发送的计费请求，则任务分配器按照选择顺序，将计费请求先 分配到应用服务器1上，由应用服务器1上的计费模块执行计费功能。一旦应用服务器 1执行失败，为了保证服务系统的稳定性，按照选择顺序，再将计费请求分配到应用服务 器2上，进一步由应用服务器2上的计费模块执行计费功能。在分布式的服务系统中，当业务模块调用其它业务模块且被调用业务模块分布 在至少两个应用服务器上时，则在调用业务模块所在的应用服务器上还配置有调用业务 模块所在的应用服务器与被调用业务模块所在的应用服务器之间的对应关系。例如，请参阅图4，其为本申请一种分布式的销售系统的另一个结构示意图。如 图4所示，在该销售系统中，菜单管理模块在运行时需要调用计费模块，且计费模块分 布在2个应用服务器上。在菜单管理模块所在的应用服务器4上设置有菜单管理模块所 在的应用服务器与计费模块所在的应用服务器之间的对应关系，如，设置了菜单管理模 块所在的应用服务器4与计费模块所在的应用服务器1之间的对应关系。当菜单管理模 块需要调用计费模块时，根据该对应关系可以调用应用服务器1上的计费模块。另外， 如图4所示，如果计费系统中还存在其他业务模块X也需要调用计费模块，还可以在业 务模块X所在的应用服务器3上设置业务模块X所在的应用服务器3与计费模块所在的 其它应用服务器，即，应用服务器3与应用服务器2之间的对应关系，以保证业务模块X 调用应用服务器2上的计费模块。当然，在分布式的服务系统中，当调用其它模块的业务模块分布在至少两个应 用服务器上，且被调用业务模块也分布在至少两个应用服务器上时，可以按照上述方 式，同时在任务分配器和调用业务模块所在的应用服务器上进行配置。具体过程可以参 见上述内容，此处不再赘述。由上述实施例可以看出，本申请实施例改变了传统方式中对整个应用系统进行 分布式部署的模式，而是将应用系统分解为基本模块和业务模块，并基于重要程度对业 务模块进行分布式部署。这种架构为使用带来了更大的灵活性。对于重要程度高的业务 模块，例如，对于资源耗费大的业务模块或者使用频率较高的业务模块，可以采用分布 式部署的方式，而对于资源耗费小的业务模块或者使用频率较低的业务模块，可以不采 用分布式部署的方式。即，在本申请的分布式服务系统中，以业务模块为集群粒度，与 传统的以整个应用系统为集群粒度相比，可以更加有针对性地进行部署，节约了系统资 源。实施例二请参阅图5，其为本申请中一种分布式服务系统的另一个实施例的结构图。在分布式服务系统中，当业务模块分布在至少两个应用服务器上时，所述系统还包括一个负 载均衡器203，负载均衡器203用于根据负载平衡原则从业务模块所在的至少两个应用服 务器中选择一个应用服务器。例如，请参阅图6，其为本申请一种分布式的销售系统的另一个结构示意图。图 6所示，计费模块分布在3个应用服务器上，分布式服务系统中的负载均衡器根据负载平 衡原则从3个应用服务器上选择应用服务器1，以便将服务请求分配到应用服务器1上。由于任务分配器201和应用服务器集群202已经在实施例一中进行了详细地说 明，故此处不再赘述。需要说明的是，本申请实施例对负载均衡器上执行的负载均衡算法并不进行限 定，可以采用现有技术中任意一种算法。同样，在包含负载均衡器的分布式服务系统中，当调用其它模块的业务模块分 布在至少两个应用服务器上，且被调用业务模块也分布在至少两个应用服务器上时，也 可以同时利用负载均衡器，以及在调用业务模块所在的应用服务器上进行配置。具体过 程可以参见实施例一和实施例二的内容，此处不再赘述。其中，重要程度包括业务模块被访问频率、业务模块耗费资源的程度和被其它 业务模块调用的次数中的任意一个或者任意多个的组合。由上述实施例可以看出，本申请实施例改变了传统方式中对整个应用系统进行 分布式部署的模式，而是将应用系统分解为基本模块和业务模块，并基于重要程度对业 务模块进行分布式部署。这种架构为使用带来了更大的灵活性。对于重要程度高的业务 模块，例如，对于资源耗费大的业务模块或者使用频率较高的业务模块，可以采用分布 式部署的方式，而对于资源耗费小的业务模块或者使用频率较低的业务模块，可以不采 用分布式部署的方式。即，在本申请的分布式服务系统中，以业务模块为集群粒度，与 传统的以整个应用系统为集群粒度相比，可以更加有针对性地进行部署，节约了系统资 源。实施例三以上述图2中的分布式服务系统为基础，本申请实施例还提供了一种在上述分 布式服务系统中执行任务的方法。结合图2，请参阅图7，其为本申请一种在分布式服务 系统中执行任务的方法的一个实施例的流程图，包括以下步骤步骤701 接收用户的服务请求；步骤702:根据配置的应用系统中的各个业务模块在应用服务器集群中的位 置，查找执行所述服务请求的业务模块所在的应用服务器；例如，如图3所示，在分布式销售系统中，将整个销售系统划分为实现销售系 统基本配置的基本模块、计费模块和菜单管理模块。基本模块分布在应用服务器集群的 所有应用服务器上，计费模块分布在应用服务器1-3上，菜单管理模块分布在应用服务 器4上。当接收到用户的菜单管理请求时，根据配置销售系统中的各个业务模块在应用 服务器集群中的位置，查找到执行菜单管理请求的菜单管理模块所在的应用服务器为应 用服务器4。在查找执行所述服务请求的业务模块所在的应用服务器过程中，当执行服务请 求的业务模块分布在至少两个应用服务器上时，可以由负载均衡器根据负载平衡原则动态地选择一个应用服务器，也可以在任务分配器上进行静态的配置。在此情况下，所述根据配置的应用系统中的各个业务模块在应用服务器集群中 的位置，查找执行所述服务请求的业务模块所在的应用服务器包括当执行所述服务请 求的业务模块分布在至少两个应用服务器上时，触发负载均衡器根据负载均衡原则从业 务模块所在的至少两个应用服务器中选择一个应用服务器；接收负载均衡器返回的选择 结果，将所述选择结果作为查找到的应用服务器。例如，如图6所示，当接收到用户的计费请求时，由于执行计费请求的计费模 块分布在3个应用服务器上，任务分配器触发负载均衡器根据负载平衡原则从计费模块 所在的3个应用服务器中选择一个应用服务器，如，选择了应用服务器1，负载均衡器将 选择结果返回给任务分配器，任务分配器接收负载均衡器返回的选择结果，将选择的结 果作为查找到的应用服务器。或者，所述根据配置的应用系统中的各个业务模块在应用服务器集群中的位 置，查找执行所述服务请求的业务模块所在的应用服务器包括当执行所述业务请求的 业务模块分布在至少两个应用服务器上时，根据配置的业务模块所在的至少两个应用服 务器的选择顺序选择一个应用服务器，将选择的应用服务器作为查找到的应用服务器。例如，如图3所示的消费系统，在任务分配器上配置有计费模块所在的3个应用 服务器的选择顺序，当任务分配器接收到用户的计费请求时，根据自身配置的计费模块 所在的3个应用服务器的选择顺序，从中选择应用服务器1。在查找执行所述服务请求的业务模块所在的应用服务器过程中，当业务模块调 用其它业务模块且被调用业务模块分布在至少两个应用服务器上时，在调用模块所在的 应用服务器上进行静态配置。在此情况下，所述根据配置的应用系统中的各个业务模块在应用服务器集群中 的位置，查找执行所述服务请求的业务模块所在的应用服务器包括当执行所述服务请 求的业务模块调用其它业务模块且被调用业务模块分布在至少两个应用服务器上时，触 发调用业务模块所在的应用服务器根据配置的调用业务模块所在的应用服务器与被调用 业务模块所在的应用服务器之间的对应关系选择一个应用服务器，以便调用业务模块所 在的应用服务器将所述请求任务发送给选择的应用服务器。例如，如图4所示，在该销售系统中，菜单管理模块在运行时需要调用计费模 块，且计费模块分布在2个应用服务器上。在菜单管理模块所在的应用服务器4上设置 有菜单管理模块所在的应用服务器与计费模块所在的应用服务器之间的对应关系，如， 设置了菜单管理模块所在的应用服务器4与计费模块所在的应用服务器1之间的对应关 系。当任务分配器接收到用户的菜单管理请求时，根据配置的应用系统中的各个业务模 块在应用服务器集群中的位置，查找执行菜单管理请求的菜单管理模块所在的应用服务 器为应用服务器4，任务分配器将菜单管理请求分配到应用服务器4上。而菜单管理模块 在运行时需要进一步调用计费模块，应用服务器4上配置有菜单管理模块所在的应用服 务器与计费模块所在的应用服务器之间的对应关系，如，设置了菜单管理模块所在的应 用服务器4与计费模块所在的应用服务器1之间的对应关系。因此，当菜单管理模块需 要调用计费模块时，应用服务器4将菜单管理请求发送给应用服务器1，由应用服务器1 上的计费模块执行计费功能。
当然，在分布式的服务系统中，当调用其它模块的业务模块分布在至少两个应 用服务器上，且被调用业务模块也分布在至少两个应用服务器上时，可以按照上述方 式，同时在任务分配器和调用业务模块所在的应用服务器上进行配置。具体过程可以参 见上述内容，此处不再赘述。步骤703:将所述服务请求分配给查找到的应用服务器，以便由查找到的应用 服务器上的业务模块执行所述服务请求。由上述实施例可以看出，本申请实施例改变了传统方式中对整个应用系统进行 分布式部署的模式，而是将应用系统分解为基本模块和业务模块，并基于重要程度对业 务模块进行分布式部署。这种架构为使用带来了更大的灵活性。对于重要程度高的业务 模块，例如，对于资源耗费大的业务模块或者使用频率较高的业务模块，可以采用分布 式部署的方式，而对于资源耗费小的业务模块或者使用频率较低的业务模块，可以不采 用分布式部署的方式。即，在本申请的分布式服务系统中，以业务模块为集群粒度，与 传统的以整个应用系统为集群粒度相比，可以更加有针对性地进行部署，节约了系统资 源。实施例四与上述一种在分布式服务系统中执行任务的方法相对应，本申请实施例还提供 了一种在分布式服务系统中执行任务的装置。请参阅图8，其为本申请一种在分布式服务 系统中执行任务的装置的一个实施例的结构示意图，包括请求接收单元801、查找单 元802和任务执行单元803。下面结合该装置的工作原理进一步介绍其内部结构以及连接 关系。请求接收单元801，用于接收用户的服务请求；查找单元802，用于根据配置的应用系统中的各个业务模块在应用服务器集群中 的位置，查找执行所述服务请求的业务模块所在的应用服务器；任务执行单元803，用于将所述服务请求分配给查找到的应用服务器，以便由查 找到的应用服务器上的业务模块执行所述服务请求。其中，在查找执行所述服务请求的业务模块所在的应用服务器过程中，当执行 服务请求的业务模块分布在至少两个应用服务器上时，请参阅图9，其为本申请的分布式 服务系统中查找单元的一个结构示意图。如图9所示，查找单元802包括第一触发子 单元8011和选择结果接收子单元8012，第一触发子单元8011，用于当执行所述服务请求的业务模块分布在至少两个应 用服务器上时，触发负载均衡器根据负载均衡原则从业务模块所在的至少两个应用服务 器中选择一个应用服务器；选择结果接收子单元8012，用于接收负载均衡器返回的选择结果，将所述选择 结果作为查找到的应用服务器。可替换的，查找单元802包括选择子单元，用于当执行所述业务请求的业务 模块分布在至少两个应用服务器上时，根据配置的业务模块所在的至少两个应用服务器 的选择顺序选择一个应用服务器，将选择的应用服务器作为查找到的应用服务器。可替换的，查找单元802包括第二触发子单元，用于当执行所述服务请求的 业务模块调用其它业务模块且被调用业务模块分布在至少两个应用服务器上时，触发调用业务模块所在的应用服务器根据配置的调用业务模块所在的应用服务器与被调用业务 模块所在的应用服务器之间的对应关系选择一个应用服务器，以便调用业务模块所在的 应用服务器将所述请求任务发送给选择的应用服务器。需要说明的是，在分布式的服务系统中，当调用其它模块的业务模块分布在至 少两个应用服务器上，且被调用业务模块也分布在至少两个应用服务器上时，此时，查 找单元802既包括第一触发子单元和选择结果接收子单元，又包括第二触发子单元，或 者，包括查找单元802选择子单元和第二触发子单元。由上述实施例可以看出，本申请实施例改变了传统方式中对整个应用系统进行 分布式部署的模式，而是将应用系统分解为基本模块和业务模块，并基于重要程度对业 务模块进行分布式部署。这种架构为使用带来了更大的灵活性。对于重要程度高的业务 模块，例如，对于资源耗费大的业务模块或者使用频率较高的业务模块，可以采用分布 式部署的方式，而对于资源耗费小的业务模块或者使用频率较低的业务模块，可以不采 用分布式部署的方式。即，在本申请的分布式服务系统中，以业务模块为集群粒度，与 传统的以整个应用系统为集群粒度相比，可以更加有针对性地进行部署，节约了系统资 源。需要说明的是，本领域普通技术人员可以理解实现上述实施例方法中的全部或 部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计 算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其 中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随 机存储记忆体(Random AccessMemory，RAM)等。以上对本申请所提供的一种分布式服务系统、分布式服务系统的任务执行方法 和装置进行了详细介绍，本文中应用了具体实施例对本申请的原理及实施方式进行了阐 述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本 领域的一般技术人员，依据本申请的思想，在具体实施方式
及应用范围上均会有改变之 处，综上所述，本说明书内容不应理解为对本申请的限制。
权利要求
1.一种分布式服务系统，其特征在于，包括一个任务分配器和一个应用服务器集 群，其中，所述应用服务器集群包括至少两个应用服务器，用于实现应用系统的基本配置的基本模块分布在应用服务器集群中的每一个应用服 务器上，用于实现应用系统的业务功能的各个业务模块按照重要程度越高分布的应用服 务器越多的规则，分布在应用服务器集群中的应用服务器上；所述任务分配器上配置有各个业务模块在所述应用服务器集群中的位置，以便当接 收到用户的服务请求时，根据所述位置将服务请求分配到对应的应用服务器上。
2.根据权利要求1所述的分布式服务系统，其特征在于，当业务模块分布在至少两个 应用服务器上时，所述系统还包括一个负载均衡器，所述负载均衡器用于根据负载平衡 原则从业务模块所在的至少两个应用服务器中选择一个应用服务器。
3.根据权利要求1所述的分布式服务系统，其特征在于，当业务模块分布在至少两个 应用服务器上时，所述任务分配器上还配置有业务模块所在的至少两个应用服务器的选 择顺序。
4.根据权利要求1-3中的任意一项所述的分布式服务系统，其特征在于，当业务模块 调用其它业务模块且被调用业务模块分布在至少两个应用服务器上时，在调用业务模块 所在的应用服务器上还配置有调用业务模块所在的应用服务器与被调用业务模块所在的 应用服务器之间的对应关系。
5.根据权利要求1所述的分布式服务系统，其特征在于，所述重要程度包括业务模块 被访问频率、业务模块耗费资源的程度和被其它业务模块调用的次数中的任意一个或者 任意多个的组合。
6. —种在权利要求1所述的分布式服务系统中执行任务的方法，其特征在于，包括接收用户的服务请求；根据配置的应用系统中的各个业务模块在应用服务器集群中的位置，查找执行所述 服务请求的业务模块所在的应用服务器；将所述服务请求分配给查找到的应用服务器，以便由查找到的应用服务器上的业务 模块执行所述服务请求。
7.根据权利要求6所述的方法，其特征在于，所述根据配置的应用系统中的各个业务 模块在应用服务器集群中的位置，查找执行所述服务请求的业务模块所在的应用服务器 包括当执行所述服务请求的业务模块分布在至少两个应用服务器上时，触发负载均衡器 根据负载均衡原则从业务模块所在的至少两个应用服务器中选择一个应用服务器；接收负载均衡器返回的选择结果，将所述选择结果作为查找到的应用服务器。
8.根据权利要求6所述的方法，其特征在于，所述根据配置的应用系统中的各个业务 模块在应用服务器器集群中的位置，查找执行所述服务请求的业务模块所在的应用服务 器包括当执行所述业务请求的业务模块分布在至少两个应用服务器上时，根据配置的业务 模块所在的至少两个应用服务器的选择顺序选择一个应用服务器，将选择的应用服务器 作为查找到的应用服务器。
9.根据权利要求6-8中的任意一项所述的方法，其特征在于，所述根据配置的应用系 统中的各个业务模块在应用服务器集群中的位置，查找执行所述服务请求的业务模块所 在的应用服务器包括当执行所述服务请求的业务模块调用其它业务模块且被调用业务模块分布在至少 两个应用服务器上时，触发调用业务模块所在的应用服务器根据配置的调用业务模块所 在的应用服务器与被调用业务模块所在的应用服务器之间的对应关系选择一个应用服务 器，以便调用业务模块所在的应用服务器将所述请求任务发送给选择的应用服务器。
10.—种在权利要求1所述的分布式服务系统中执行任务的装置，其特征在于，包括请求接收单元，用于接收用户的服务请求；查找单元，用于根据配置的应用系统中的各个业务模块在应用服务器集群中的位 置，查找执行所述服务请求的业务模块所在的应用服务器；任务执行单元，用于将所述服务请求分配给查找到的应用服务器，以便由查找到的 应用服务器上的业务模块执行所述服务请求。
11.根据权利要求10所述的装置，其特征在于，所述查找单元包括第一触发子单元，用于当执行所述服务请求的业务模块分布在至少两个应用服务器 上时，触发负载均衡器根据负载均衡原则从业务模块所在的至少两个应用服务器中选择 一个应用服务器；选择结果接收子单元，用于接收负载均衡器返回的选择结果，将所述选择结果作为 查找到的应用服务器。
12.根据权利要求10所述的装置，其特征在于，所述查找单元包括选择子单元，用于当执行所述业务请求的业务模块分布在至少两个应用服务器上 时，根据配置的业务模块所在的至少两个应用服务器的选择顺序选择一个应用服务器， 将选择的应用服务器作为查找到的应用服务器。
13.根据权利要求10-12任意一项所述的装置，其特征在于，所述查找单元包括 第二触发子单元，用于当执行所述服务请求的业务模块调用其它业务模块且被调用业务模块分布在至少两个应用服务器上时，触发调用业务模块所在的应用服务器根据配 置的调用业务模块所在的应用服务器与被调用业务模块所在的应用服务器之间的对应关 系选择一个应用服务器，以便调用业务模块所在的应用服务器将所述请求任务发送给选 择的应用服务器。
全文摘要
本申请实施例公开了分布式服务系统、分布式服务系统的任务执行方法和装置。其中，分布式服务系统包括一个任务分配器和一个应用服务器集群，其中，所述应用服务器集群包括至少两个应用服务器，用于实现应用系统的基本配置的基本模块分布在应用服务器集群中的每一个应用服务器上，用于实现应用系统的业务功能的各个业务模块按照重要程度越高分布的应用服务器越多的规则，分布在应用服务器集群中的应用服务器上；所述任务分配器上配置有各个业务模块在所述应用服务器集群中的位置，以便当接收到用户的服务请求时，根据所述位置将服务请求分配到对应的应用服务器上。根据本申请实施例，可以节约系统资源。
文档编号H04L29/08GK102014169SQ20101060176
公开日2011年4月13日 申请日期2010年12月22日 优先权日2010年12月22日
发明者刘歆一, 方国, 王能 申请人:北京中电普华信息技术有限公司