CN112394962B - 一种业务执行方法、业务逻辑更新方法及装置 - Google Patents

Abstract

本发明实施例涉及计算机技术领域，尤其涉及一种业务执行方法、业务逻辑更新方法及装置，用以解决业务执行中的业务逻辑和底层框架逻辑的耦合度高，不利于后续维护且工作效率低的问题。该方法包括：服务方接收任务执行请求，且获取任务执行请求的业务逻辑，该业务逻辑是从缓存服务方获取的，缓存服务方用于获取业务方生成的各业务逻辑，服务方按照该业务逻辑，通过服务方自身的底层框架逻辑执行所述任务执行请求。

Description

一种业务执行方法、业务逻辑更新方法及装置

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种业务执行方法、业务逻辑更新方法及装置。

背景技术

随着移动支付的蓬勃发展，支付系统承接大量的业务需求，不同的业务需求需要配置不同的业务逻辑。现有技术的业务执行中，业务逻辑通常采用硬编码，业务逻辑作为程序代码的一部分，每次业务逻辑的更新需要改动程序代码，底层框架逻辑和业务逻辑的耦合度较高，代码可读性较差，且庞大且复杂的业务逻辑让系统变得越来越冗余，不利于后续维护；且对于业务参数的配置，服务方往往需要通过调用配置中心服务来获取配置文件，实现根据配置文件的业务参数来处理不同的业务逻辑，这存在着对业务参数进行新增、删除、修改时，需要修改配置文件，并且需要重新启动服务方，才可以得到修改后的业务参数，导致效率过低；

因此，需要提供一种解决方案，用于解决业务执行中的业务逻辑和底层框架逻辑的耦合度高，不利于后续维护且工作效率低的问题。

发明内容

本发明实施例提供一种业务执行方法、业务逻辑更新方法及装置，用于解决业务执行中的业务逻辑和底层框架逻辑的耦合度高，不利于后续维护且效率低的问题。

第一方面，本发明实施例提供的一种业务执行方法，包括：

服务方接收任务执行请求；

所述服务方获取所述任务执行请求的业务逻辑；所述业务逻辑是从缓存服务方获取的；所述缓存服务方用于获取业务方生成的各业务逻辑；

所述服务方按照所述业务逻辑，通过所述服务方自身的底层框架逻辑执行所述任务执行请求。

通过上述方式，利用从缓存服务方获取的业务逻辑，并按照该业务逻辑，通过服务方自身的底层框架逻辑执行任务执行请求，避免了现有技术中，服务方的业务逻辑由于是采用硬编码方式，业务逻辑和底层框架逻辑作为程序的一部分所导致的底层框架逻辑和业务逻辑的耦合度较高且代码可读性较差的问题，实现了业务逻辑与服务方自身的底层框架逻辑的解耦且有利于后续维护；通过从缓存服务方获取业务逻辑的方式，避免了业务逻辑作为服务方程序代码的一部分，每次业务逻辑的更新需要改动服务方的程序代码。

可选地，所述方法还包括：所述服务方周期性从所述缓存服务方获取各业务逻辑；

所述服务方在确定任一业务逻辑存在更新，则将所述业务逻辑更新至所述服务方的缓存中。

通过上述方式，服务方可周期性的从缓存服务方获取各业务逻辑，保证了对于更新的业务逻辑，能够定时调用到服务方本地并更新到本地缓存中，而无需重启服务方。

可选地，所述从所述缓存服务方获取各业务逻辑，包括：

从所述缓存服务方获取各业务逻辑的业务参数、业务参数的版本号以及业务代码和业务代码的版本号；

通过如下方式确定任一业务逻辑存在更新：

所述服务方针对同一业务逻辑，确定自身存储的业务参数的版本号与从所述缓存服务方获取的业务参数的版本号是否一致，不一致则存在更新；和/或所述服务方针对同一业务逻辑，确定自身存储的业务代码的版本号与从所述缓存服务方获取的业务代码的版本号是否一致，不一致则存在更新。

