基于服务调用的收益分配任务处理方法及装置

摘要

本发明属于金融领域或其他技术领域，本发明提供了一种基于服务调用的收益分配任务处理方法及装置，基于服务调用的收益分配任务处理方法包括：接收待分配的收益分配任务；对所述收益分配任务进行分片拆分，以生成收益分配子任务；以服务调用方式对所述收益分配子任务进行分片处理。本发明结合微服务及数据分片的设计理念，通过降低单个执行单元的执行数据量及提高并发执行思路，以提升整体收益分配的执行效率。

说明书

技术领域

本申请可用于金融领域或其他技术领域，具体涉及一种基于服务调用的收益分配任务处理方法及装置。

背景技术

随着经济发展，人民生活水平逐步提升，大众理财需求也逐步增强，另一方面理财公司中的货币类产品流通性高，符合多数低风险投资者的需求。货币类产品客户基数巨大，对于系统收益分配的处理效率提出更高的要求。传统收益分配批处理采用集中处理节点结合集中式关系型数据库实现收益分配，在数据量日益增长的情况下，存在较高的数据检索及串行处理耗时压力，整体处理效率无法满足业务处理要求。

发明内容

本发明属于金融领域或其他技术领域，本发明结合微服务及数据分片的设计理念，通过降低单个执行单元的执行数据量及提高并发执行思路，以提升整体收益分配的执行效率。

为解决上述技术问题，本发明提供以下技术方案：

接收待分配的收益分配任务；

对所述收益分配任务进行分片拆分，以生成收益分配子任务；

以服务调用方式对所述收益分配子任务进行分片处理。

一实施例中，所述对所述收益分配任务进行分片拆分，以生成收益分配子任务，包括：

按照多维度的方式对所述收益分配任务进行分片拆分；

所述多维度包括：理财产品维度、合作方维度以及客户维度。

一实施例中，所述以服务调用方式对所述收益分配子任务进行分片处理包括：

解析所述收益分配子任务，以确定所述收益分配子任务的分片信息；

利用分片算法，根据所述分片信息以及预设的收益分配规则对所述收益分配子任务进行处理。

一实施例中，所述对所述收益分配任务进行分片拆分，以生成收益分配子任务，还包括：

利用一致性HASH算法，根据客户唯一标识对所述收益分配任务进行分片拆分。

第二方面，本发明提供一种基于服务调用的收益分配任务处理装置，该装置包括：

任务分配单元，用于接收待分配的收益分配任务；

任务拆分单元，用于对所述收益分配任务进行分片拆分，以生成收益分配子任务；

分片处理单元，用于以服务调用方式对所述收益分配子任务进行分片处理。

一实施例中，所述任务拆分单元包括：

维度拆分模块，用于按照多维度的方式对所述收益分配任务进行分片拆分；

所述多维度包括：理财产品维度、合作方维度以及客户维度。

一实施例中，所述分片处理单元包括：

子任务解析模块，用于解析所述收益分配子任务，以确定所述收益分配子任务的分片信息；

子任务处理模块，用于利用分片算法，根据所述分片信息以及预设的收益分配规则对所述收益分配子任务进行处理。

一实施例中，所述任务拆分单元还包括：

一致性拆分模块，用于利用一致性HASH算法，根据客户唯一标识对所述收益分配任务进行分片拆分。

第三方面，本发明提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现基于服务调用的收益分配任务处理方法的步骤。

第四方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现基于服务调用的收益分配任务处理方法的步骤。

从上述描述可知，本发明实施例提供一种基于服务调用的收益分配任务处理方法及装置，首先接收待分配的收益分配任务；接着，对所述收益分配任务进行分片拆分，以生成收益分配子任务；最后以服务调用方式对所述收益分配子任务进行分片处理。本发明结合微服务及数据分片的设计理念，通过降低单个执行单元的执行数据量及提高并发执行思路，提升整体交易执行效率。主要达到以下有益效果：

1、结合微服务的松耦合的特点，有效将收益分配的调度与计算执行解耦，有效支撑业务规则多变性。

2、通过数据分片的思路，有效单个计算节点的计算数据量，并通过分片执行有效提供并发度，通过横向扩展能力有效提升需提系统扩展性。

3、通过有效自洽机制，实现数据最终一致性检查，保障执行结果的准确性。