通过上述方式，利用自身存储的业务参数的版本号与从缓存服务方获取的业务参数的版本号是否一致，和/或自身存储的业务代码的版本号与从缓存服务方获取的业务代码的版本号是否一致，来判断是否是更新的业务逻辑，操作过程简便且同时保证了服务方可从缓存服务方获取更新的业务逻辑。

可选地，所述将所述业务逻辑更新至所述服务方的缓存中，包括：

所述服务方在确定业务代码存在更新后，将所述业务代码更新至第一缓存中；

所述服务方在确定业务参数存在更新后，将所述业务参数更新至第二缓存中。

通过上述方式，实现了对更新的业务逻辑，将其中的业务代码和业务参数存储于不同缓存中，保证了业务代码和业务参数的分别存储，方便服务方根据任务执行请求来调取对应的业务代码和业务参数。

第二方面，本发明实施例提供的一种业务逻辑更新方法，包括：

缓存服务方从业务方获取针对各服务方的业务逻辑；

所述缓存服务方接收服务方的调用请求；

所述缓存服务方将所述调用请求对应的业务逻辑发送给所述服务方；所述服务方用于通过所述业务逻辑及自身存储的底层框架逻辑执行任务执行请求。

通过上述方式，保证了服务方可通过从缓存方获取的业务逻辑和自身存储的底层框架逻辑执行任务执行请求，底层框架逻辑可以专注于任务的流转和资源的维护，而业务逻辑利用业务方来更新与维护。

可选地，所述缓存服务方从业务方获取针对各服务方的业务逻辑，包括：

所述缓存服务方周期性从数据库中获取针对各服务方的业务逻辑；所述数据库用于存储通过校验的业务逻辑；

所述缓存服务方在确定任一业务逻辑的业务参数存在更新时，更新业务参数的版本号；和/或

所述缓存服务方在确定任一业务逻辑的业务代码存在更新时，更新业务代码的版本号。

通过上述方式，保证了缓存服务方可周期性的从数据库获得各服务方的业务逻辑，并对存在更新的业务参数版本号和业务代码版本号进行更新，保证了服务方可通过更新的版本号来判断对应业务参数和业务代码是否有更新，来进一步将更新的业务逻辑存于本地缓存中，工作效率更高。

第三方面，本发明实施例提供的一种业务执行装置，包括：

接收模块，用于接收任务执行请求；

处理模块，用于获取所述任务执行请求的业务逻辑；所述业务逻辑是从缓存服务方获取的；所述缓存服务方用于获取业务方生成的各业务逻辑；按照所述业务逻辑，通过所述处理模块自身的底层框架逻辑执行所述任务执行请求。

可选地，所述处理模块，还用于周期性从所述缓存服务方获取各业务逻辑；在确定任一业务逻辑存在更新，则将所述业务逻辑更新至所述服务方的缓存中。

可选地，所述处理模块，具体用于从所述缓存服务方获取各业务逻辑的业务参数、业务参数的版本号以及业务代码和业务代码的版本号；还用于确定任一业务逻辑存在更新：针对同一业务逻辑，确定自身存储的业务参数的版本号与从所述缓存服务方获取的业务参数的版本号是否一致，不一致则存在更新；和/或所述处理模块针对同一业务逻辑，确定自身存储的业务代码的版本号与从所述缓存服务方获取的业务代码的版本号是否一致，不一致则存在更新。

可选地，所述处理模块，具体用于在确定业务代码存在更新后，将所述业务代码更新至第一缓存中；在确定业务参数存在更新后，将所述业务参数更新至第二缓存中。

第四方面，本发明实施例提供的一种业务逻辑更新装置，包括：

收发模块，用于从业务方获取针对各服务方的业务逻辑；接收服务方的调用请求；

处理模块，用于将所述调用请求对应的业务逻辑发送给所述服务方；所述服务方用于通过所述业务逻辑及自身存储的底层框架逻辑执行任务执行请求。

可选地，所述处理模块，具体用于周期性从数据库中获取针对各服务方的业务逻辑；所述数据库用于存储通过校验的业务逻辑；在确定任一业务逻辑的业务参数存在更新时，更新业务参数的版本号；和/或在确定任一业务逻辑的业务代码存在更新时，更新业务代码的版本号。

第五方面，本发明实施例还提供一种计算机设备，包括：存储器，用于存储计算机程序；处理器，用于调用所述存储器中存储的计算机程序，按照获得的程序执行如第一方面和第二方面的各种可能的设计中所述的方法。

第六方面，本发明实施例还提供一种计算机可读非易失性存储介质，包括计算机可读程序，当计算机读取并执行所述计算机可读程序时，使得计算机执行如第一方面和第二方面的各种可能的设计中所述的方法。

附图说明

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

图1为本发明实施例提供的一种系统架构的示意图；

图2为本发明实施例提供的一种业务执行方法流程图；

图3为本发明实施例提供的一种业务逻辑配置示意图；

图4为本发明实施例提供的一种服务方处理业务逻辑示意图；

图5为本发明实施例提供的一种服务处理具体的业务执行方法流程图；

图6为本发明实施例提供的一种业务执行装置的结构示意图；

图7为本发明实施例提供的一种业务逻辑更新装置的结构示意图。

具体实施方式

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

图1为本发明实施例提供的一种系统架构。如图1所示，该系统架构可以为服务器100，该服务器100可以包括处理器110、通信接口120和存储器130。

其中，通信接口120用于与缓存服务方进行通信，收发该缓存服务方传输的信息，实现通信。

处理器110是服务器100的控制中心，利用各种接口和线路连接整个服务器100的各个部分，通过运行或执行存储在存储器130内的软件程序/或模块，以及调用存储在存储器130内的数据，执行服务器100的各种功能和处理数据。可选地，处理器110可以包括一个或多个处理单元。

存储器130可用于存储软件程序以及模块，处理器110通过运行存储在存储器130的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器130可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据业务处理所创建的数据等。此外，存储器130可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

需要说明的是，上述图1所示的结构仅是一种示例，本发明实施例对此不做限定。

基于上述描述，图2详细的示出了本发明实施例提供的一种业务执行方法的流程，该流程可以由业务执行装置执行，该装置可以为上述服务器或位于上述服务器内。

如图2所示，该流程具体包括：

步骤201：服务方接收任务执行请求；

步骤202：服务方获取任务执行请求的业务逻辑,业务逻辑是从缓存服务方获取的,缓存服务方用于获取业务方生成的各业务逻辑；

步骤203：服务方按照业务逻辑，通过服务方自身的底层框架逻辑执行任务执行请求。

在步骤201中，针对用户需求的不同，服务方可接收到多种类型的业务执行请求，例如该业务执行请求为消费、取现、转账、消费撤销、消费冲正等，并在接收到任务执行请求后，执行步骤202。

在步骤202的具体实施过程中，服务方从缓存服务方获取业务逻辑，且该业务逻辑为缓存服务方从业务方所获取存储于该缓存服务方本地的。该业务方可根据实际任务执行请求，按照一定语法规则和长度类型对业务逻辑进行增加、删除和修改等操作，实现业务方可生成针对各任务执行请求的各业务逻辑，使得缓存服务方可从此处获取到各业务逻辑，从而使得服务方可获取到针对任务执行请求的业务逻辑。

例如，业务运营人员可通过一个业务运营平台，对业务逻辑进行增加、删除和修改等操作，该业务运营人员可以根据开发人员所提供的使用手册来对业务逻辑按照一定语法规则和长度类型进行上述操作。需要说明的是，该语法规则可为Lua/PHP(超文本预处理器)/Python等无需编译的脚本语言，长度类型可为数组类型、int类型、字符串等多种类型，本领域技术人员可根据实际需求，选用不同类型的语法规则以及长度类型，此处不再赘述。

在步骤203中，服务方通过执行步骤202所获取的任务执行请求的业务逻辑，按照该业务逻辑，通过自身的底层框架逻辑来执行相应的任务执行请求。