附图说明

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

图1为本发明实施例中基于服务调用的收益分配任务处理方法的流程示意图；

图2为本发明实施例中步骤200的流程示意图一；

图3为本发明实施例中步骤300的流程示意图；

图4为本发明实施例中步骤200的流程示意图二；

图5为本发明具体应用实例中基于服务调用的收益分配任务处理装置的方块图；

图6为本发明具体应用实例中基于服务调用的收益分配任务处理装置的工作原理图；

图7为本发明具体应用实例中任务控制模块的方块图；

图8为本发明具体应用实例中执行器模块的方块图；

图9为本发明具体应用实例中数据存储模块的方块图；

图10为本发明具体应用实例中基于服务调用的收益分配任务处理方法的流程示意图；

图11为本发明具体应用实例中业务实例的示意图；

图12为本发明的实施例中基于服务调用的收益分配任务处理装置的结构示意图；

图13为本发明的实施例中任务拆分单元的结构示意图；

图14为本发明的实施例中分片处理单元的结构示意图；

图15为本发明的实施例中任务拆分单元的结构示意图；

图16为本发明的实施例中的电子设备的结构示意图。

具体实施方式

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

本发明的实施例提供一种基于服务调用的收益分配任务处理方法的具体实施方式，参见图1，其具体包括如下内容：

步骤100：接收待分配的收益分配任务。

目前，理财类别多种多样，理财客户数量同样也成千上万，这就导致了现有技术中，采用集中方式实现理财收益分配存在较高的数据检索及串行处理耗时压力的问题。

可以理解的是，该收益分配任务包括：产品、渠道、客户、合作方的参数以及决定收益分配的执行规则，如收益处理方式为现金分红，则通过现金方式将收益返回给客户，若分红再投，则通过转份额的方式转化为客户份额。产品行情数据决定分配收益。

步骤200：对所述收益分配任务进行分片拆分，以生成收益分配子任务；

具体地，基于分布式体系微服务方法，对业务数据按一定维度分片拆分，进一步地，微服务是一种服务间松耦合的、每个服务之间高度自治并且使用轻量级协议进行通信的可持续集成部署的分布式架构体系，其主要包括以下几种类型：

单体架构：单体架构是最简单的软件架构，常用于传统的应用软件开发以及传统Web应用。传统Web应用，一般是将所有功能模块都打包(jar,war)在一个Web容器(JBoss、Tomcate)中部署、运行。随着业务复杂度增加、技术团队规模扩大。在一个单体应用中维护代码，会降低开发效率。即使是处理一个小需求，也需要将所有机器上的应用全部部署一遍，增加了运维的复杂度。

SOA架构：当某一天使用单体架构发现很难推进需求的开发、以及日积月累的技术债，很多企业会开始做单体服务的拆分。拆分的方式一般有水平拆分以及垂直拆分。垂直拆分把一个应用拆成松耦合的多个独立的应用，让应用可以独立部署，有独立的团队进行维护。水平拆分把一些通用的，会被很多上层服务调用的模块独立拆分出去，形成一个共享的基础服务，这样拆分可以对一些性能瓶颈的应用进行单独的优化和运维管理，也一定程度防止了垂直拆分的重复造轮子。SOA也叫面向服务的架构，从单体服务到SOA的演进，需要结合水平拆分以及垂直拆分。SOA强调用统一的协议进行服务间的通信，服务间运行在彼此独立的硬件平台但是需通过统一的协议接口相互协作，也即将应用系统服务化。另一方面，微服务具有以下特点：

松耦合：每个微服务内部都可以使用DDD(领域驱动设计)的思想进行设计领域模型，服务间尽量减少同步的调用，多使用消息的方式让服务间的领域事件来进行解耦。

轻量级协议：Dubbo是SOA的开源的标准实现之一，类似的还有像gRPC、Thrift等。微服务更倾向于使用Restful风格的API，轻量级的协议可以很好得支持跨语言开发的服务，可能有的微服务用Java实现，有的用Go语言，有的用C++，但所有的语言都可以支持Http协议通信，所有的开发人员都能理解Restful风格API的含义。