例如，某银行的任务执行请求为对用户转账任务操作后，发送用户卡号后四位以及剩余金额到用户绑定手机号，那么，业务运营人员可通过添加该银行的机构号到具有这一转账功能的相应业务逻辑中，使得业务方具有了该任务执行请求的业务逻辑，进一步，缓存服务可获取到该业务方的各业务逻辑，即包括该任务执行请求的业务逻辑，且服务方可从该缓存服务方获取该任务执行请求的业务逻辑，那么，该服务方进一步可按照该业务逻辑来通过自身的底层框架逻辑执行该任务执行请求，使得该银行可实现对用户转账任务操作后，发送用户卡号后四位以及剩余金额到用户绑定手机号。

利用从缓存服务方获取的业务逻辑，并按照该业务逻辑，通过服务方自身的底层框架逻辑执行任务执行请求，避免了现有技术中，服务方的业务逻辑由于是采用硬编码方式，业务逻辑和底层框架逻辑作为程序的一部分所导致的底层框架逻辑和业务逻辑的耦合度较高且代码可读性较差的问题，实现了业务逻辑与服务方自身的底层框架逻辑的解耦且有利于后续维护；通过从缓存服务方获取业务逻辑的方式，避免了业务逻辑作为服务方程序代码的一部分，每次业务逻辑的更新需要改动服务方的程序代码。

针对服务方从缓存服务获取任务执行请求的业务逻辑，如下提供两种该服务方从缓存服务获取各业务逻辑的方式。

方式一：服务方可根据需要，即根据所接收的业务执行请求来获取该任务执行请求的业务逻辑。例如当前的任务执行请求为执行X，则根据接收到的执行X，来获取相应的业务逻辑。

方式二：服务方周期性从该缓存服务方获取各业务逻辑，在确定任一业务逻辑存在更新，则将业务逻辑更新至服务方的缓存中。

方式二中，该服务方根据调取周期，来从缓存服务方周期性获取各业务逻辑，并在判断获取的业务逻辑存在更新便存于本地缓存中，如此，在接收到任务执行请求后，可根据已存入本地缓存中的该任务执行请求的业务逻辑，来根据自身的底层框架执行该业务执行请求。采用周期性获取各业务逻辑的方式，使得服务方可周期性的利用更新的业务逻辑处理所接收到的不同的任务执行请求，对于不同的任务执行请求，且不再需要对服务方进行重启操作，以求获取更新的业务参数，提高了工作效率。可见，通过方式二的方式来从缓存服务获取各业务逻辑，可使得处理任务执行请求速度相较于方式一中接收到任务执行请求后才去获取该任务执行请求的业务逻辑速度较快。

针对服务方从缓存服务方获取的各业务逻辑，是缓存服务方从业务方获取针对各服务方的业务逻辑；缓存服务方接收服务方的调用请求，将调用请求对应的业务逻辑发送给服务方，使得服务方通过业务逻辑及自身存储的底层框架逻辑来执行任务执行请求。

需要说明的是，针对不同的业务逻辑具有不同的服务方，在接收到任务执行请求时，各服务方可根据该任务执行请求来分配到对应的服务方，那么该服务方便可以从缓存服务方获取该任务执行请求的业务逻辑，由此，该缓存服务方从业务方获取针对各服务方的业务逻辑，根据接收到的调用请求，将对应的业务逻辑发送给对应的服务方，使得对应服务方按照业务逻辑，来根据自身的底层框架逻辑执行对应的任务执行请求，本领域技术人员可根据具体需要执行上述过程，本申请不再赘述。

通过上述方式，保证了服务方可通过从缓存方获取的业务逻辑和自身存储的底层框架逻辑执行任务执行请求，底层框架逻辑可以专注于任务的流转和资源的维护，而业务逻辑利用业务方来更新与维护，且针对更新的业务参数，服务方不必进行重启操作，如现有技术中仍需从配置中心获取配置文件以得到更新的业务参数，提高了工作效率。

针对服务方所获取的任务执行请求的业务逻辑，图3为本发明实施例提供的一种业务逻辑配置示意图；

可选的，针对缓存服务方从业务方获取针对各服务方的业务逻辑，包括：缓存服务方周期性从数据库中获取针对各服务方的业务逻辑，该数据库用于存储通过校验的业务逻辑，在缓存服务方确定任一业务逻辑的业务参数存在更新时，更新业务参数的版本号；和/或在确定任一业务逻辑的业务代码存在更新时，更新业务代码的版本号。

如图3所示，服务方可为针对不同业务的服务A、服务B和服务C，例如服务A为针对转账服务；服务B为针对冲正服务，服务C为针对退款服务。那么缓存服务方执行步骤S301，从业务方周期性获取业务逻辑；即缓存服务从业务方获取针对该服务A、服务B和服务C的业务逻辑，该业务方可为业务运营人员根据需求通过业务运营平台来导入具体的业务逻辑到数据库中，且该导入的业务逻辑经过了校验。

缓存服务方周期性的从数据库中获取针服务A、服务B和服务C的业务逻辑，并在确定任一业务逻辑存在更新时，即在确定任一业务逻辑的业务参数存在更新时，则更新业务参数的版本号；和/或在确定任一业务逻辑的业务代码存在更新时，更新业务代码的版本号，保证了更新的业务参数版本号和/或更新的业务代码版本号与本地存储的历史业务参数版本号和业务代码版本号均不同。该业务参数版本号和/或更新业务代码版本号可以是更新时间，例如将更新的业务代码和/或更新的业务逻辑的版本号更新为最新时间，又或将对应版本号数值加1等，本领域技术人员可以根据需求，设置不同类型的版本号，此处不做赘述。

进一步，服务方执行步骤S302，从缓存服务方周期性获取业务逻辑；即服务A、服务B和服务C可通过上述两种方式从缓存服务获取各业务逻辑，以方式二为例，服务A、服务B和服务C周期性的获取缓存服务所存储的针对本服务方的业务逻辑，以服务A为例，服务A从缓存服务周期性的获取针对转账服务的业务逻辑，在接收到任务执行请求时，根据服务方本地缓存中存储的该任务执行请求的业务逻辑，通过自身的底层框架逻辑来执行任务执行请求。

可选的，服务方从缓存服务方获取各业务逻辑的业务参数、业务参数的版本号以及业务代码和业务代码的版本号；

服务方通过如下方式确定任一业务逻辑存在更新：

服务方针对同一业务逻辑，确定自身存储的业务参数的版本号与从缓存服务方获取的业务参数的版本号是否一致，不一致则存在更新；和/或服务方针对同一业务逻辑，确定自身存储的业务代码的版本号与从缓存服务方获取的业务代码的版本号是否一致，不一致则存在更新。

例如，服务A在从缓存服务方获取到业务逻辑时，根据自身存储的业务代码的版本号来判断，所获得的该业务逻辑中业务代码的版本号是否与之一致，若不一致，则表明该业务代码是更新的业务代码，则将该更新的业务代码刷新到本身缓存中；若根据自身存储的业务参数的版本号来判断，所获得的该业务逻辑中业务参数的版本号是否与之一致，若一致，则表明该业务参数未更新，则丢弃该未更新的业务参数即可。

利用自身存储的业务参数的版本号与从缓存服务方获取的业务参数的版本号是否一致，和/或自身存储的业务代码的版本号与从缓存服务方获取的业务代码的版本号是否一致的方式，来判断接收到的业务逻辑是否是更新的业务逻辑，操作过程简便，实用性较高，且同时保证了服务方可从缓存服务方获取更新的业务逻辑。

可选的，针对业务逻辑更新至服务方的缓存中，包括：服务方在确定业务代码存在更新后，将业务代码更新至第一缓存中；在确定业务参数存在更新后，将业务参数更新至第二缓存中。

服务方初始配置的一个缓存模块，即程序的堆栈区，其中维护两组缓存，在第一缓存中存储业务代码，在第二缓存中存储业务参数，图4为本发明实施例提供的一种服务方处理业务逻辑示意图。