高度自治和持续集成：从底层的角度来说，SOA更加倾向于基于虚拟机或者服务器的部署，每个应用都部署在不同的机器上，一般持续集成工具更多是由运维团队写一些shell脚本以及提供基于共同协议(比如dubbo管理页面)的开发部署页面。微服务可以很好得和容器技术结合，容器技术比微服务出现得晚，但是容器技术的出现让微服务的实施更加简便。目前Docker已经成为很多微服务实践的基础容器。因为容器的特色，所以一台机器上可以部署几十个几百个不同的微服务。如果某个微服务流量压力比其他微服务大，可以在不增加机器的情况，在一台机器上多分配一些该微服务的容器实例。同时，因为Docker的容器编排社区日渐成熟，类似Mesos，Kubernetes以及Docker官方提供的swarm都可以作为持续集成部署的技术选择。

微服务的分布式不仅仅是容器应用层面的分布式，其为了高度自治，底层的存储体系也应该互相独立。并且也不是所有的微服务都需要持久化的存储服务。微服务中的分布式场景除了服务本身需要有服务发现、负载均衡。微服务依赖的底层存储也会有分布式的场景:为了高可用性和性能需要处理数据库的复制、分区。并且存储的分库情况下，微服务需要能保证分布式事务的一致性。

步骤300：以服务调用方式对所述收益分配子任务进行分片处理；

具体地，可采用远程过程调用方式(RPC，Remote Procedure Call)对步骤300中的收益分配子任务进行分片处理，RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。举例来说：两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据(远程过程调用)。

RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。

需要说明的是，在微服务架构中，需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。服务调用有两种方式，一种是RPC方式，另一种是事件驱动(Event-driven)方式，消息方式是松耦合方式，比紧耦合的RPC方式要优越，但RPC方式如果用在适合的场景也有它的一席之地。

耦合的种类：

时间耦合：客户端和服务端必须同时上线才能工作。发消息时，接受消息队列必须运行，但后台处理程序暂时不工作也不影响。

容量耦合：客户端和服务端的处理容量必须匹配。发消息时，如果后台处理能力不足也不要紧，消息队列会起到缓冲的作用。

接口耦合：RPC调用有函数标签，而消息队列只是一个消息。例如买了商品之后要调用发货服务，如果是发消息，那么就只需发送一个商品被买消息。

发送方式耦合：RPC是点对点方式，需要知道对方是谁，它的好处是能够传回返回值。消息既可以点对点，也可以用广播的方式，这样减少了耦合，但也使返回值比较困难。

事件驱动(Event-Driven)方式：

Martin Fowler把事件驱动分成四种方式(What do you mean by“Event-Driven”)，简化之后本质上只有两种方式。一种就是我们熟悉的的事件通知(EventNotification)，另一种是事件溯源(Event Sourcing)。

事件通知就是微服务之间不直接调用，而是通过发消息来进行合作。事件溯源有点像记账，它把所有的事件都记录下来，作为永久存储层，再在它的基础之上构建应用程序。

实际上从应用的角度来讲，它们并不应该分属一类，它们的用途完全不同。事件通知是微服务的调用(或集成)方式，应该和RPC分在一起。事件溯源是一种存储数据的方式，应该和数据库分在一起。

从上述描述可知，本发明实施例提供一种基于服务调用的收益分配任务处理方法，首先接收待分配的收益分配任务；接着，对所述收益分配任务进行分片拆分，以生成收益分配子任务；最后以服务调用方式对所述收益分配子任务进行分片处理。本发明结合微服务及数据分片的设计理念，通过降低单个执行单元的执行数据量及提高并发执行思路，提升整体交易执行效率。

一实施例中，参见图2，步骤200进一步包括：

步骤201：按照多维度的方式对所述收益分配任务进行分片拆分；

多维度包括：理财产品维度、合作方维度以及客户维度。具体地，可灵活定义产品维度参数、合作方维度参数、客户维度参数，并根据该些维度参数对总的收益分配任务进行分片拆分。

具体地，根据微服务所具有的功能对收益分配任务进行拆分，以生成收益分配子任务，在拆分过程中需要遵循以下原则：

1)业务驱动原则。服务的拆分按照业务标准进行讨论拆分，避免单纯地从技术角度进行划分，避免不合适地数据划分，对业务流程进行明确地分析。