如图4所示，在服务方执行步骤S401，从缓存服务方周期性获取到业务逻辑时，会根据本地缓存模块中的业务代码版本号判断获取的业务代码有更新，则将业务代码更新至第一缓存中；在根据本地业务代码参数版本号判断获取的业务参数有更新，则将业务参数更新至第二缓存中。如此，保证了业务代码和业务参数的分别存储，方便服务方根据任务执行请求来调取对应的业务代码和业务参数。

在服务方接收到任务执行请求，通过业务处理模块中的底层框架逻辑对该任务执行请求处理时，则可执行步骤S402，根据本地缓存模块的第一缓存中获取的该任务执行请求的业务代码，通过语言解释器对该业务代码进行分析，同时，执行步骤403，根据本地缓存模块的第二缓存中获取的该任务执行请求的业务参数，来根据指针使用，用于处理更新后的业务逻辑。

针对对业务逻辑的处理，实际为该服务方的缓存模块从缓存服务方获取，并存于缓存模块的第一缓存和第二缓存中的，而真正的业务处理模块的底层框架逻辑，实际无需关注具体的业务逻辑针对任务执行请求的业务实现，而只需要专注于资源的分配、任务的流转和资源维护等。

基于上述情况，图5为本发明实施例提供的一种服务处理具体的业务执行方法流程图，具体包括：

步骤501：导入经校验的业务逻辑到数据库；

步骤502：缓存服务方获取针对各服务方的业务逻辑；

在具体执行步骤501中，可为业务运营人员通过业务运行平台来将业务逻辑导入到数据库中，且该业务逻辑中业务代码具有一定的语法规则、同时业务参数具有一定规则的长度类型；该业务运营人员可根据各个服务方的任务执行请求来导入针对各服务方的业务逻辑到数据库中；在步骤502中，缓存服务方周期性从数据库中获取针对各服务方的业务逻辑，在确定任一业务逻辑的业务参数存在更新时，更新业务参数的版本号；和/或在确定任一业务逻辑的业务代码存在更新时，更新业务代码的版本号，保证服务方可根据获取到的业务参数版本号和业务代码版本号与本地存储的业务参数版本号和业务代码版本号是否一致来判断是否存在更新。

步骤503：缓存服务方接收服务方发送的调用请求；

步骤504：缓存服务方将调用请求对应的业务逻辑发送给服务方；

在步骤503中，服务方会周期性的向缓存服务方发送调用请求，请求获取各业务逻辑，在缓存服务接收到服务方发送的调用请求后，会执行步骤504，将调用请求对应的业务逻辑发送至服务方，该业务逻辑可以是更新的业务逻辑，也可以为未经过更新的业务逻辑；服务方会根据相应版本号来判断该接收到的业务参数和业务代码是否存在更新，若有更新，则将更新的业务参数和/或业务代码刷新到本地的缓存模块中，具体为将业务代码更新于第一缓存中，将业务参数更新于第二缓存中；若业务代码和/或业务参数没有更新，则将此次接收到的业务代码和/或业务参数丢弃。

步骤505：服务方接收任务执行请求，通过业务逻辑以及自身存储的底层框架逻辑执行任务执行请求。

在具体步骤505中，服务方根据执行步骤504所获取的业务逻辑存于本地缓存模块中，在服务方接收到任务执行请求时，可通过本地存储的该任务执行请求的业务逻辑，来根据自身的业务处理模块的底层框架逻辑执行该任务执行请求。

需要说明的是，若一个或几个周期内，该服务方根据业务逻辑，通过自身的底层框架逻辑无法完成对任务执行请求的执行，则可根据周期性的从缓存服务中获取业务逻辑，来实现对该任务执行请求的业务逻辑的获取，从而在预期时间内完成对该任务执行请求的执行，本领域技术人员可根据实际需求来设定预期时间，在此不做赘述。

综上所述，服务方接收任务执行请求，且获取任务执行请求的业务逻辑，该业务逻辑是从缓存服务方获取的，缓存服务方用于获取业务方生成的各业务逻辑，服务方按照该业务逻辑，通过服务方自身的底层框架逻辑执行所述任务执行请求。通过上述方式，避免了现有技术中，服务方的业务逻辑由于是采用硬编码方式，业务逻辑和底层框架逻辑作为程序的一部分所导致的底层框架逻辑和业务逻辑的耦合度较高且代码可读性较差的问题，实现了业务逻辑与服务方自身的底层框架逻辑的解耦且有利于后续维护；通过从缓存服务方获取业务逻辑的方式，避免了业务逻辑作为服务方程序代码的一部分，每次业务逻辑的更新需要改动服务方的程序代码。

基于相同的技术构思，本发明实施例还提供一种业务执行装置，该装置用于实现上述实施例中的任一种业务执行方法。图6为本发明实施例提供的一种可穿戴设备的定位装置结构示意图，如图6所示，该业务执行装置600包括：

接收模块601，用于接收任务执行请求；

处理模块602，用于获取所述任务执行请求的业务逻辑；所述业务逻辑是从缓存服务方获取的；所述缓存服务方用于获取业务方生成的各业务逻辑；按照所述业务逻辑，通过所述处理模块自身的底层框架逻辑执行所述任务执行请求。

可选的，所述处理模块602，还用于周期性从所述缓存服务方获取各业务逻辑；在确定任一业务逻辑存在更新，则将所述业务逻辑更新至所述服务方的缓存中。

可选地，所述处理模块602，具体用于从所述缓存服务方获取各业务逻辑的业务参数、业务参数的版本号以及业务代码和业务代码的版本号；还用于确定任一业务逻辑存在更新：针对同一业务逻辑，确定自身存储的业务参数的版本号与从所述缓存服务方获取的业务参数的版本号是否一致，不一致则存在更新；和/或所述处理模块针对同一业务逻辑，确定自身存储的业务代码的版本号与从所述缓存服务方获取的业务代码的版本号是否一致，不一致则存在更新。

可选地，所述处理模块602，具体用于在确定业务代码存在更新后，将所述业务代码更新至第一缓存中；在确定业务参数存在更新后，将所述业务参数更新至第二缓存中。

基于相同的技术构思，本发明实施例还提供一种业务逻辑更新装置，该装置用于实现上述实施例中的任一种业务逻辑更新方法。图7为本发明实施例提供的一种业务逻辑更新装置结构示意图，如图7所示，该业务逻辑更新装置700包括：

收发模块701，用于从业务方获取针对各服务方的业务逻辑；接收服务方的调用请求；

处理模块702，用于将所述调用请求对应的业务逻辑发送给所述服务方；所述服务方用于通过所述业务逻辑及自身存储的底层框架逻辑执行任务执行请求。

可选的，所述处理模块702，具体用于周期性从数据库中获取针对各服务方的业务逻辑；所述数据库用于存储通过校验的业务逻辑；在确定任一业务逻辑的业务参数存在更新时，更新业务参数的版本号；和/或在确定任一业务逻辑的业务代码存在更新时，更新业务代码的版本号。

基于同样的发明构思，本发明实施例还提供另一种计算机设备，该计算机设备具体可以为桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理(PersonalDigital Assistant，PDA)等。该计算机设备可以包括中央处理器(Center ProcessingUnit，CPU)、存储器、输入/输出设备等，输入设备可以包括键盘、鼠标、触摸屏等，输出设备可以包括显示设备，如液晶显示器(Liquid Crystal Display，LCD)、阴极射线管(CathodeRay Tube，CRT)等。

存储器可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器提供存储器中存储的程序指令和数据。在本发明实施例中，存储器可以用于存储上述业务执行方法和业务逻辑更新方法的程序。

处理器通过调用存储器存储的程序指令，处理器用于按照获得的程序指令执行上述业务执行方法和业务逻辑更新方法。

基于同样的发明构思，本发明实施例提供了一种计算机存储介质，用于储存为上述计算机设备所用的计算机程序指令，其包含用于执行上述业务执行方法和业务逻辑更新方法的程序。

所述计算机存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等。

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

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

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

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

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种业务执行方法，其特征在于，所述方法包括：