2)烟囱原则。服务边界划分清晰后不同的服务不能共享数据库表的操作，一张数据库表只能被一个服务访问，其他服务需要访问相关数据只能通过拥有该张表所有权的服务发布的API接口进行调用。

3)动态性原则。所有的服务配置与发现不能硬编码到应用中，要通过服务发现的方式来调用相应的接口，要能够通过配置管理服务动态更新配置文件。

4)无状态原则。所有的服务接口的调用不依赖于保存在请求上下文中的信息，支持进行负载均衡和弹性扩容操作。

一实施例中，参见图3，步骤300进一步包括：

步骤301：解析所述收益分配子任务，以确定所述收益分配子任务的分片信息；具体地，解析调度指令的业务区信息，计算出执行涉及的分片信息。如业务信息product_type＝3,TA_CODE in[A1,A2,A3,A4,A5],则分片计算会根据业务要求计算出，对应的HASH值，则应放在分片3、分片5、分片10处理。

步骤302：利用分片算法，根据所述分片信息以及预设的收益分配规则对所述收益分配子任务进行处理。

优选地，可根据以下步骤来定义收益分配规则，首先定义收益分配执行频率，收益兑付执行的频率，尾差的处理方式，节假日是否收益分配等收益分配基础配置。具体地：

收益分配执行频率：指的是收益分配是按照天、月、季度、年等频率执行

收益兑付执行频率：指的是收益分配后收益兑付给客户的方式。

一实施例中，参见图4，步骤200还包括：

步骤202：利用一致性HASH算法，根据客户唯一标识对所述收益分配任务进行分片拆分。

具体地，根据一致性HASH算法，按照客户唯一标示进行数据切分，保证每个分片的数据相对均匀的同时，实现业务数据切分，降低数据检索的成本。

可以理解的是，HASH算法将任意长度的二进制值映射为较短的固定长度的二进制值，这个小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式。其具有以下特定：

均衡性：是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。

单调性：是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲区加入到系统中，那么哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲区中去，而不会被映射到旧的缓冲集合中的其他缓冲区。(这段翻译信息有负面价值的，当缓冲区大小变化时一致性哈希(Consistent hashing)尽量保护已分配的内容不会被重新映射到新缓冲区。)

分散性：在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。

负载：负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。

为进一步地说明本方案，本发明提供基于服务调用的收益分配任务处理方法的具体应用实例。

参见图5以及图6，本具体应用实例还包括一种基于服务调用的收益分配任务处理定装置，该装置包括：任务控制模块1、执行器模块2、数据存储模块3，具体地：

任务控制模块1：通过服务调用方式协调各执行器协调工作。参见图7，任务控制模块分为规则装置、数据接收装置、任务调度装置。

规则定义装置：定义收益分配执行频率，收益兑付执行的频率，尾差的处理方式，节假日是否收益分配等收益分配基础配置。

收益分配执行频率：指的是收益分配是按照天、月、季度、年等频率执行

收益兑付执行频率：指的是收益分配后收益兑付给客户的方式。

数据接收装置：主要实现3部分内容：1.接收外部收益分配执行事件；2.解析事件并检查基础参数是否完整；3.读取执行规则通知任务调度装置实现任务调度。基础参数：主要包含如产品、渠道、客户、合作方的参数，决定收益分配的执行规则。如收益处理方式为现金分红，则通过现金方式将收益返回给客户，若分红再投，则通过转份额的方式转化为客户份额。产品行情数据决定分配收益。

任务调度装置：根据规则定义装置动态初始化执行器实例，并按照配置依赖实现执行器有序调度。

执行器模块2：本模块主要通过服务形式接收任务控制模块的任务调度指令，协调收益分配计算装置完成收益计算。参见图8，执行器模块主要包含：指令接收装置、缓存装置、执行控制装置、计算装置，具体地：

指令接收装置：通过服务化方式接收来自任务控制模块的执行指令，并实现对指令的解析及缓存，同步反馈指令接收情况给控制模块。

缓存装置：采用队列形式存储来至控制器的指令，并实现指令的先进先出控制，存储分片规则。

执行控制装置：主要用于协调指令接收到计算装置间的关系，保障交易指令能快速有效到达对应的计算装置处理，并及时获取指令处理结果通知任务控制模块。指令处理及分片计算。