服务方接收任务执行请求，其中，针对不同的业务逻辑具有不同的服务方，在接收到任务执行请求时，各服务方根据所述任务执行请求来分配到对应的服务方；

所述服务方获取所述任务执行请求的业务逻辑；所述业务逻辑是从缓存服务方获取的；所述缓存服务方用于获取业务方生成的各业务逻辑，所述业务方用于按照语法规则和长度类型对业务逻辑进行操作；

所述服务方按照所述业务逻辑，通过所述服务方自身的底层框架逻辑执行所述任务执行请求。

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

所述服务方周期性从所述缓存服务方获取各业务逻辑；

所述服务方在确定任一业务逻辑存在更新，则将所述业务逻辑更新至所述服务方的缓存中。

3.根据权利要求2所述的方法，其特征在于，所述从所述缓存服务方获取各业务逻辑，包括：

从所述缓存服务方获取各业务逻辑的业务参数、业务参数的版本号以及业务代码和业务代码的版本号；

通过如下方式确定任一业务逻辑存在更新：

所述服务方针对同一业务逻辑，确定自身存储的业务参数的版本号与从所述缓存服务方获取的业务参数的版本号是否一致，不一致则存在更新；和/或所述服务方针对同一业务逻辑，确定自身存储的业务代码的版本号与从所述缓存服务方获取的业务代码的版本号是否一致，不一致则存在更新。

4.根据权利要求2所述的方法，其特征在于，所述将所述业务逻辑更新至所述服务方的缓存中，包括：

所述服务方在确定业务代码存在更新后，将所述业务代码更新至第一缓存中；

所述服务方在确定业务参数存在更新后，将所述业务参数更新至第二缓存中。

5.一种业务逻辑更新方法，其特征在于，所述方法包括：

缓存服务方从业务方获取针对各服务方的业务逻辑，所述业务方用于按照语法规则和长度类型对业务逻辑进行操作；

所述缓存服务方接收服务方的调用请求；

所述缓存服务方将所述调用请求对应的业务逻辑发送给所述服务方；所述服务方用于通过所述业务逻辑及自身存储的底层框架逻辑执行任务执行请求，其中，针对不同的业务逻辑具有不同的服务方，在接收到任务执行请求时，各服务方根据所述任务执行请求来分配到对应的服务方。

6.根据权利要求5所述的方法，其特征在于，所述缓存服务方从业务方获取针对各服务方的业务逻辑，包括：

所述缓存服务方周期性从数据库中获取针对各服务方的业务逻辑；所述数据库用于存储通过校验的业务逻辑；

所述缓存服务方在确定任一业务逻辑的业务参数存在更新时，更新业务参数的版本号；和/或

所述缓存服务方在确定任一业务逻辑的业务代码存在更新时，更新业务代码的版本号。

7.一种业务执行装置，其特征在于，包括：

接收模块，用于接收任务执行请求，其中，针对不同的业务逻辑具有不同的服务方，在接收到任务执行请求时，各服务方根据所述任务执行请求来分配到对应的服务方；

处理模块，用于获取所述任务执行请求的业务逻辑；所述业务逻辑是从缓存服务方获取的；所述缓存服务方用于获取业务方生成的各业务逻辑，所述业务方用于按照语法规则和长度类型对业务逻辑进行操作；按照所述业务逻辑，通过所述处理模块自身的底层框架逻辑执行所述任务执行请求。

8.一种业务逻辑更新装置，其特征在于，包括：

收发模块，用于从业务方获取针对各服务方的业务逻辑，所述业务方用于按照语法规则和长度类型对业务逻辑进行操作；接收服务方的调用请求；

处理模块，用于将所述调用请求对应的业务逻辑发送给所述服务方；所述服务方用于通过所述业务逻辑及自身存储的底层框架逻辑执行任务执行请求，其中，针对不同的业务逻辑具有不同的服务方，在接收到任务执行请求时，各服务方根据所述任务执行请求来分配到对应的服务方。

9.一种计算设备，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行如权利要求1-6任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行如权利要求1-6任一项所述的方法。