计算装置：一方面计算装置主要实现收益分配的核心计算引擎，支持业务灵活定义产品维度参数、合作方维度参数、客户维度参数，收益分配规则灵活组合实现客户收益分配。另一方面，实现各分片之间计算后的尾差处理，实现分配收益和产品总未付收益的核对。主要有规则定义、规则配置、规则执行、尾差处理。

数据存储模块3：主要用于收益分配业务数据的存储及收益分配规则存储。参见图9，数据存储模块分为分片数据存储装置及集中节点装置：

分片数据存储装置，主要根据一致性HASH算法，按照客户唯一标示进行数据切分，保证每个分片的数据相对均匀的同时，实现业务数据切分，降低数据检索的成本。

集中节点装置，实现主要公共技术参数存储，如执行参数等，另外计算装置内的规则配置信息也将持久化在集中数据节点。

参见图10，基于上述基于服务调用的收益分配任务处理定装置，本具体应用实例所提供的基于服务调用的收益分配任务处理定方法包括以下步骤：

S1：接收收益分配任务(事件)。

S2：根据事件要素读取对应规则定义。

从多维度实现收益分配的规则定义，并以动态编译存储规则。具体地，可根据产品维度参数、合作方维度参数以及客户维度参数对规则进行定义：

产品维度参数，单个产品的收益分配规则，比如收益分配执行的频率、收益分配的比例、尾差的处理方式，业绩提成、交易费用。合作方维度参数，如合作方的折扣、大客户处理方式。客户维度参数，如客户征信、冻结等信息。

规则配置：组合规则定义的原子规则，按照业务定义的流程实现收益分配流程的组装。

规则执行：提供服务化调度入口，执行控制装置通过服务化调用实现收益分配流程执行。

尾差处理：区分与分片计算节点，用于计算分片汇总与总账间的尾差，并按照配置规则实现尾差再分配至单体客户。

S3：将事件要素通知任务调度装置。

S4：初始化执行器任务并持久化至数据存储。

具体地，根据规则定义装置的配置，初始化本场次收益分配的任务执行规则，包括执行器实例及依赖规则。如节假日第一天(20201026)，则需要初始化周六(20201024)、周日(20201025)、周一(20201025)三天的收益分配任务，并且每日进行兑付。

任务一：20201024，收益分配，#调用服务名#，#执行状态#，#依赖任务#......

任务二：20201024，收益兑付，#调用服务名#，#执行状态#，#依赖任务#......

任务三：20201025，收益分配，#调用服务名#，#执行状态#，#依赖任务#......

任务四：20201025，收益兑付，#调用服务名#，#执行状态#，#依赖任务#......

任务五：20201026，收益分配，#调用服务名#，#执行状态#，#依赖任务#......

任务六：20201026，收益兑付，#调用服务名#，#执行状态#，#依赖任务#......

S5：读取执行初始实例。

S6：初始化后通知任务调度执行任务。

具体地，根据初始化任务及依赖关系，基于RPC服务框架实现指定服务调用，并根据依赖关系依次调用任务。提供人工调度入口，支持人工手工调用执行。

S7：读取任务依赖关系。

S8：通过服务调用及任务依赖开始服务调用。

S9：按照依赖关系并行或串行调度各执行工作。

首先进行指令处理，运用jdk线程池扫描缓存装置内的待处理指令，并调用分片计算本指令涉及的处理分片并记录本指令与分片关联信息记录。接收各分片之间的执行结果，记录分片结果，以决策分片。接着，进行分片计算：解析调度指令的业务区信息，并根据实现分片算法(一致性HASH)，计算出执行涉及的分片信息。如业务信息product_type＝3,TA_CODE in[A1,A2,A3,A4,A5],则分片计算会根据业务要求计算出，对应的HASH值，则应放在分片3、分片5、分片10处理。

S10：检查执行器健康状态，对失败任务实现自动化切换。

通过心跳保障执行器的可用性检测；采用定频检测方式检测任务的执行结果；根据超时参数决策任务超时；通知任务执行结果给任务调用。

本具体应用实例还提供业务执行实例，以进一步阐述基于服务调用的收益分配任务处理方法，参见图11，包括以下步骤：

01：对收益分配任务进行初始化。

02：按照产品维度进行收益分配。

03：根据产品代码获取产品信息。

04：保存单库总份额。

05：计算单库用户收益。

06：检查当天的收益分配是否结束。

07：按照产品维度进行收益兑付。

从上述描述可知，本发明实施例提供一种基于服务调用的收益分配任务处理方法，首先接收待分配的收益分配任务；接着，对所述收益分配任务进行分片拆分，以生成收益分配子任务；最后以服务调用方式对所述收益分配子任务进行分片处理。本发明结合微服务及数据分片的设计理念，通过降低单个执行单元的执行数据量及提高并发执行思路，提升整体交易执行效率。本发明主要基于分布式体系微服务思想，对业务数据按一定维度分片拆分，并采用集中控制模块通过服务调用方式协调各分片处理，实现收益并发处理，支撑海量持仓客户的收益分配及兑付。

基于同一发明构思，本申请实施例还提供了一种基于服务调用的收益分配任务处理装置，可以用于实现上述实施例所描述的方法，如下面的实施例。由于基于服务调用的收益分配任务处理装置解决问题的原理与基于服务调用的收益分配任务处理方法相似，因此基于服务调用的收益分配任务处理装置的实施可以参见基于服务调用的收益分配任务处理方法实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本发明的实施例提供一种能够实现基于服务调用的收益分配任务处理方法的基于服务调用的收益分配任务处理装置的具体实施方式，参见图12，基于服务调用的收益分配任务处理装置具体包括如下内容：

任务分配单元10，用于接收待分配的收益分配任务；

任务拆分单元20，用于对所述收益分配任务进行分片拆分，以生成收益分配子任务；

分片处理单元30，用于以服务调用方式对所述收益分配子任务进行分片处理。

一实施例中，参见图13，所述任务拆分单元20包括：

维度拆分模块201，用于按照多维度的方式对所述收益分配任务进行分片拆分；

所述多维度包括：理财产品维度、合作方维度以及客户维度。

一实施例中，参见图14，所述分片处理单元30包括：

子任务解析模块301，用于解析所述收益分配子任务，以确定所述收益分配子任务的分片信息；

子任务处理模块302，用于利用分片算法，根据所述分片信息以及预设的收益分配规则对所述收益分配子任务进行处理。

一实施例中，参见图15，所述任务拆分单元20还包括：

一致性拆分模块202，用于利用一致性HASH算法，根据客户唯一标识对所述收益分配任务进行分片拆分。

从上述描述可知，本发明实施例提供一种基于服务调用的收益分配任务处理装置，首先接收待分配的收益分配任务；接着，对所述收益分配任务进行分片拆分，以生成收益分配子任务；最后以服务调用方式对所述收益分配子任务进行分片处理。本发明结合微服务及数据分片的设计理念，通过降低单个执行单元的执行数据量及提高并发执行思路，提升整体交易执行效率。本发明主要基于分布式体系微服务思想，对业务数据按一定维度分片拆分，并采用集中控制模块通过服务调用方式协调各分片处理，实现收益并发处理，支撑海量持仓客户的收益分配及兑付。

本申请的实施例还提供能够实现上述实施例中的基于服务调用的收益分配任务处理方法中全部步骤的一种电子设备的具体实施方式，参见图16，电子设备具体包括如下内容：

处理器(processor)1201、存储器(memory)1202、通信接口(CommunicationsInterface)1203和总线1204；

其中，处理器1201、存储器1202、通信接口1203通过总线1204完成相互间的通信；通信接口1203用于实现服务器端设备以及客户端设备等相关设备之间的信息传输；

处理器1201用于调用存储器1202中的计算机程序，处理器执行计算机程序时实现上述实施例中的基于服务调用的收益分配任务处理方法中的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：接收待分配的收益分配任务；

步骤200：对所述收益分配任务进行分片拆分，以生成收益分配子任务；

步骤300：以服务调用方式对所述收益分配子任务进行分片处理。

本申请的实施例还提供能够实现上述实施例中的基于服务调用的收益分配任务处理方法中全部步骤的一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的基于服务调用的收益分配任务处理方法的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：接收待分配的收益分配任务；

步骤200：对所述收益分配任务进行分片拆分，以生成收益分配子任务；

步骤300：以服务调用方式对所述收益分配子任务进行分片处理。

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

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

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

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

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

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