CN115408124A - 一种处理业务调用请求的方法和装置 - Google Patents

Abstract

本发明公开了一种处理业务调用请求的方法和装置，涉及医疗健康技术领域。该方法的一具体实施方式包括：接收调用当前业务的调用请求，将所述调用请求中携带的入参写入下游业务的业务模型；将所述下游业务的业务模型放入业务队列，以使异步线程执行所述下游业务的业务模型，将执行结果写入所述下游业务的业务模型并将所述下游业务的状态修改为执行完成；监听所述业务队列中所述下游业务的状态，若所述下游业务的状态为执行完成，则从所述业务队列中取出所述下游业务的业务模型。该实施方式能够解决业务接口耦合性强、灵活性差的技术问题。

Description

一种处理业务调用请求的方法和装置

技术领域

本发明涉及医疗健康技术领域，尤其涉及一种处理业务调用请求的方法和装置。

背景技术

随着健康医疗业务的不断发展，健康业务的数据展示和所需要提供的业务功能复杂度逐渐增高，特别是对前台医疗业务，由于市场业务形态再不断变化，一般通过使用中台提供的原子业务接口聚合或组装方式，来满足自身的业务接口的落地。

当前，健康医疗业务中一个业务接口依赖的业务接口越来越多，比如问诊接口依赖患者身份验证接口和患者信息查询接口。一方面，串行调用耗时严重，已不能满足业务要求，另一方面，业务接口的耦合性强、灵活性差，当增加一个业务接口时需要考虑接口之间的依赖关系，需要考虑接口放入对应模块层次、调用逻辑顺序等问题，导致修改或升级业务功能的风险较高，而且不能快速复用业务接口、不能快速落地业务功能。

发明内容

有鉴于此，本发明实施例提供一种处理业务调用请求的方法和装置，以解决业务接口耦合性强、灵活性差的技术问题。

为实现上述目的，根据本发明实施例的一个方面，提供了一种处理业务调用请求的方法，包括：

接收调用当前业务的调用请求，将所述调用请求中携带的入参写入下游业务的业务模型；

将所述下游业务的业务模型放入业务队列，以使异步线程执行所述下游业务的业务模型，将执行结果写入所述下游业务的业务模型并将所述下游业务的状态修改为执行完成；

监听所述业务队列中所述下游业务的状态，若所述下游业务的状态为执行完成，则从所述业务队列中取出所述下游业务的业务模型；

从所述下游业务的业务模型中取出执行结果，将所述下游业务的执行结果写入所述当前业务的业务模型，执行所述当前业务的业务模型，从而得到所述当前业务的执行结果。

可选地，所述业务模型包括数据容器、验证逻辑、主业务逻辑和后置逻辑；

其中，所述数据容器用于存储入参和执行结果；所述验证逻辑用于验证主业务逻辑是否具备执行条件；所述主业务逻辑用于对入参进行主业务处理从而得到出参；所述后置逻辑用于组装出参从而得到执行结果。

可选地，将所述调用请求中携带的入参写入下游业务的业务模型，包括：

将所述调用请求中携带的入参写入下游业务的数据容器。

可选地，将所述下游业务的业务模型放入业务队列，以使异步线程执行所述下游业务的业务模型，将执行结果写入所述下游业务的业务模型并将所述下游业务的状态修改为执行完成，包括：

将所述下游业务的业务模型放入业务队列，并将所述下游业务的状态置为可执行，以使异步线程依次执行所述验证逻辑、所述主业务逻辑和所述后置逻辑之后，将执行结果写入所述数据容器。

可选地，从所述下游业务的业务模型中取出执行结果，将所述下游业务的执行结果写入所述当前业务的业务模型，执行所述当前业务的业务模型，从而得到所述当前业务的执行结果，包括：

从所述业务模型的数据容器中取出执行结果，将所述下游业务的执行结果写入所述当前业务的数据容器；

依次执行所述当前业务的验证逻辑、主业务逻辑和后置逻辑，从而得到所述当前业务的执行结果。

可选地，接收调用当前业务的调用请求之前，还包括：

配置各个业务之间的上下游依赖关系；

对于每个业务，存储所述业务与其下游业务之间的对应关系。

可选地，采用键值对方式或JSON对象方式存储所述业务与其下游业务之间的对应关系。

另外，根据本发明实施例的另一个方面，提供了一种处理业务调用请求的装置，包括：

接收模块，用于接收调用当前业务的调用请求，将所述调用请求中携带的入参写入下游业务的业务模型；

队列模块，用于将所述下游业务的业务模型放入业务队列，以使异步线程执行所述下游业务的业务模型，将执行结果写入所述下游业务的业务模型并将所述下游业务的状态修改为执行完成；

监听模块，用于监听所述业务队列中所述下游业务的状态，若所述下游业务的状态为执行完成，则从所述业务队列中取出所述下游业务的业务模型；

执行模块，用于从所述下游业务的业务模型中取出执行结果，将所述下游业务的执行结果写入所述当前业务的业务模型，执行所述当前业务的业务模型，从而得到所述当前业务的执行结果。

可选地，所述业务模型包括数据容器、验证逻辑、主业务逻辑和后置逻辑；

其中，所述数据容器用于存储入参和执行结果；所述验证逻辑用于验证主业务逻辑是否具备执行条件；所述主业务逻辑用于对入参进行主业务处理从而得到出参；所述后置逻辑用于组装出参从而得到执行结果。

可选地，所述接收模块还用于：

将所述调用请求中携带的入参写入下游业务的数据容器。

可选地，所述队列模块还用于：

将所述下游业务的业务模型放入业务队列，并将所述下游业务的状态置为可执行，以使异步线程依次执行所述验证逻辑、所述主业务逻辑和所述后置逻辑之后，将执行结果写入所述数据容器。

可选地，所述执行模块还用于：

从所述业务模型的数据容器中取出执行结果，将所述下游业务的执行结果写入所述当前业务的数据容器；

依次执行所述当前业务的验证逻辑、主业务逻辑和后置逻辑，从而得到所述当前业务的执行结果。

可选地，还包括配置模块，用于：

接收调用当前业务的调用请求之前，配置各个业务之间的上下游依赖关系；

对于每个业务，存储所述业务与其下游业务之间的对应关系。

可选地，采用键值对方式或JSON对象方式存储所述业务与其下游业务之间的对应关系。

根据本发明实施例的另一个方面，还提供了一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行时，所述一个或多个处理器实现上述任一实施例所述的方法。

根据本发明实施例的另一个方面，还提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一实施例所述的方法。

根据本发明实施例的另一个方面，还提供了一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述任一实施例所述的方法。

上述发明中的一个实施例具有如下优点或有益效果：因为采用当前业务将下游业务的业务模型放入业务队列，以使异步线程执行下游业务的业务模型，将执行结果写入下游业务的业务模型，当前业务从业务队列中取出下游业务的执行结果并将其写入当前业务的业务模型，执行当前业务的业务模型从而得到当前业务的执行结果的技术手段，所以克服了现有技术中业务接口耦合性强、灵活性差的技术问题。本发明实施例能够对业务接口进行业务模型复用和解耦，从而提高业务接口性能和灵活性，而且本发明实施例能够快速落地业务功能，降低业务模型之间的复杂度，从而降低修改或者升级业务功能的风险。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

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

图1是根据本发明实施例的处理业务调用请求的方法的主要流程的示意图；

图2是根据本发明实施例的业务执行过程的示意图；

图3是根据本发明一个可参考实施例的处理业务调用请求的方法的主要流程的示意图；

图4是根据本发明实施例的各个业务之间的上下游依赖关系的示意图；

图5是根据本发明实施例的处理业务调用请求的方法的示意图；

图6是根据本发明实施例的上下游业务依赖的示意图；

图7是根据本发明实施例的处理业务调用请求的装置的主要模块的示意图；

图8是本发明实施例可以应用于其中的示例性系统架构图；

图9是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的处理业务调用请求的方法的主要流程的示意图。作为本发明的一个实施例，如图1所示，所述处理业务调用请求的方法可以包括：

步骤101，接收调用当前业务的调用请求，将所述调用请求中携带的入参写入下游业务的业务模型。

当前业务系统接收到调用请求后，对所述调用请求进行解析，从而得到调用请求中携带的入参。接着，判断当前业务是否有依赖的下游业务，如果有，则将调用请求中携带的入参写入下游业务的业务模型。

可选地，所述业务模型包括数据容器、验证逻辑、主业务逻辑和后置逻辑；其中，所述数据容器用于存储入参和执行结果；所述验证逻辑用于验证主业务逻辑是否具备执行条件；所述主业务逻辑用于对入参进行主业务处理从而得到出参；所述后置逻辑用于组装出参从而得到执行结果。在本发明的实施例中，业务的逻辑按照功能可以分为busiessData(数据容器逻辑)、businessCheck(验证逻辑)、business(主业务逻辑)和businessPostProcessor(后置逻辑)，并且busiessData、businessCheck、business和businessPostProcessor依次执行，如图2所示。其中，busiessData用于创建独立的数据容器，所述数据容器用于存储business运行的入参(调用请求中携带的入参或者当前业务依赖的下游业务的执行结果)、业务执行的中间结果和最终的执行结果；businessCheck用于验证business是否具备执行条件；business用于对数据容器中的入参进行主业务处理从而得到出参，并将出参存储到数据容器中；businessPostProcessor可以在business执行完毕后再执行一些后处理逻辑，比如组装出参从而得到最终的执行结果，然后将执行结果存储到数据容器中。

需要指出的是，每个业务都有各自的业务模型，每个业务将各自的入参、业务执行的中间结果和最终的执行结果存储在各自的数据容器中，以方便上游业务从下游业务的数据容器中获取执行结果。

可选地，将所述调用请求中携带的入参写入下游业务的业务模型，包括：将所述调用请求中携带的入参写入下游业务的数据容器。在本发明的实施例中，当前业务系统接收到调用请求后，判断当前业务是否有依赖的下游业务，如果有，则将调用请求中携带的入参写入下游业务的数据容器中，以便于下游业务在执行时从数据容器中获取入参并进行主业务处理。可选地，可以由下游业务的busiessData将调用请求中携带的入参写入其数据容器中。

步骤102，将所述下游业务的业务模型放入业务队列，以使异步线程执行所述下游业务的业务模型，将执行结果写入所述下游业务的业务模型并将所述下游业务的状态修改为执行完成。

将所述调用请求中携带的入参写入下游业务的业务模型之后，将所述下游业务的业务模型放入业务队列，异步线程会从业务队列中取出下游业务的业务模型，然后执行所述业务模型并将执行结果写入所述业务模型，最后将业务模型放回到业务队列中并将所述下游业务的状态修改为执行完成。需要指出的是，如果异步线程执行失败，则不需要将执行结果写入下游业务的业务模型，但是需要将队列中下游业务的状态修改为不可执行。在业务队列中，业务的状态包括可执行、不可执行和执行完成。

可选地，步骤102可以包括：将所述下游业务的业务模型放入业务队列，并将所述下游业务的状态置为可执行，以使异步线程依次执行所述验证逻辑、所述主业务逻辑和所述后置逻辑之后，将执行结果写入所述数据容器。由于下游业务的业务模型包括数据容器、验证逻辑、主业务逻辑和后置逻辑，因此异步线程依次执行下游业务的验证逻辑、主业务逻辑和后置逻辑，并将最终的执行结果写入数据容器中，以便于当前业务从下游业务的数据容器中获取执行结果。

步骤103，监听所述业务队列中所述下游业务的状态，若所述下游业务的状态为执行完成，则从所述业务队列中取出所述下游业务的业务模型。

当前业务实时监听业务队列中下游业务的状态，如果下游业务的状态修改为执行完成，则从业务队列中取出下游业务的业务模型。

步骤104，从所述下游业务的业务模型中取出执行结果，将所述下游业务的执行结果写入所述当前业务的业务模型，执行所述当前业务的业务模型，从而得到所述当前业务的执行结果。

当前业务系统从业务队列中取出下游业务的业务模型后，从该业务模型中取出执行结果，然后将下游业务的执行结果写入当前业务的业务模型，接着执行当前业务的业务模型，从而得到当前业务的执行结果。

可选地，步骤104可以包括：从所述业务模型的数据容器中取出执行结果，将所述下游业务的执行结果写入所述当前业务的数据容器；依次执行所述当前业务的验证逻辑、主业务逻辑和后置逻辑，从而得到所述当前业务的执行结果。由于当前业务的业务模型包括数据容器、验证逻辑、主业务逻辑和后置逻辑，因此数据容器逻辑将取出的执行结果写入数据容器，本地的调度线程依次执行当前业务的验证逻辑、主业务逻辑和后置逻辑，从而得到当前业务的执行结果并将该执行结果写入当前业务的数据容器。

根据上面所述的各种实施例，可以看出本发明实施例通过当前业务将下游业务的业务模型放入业务队列，以使异步线程执行下游业务的业务模型，将执行结果写入下游业务的业务模型，当前业务从业务队列中取出下游业务的执行结果并将其写入当前业务的业务模型，执行当前业务的业务模型从而得到当前业务的执行结果的技术手段，解决了现有技术中业务接口耦合性强、灵活性差的技术问题。本发明实施例能够对业务接口进行业务模型复用和解耦，从而提高业务接口性能和灵活性，而且本发明实施例能够快速落地业务功能，降低业务模型之间的复杂度，从而降低修改或者升级业务功能的风险。

图3是根据本发明一个可参考实施例的处理业务调用请求的方法的主要流程的示意图。作为本发明的又一个实施例，如图3所示，所述处理业务调用请求的方法可以包括：

步骤301，配置各个业务之间的上下游依赖关系。

本发明实施例通过有向无环图进行上下游业务之间的编排，并维护上下游业务之间的依赖关系。如图4所示，业务b和业务c为业务a的下游业务，业务a为业务b和业务c的上游业务，业务d为业务b的下游业务，业务b为业务d的上游业务，以此类推，不再赘述。

具体地，以医疗健康场景为例，业务a为问诊业务，业务b为患者身份验证业务，业务c为患者信息查询接口，业务e为身份证信息查询接口，业务f为社保账号查询接口，业务d为平台账户验证接口，业务g为签约校验业务。

步骤302，对于每个业务，存储所述业务与其下游业务之间的对应关系。

可以在配置中心和缓存中存储各个业务与其下游业务之间的对应关系，存储格式如下所示：

"business_a":["business_b","business_c"],

"business_b":["business_d"],

"business_c":["business_e","business_f"],

"business_d":["business_g"]

当向执行流中增加业务(business_x)[x代表某一个业务]时，只需要关注该业务依赖对应的上下游业务，不需要关心业务的具体位置和循序等问题，当修改或者删除业务时，可以通过依赖关系直观地看出对业务功能的影响，每个业务(business_x)都是独立的，配置可以灵活地改变，满足业务功能需求。

可选地，步骤302可以包括：采用键值对方式或JSON对象方式存储所述业务与其下游业务之间的对应关系，以便于维护各个业务与其下游业务之间的对应关系。

在本发明的实施例中，每个业务都有其自身的业务模块，每个业务模块包括数据容器、验证逻辑、主业务逻辑和后置逻辑；其中，所述数据容器用于存储入参和执行结果，每个业务将各自的入参、业务执行的中间结果和最终的执行结果存储在各自的数据容器中，以方便上游业务从下游业务的数据容器中获取执行结果；所述验证逻辑用于验证主业务逻辑是否具备执行条件；所述主业务逻辑用于对入参进行主业务处理从而得到出参；所述后置逻辑用于组装出参从而得到执行结果。在本发明的实施例中，业务的逻辑按照功能可以分为busiessData(数据容器逻辑)、businessCheck(验证逻辑)、business(主业务逻辑)和businessPostProcessor(后置逻辑)，并且busiessData、businessCheck、business和businessPostProcessor依次执行，如图2所示。其中，busiessData用于创建独立的数据容器，所述数据容器用于存储business运行的入参(调用请求中携带的入参或者当前业务依赖的下游业务的执行结果)、业务执行的中间结果和最终的执行结果；businessCheck用于验证business是否具备执行条件；business用于对数据容器中的入参进行主业务处理从而得到出参，并将出参存储到数据容器中；businessPostProcessor可以在business执行完毕后再执行一些后处理逻辑，比如组装出参从而得到最终的执行结果，然后将执行结果存储到数据容器中。

在本发明的实施例中，业务模块可以灵活地结合不同的扩展点，从而实现业务之间的解耦、提高业务模块的复用性。一个业务的主业务逻辑在代码层面上不再与其他业务产生耦合，耦合主要在businessData中，businessData在不同的业务流程中可以按照业务自行配置，可以同时在一个大业务流程场景中剥离出公共的子流程，可以保障剥离出的子流程的独立性和业务模型的复用性。因此业务流程m1和业务流程m2整体的依赖关系只存在businessData中。各个业务的执行条件、入参和封装逻辑都可能存在一定的差异，本发明实施例通过businessData的灵活配置，可以实现业务与业务流程的解耦，使得子流程可以快速的复用。

步骤303，接收调用当前业务的调用请求，将所述调用请求中携带的入参写入下游业务的数据容器。

当前业务系统接收到调用请求后，对所述调用请求进行解析，从而得到调用请求中携带的入参。接着，判断当前业务是否有依赖的下游业务，如果有，则将调用请求中携带的入参写入下游业务的业务模型。

如图4所示，以业务a为例，业务a接收到调用请求后，判断当前业务是否有依赖的下游业务，由于业务a的下游业务为业务b和业务c，因此，将调用请求中携带的入参写入业务b的数据容器busiessData_b和业务c的数据容器busiessData_c中，以便于业务a和业务b在执行时分别从数据容器中获取入参并进行主业务处理。

步骤304，将所述下游业务的业务模型放入业务队列，并将所述下游业务的状态置为可执行，以使异步线程依次执行所述验证逻辑、所述主业务逻辑和所述后置逻辑之后，将执行结果写入所述数据容器。

将所述调用请求中携带的入参写入下游业务的数据容器之后，将所述下游业务的业务模型放入业务队列，异步线程会从业务队列中取出下游业务的业务模型，然后执行所述业务模型并将执行结果写入所述数据容器，最后将业务模型放回到业务队列中并将所述下游业务的状态修改为执行完成。需要指出的是，如果异步线程执行失败，则不需要将执行结果写入下游业务的数据容器，但是需要将队列中下游业务的状态修改为不可执行。在业务队列中，业务的状态包括可执行、不可执行和执行完成。

如图5所示，业务a的本地线程将业务b的业务模型放入业务队列，并将业务b的状态置为可执行，接着通过远程调用方式使得异步线程从业务队列中取出业务b的业务模型，然后依次执行业务模型中的验证逻辑、主业务逻辑和后置逻辑并将执行结果写入数据容器，最终将业务b的业务模型放回到业务队列中并将业务b的状态修改为执行完成。业务c也是业务a的下游业务，同理，业务a的本地线程也会将业务c的业务模型放入业务队列，并将业务c的状态置为可执行，接着通过远程调用方式使得异步线程从业务队列中取出业务c的业务模型，然后依次执行业务模型中的验证逻辑、主业务逻辑和后置逻辑并将执行结果写入数据容器，最终将业务c的业务模型放回到业务队列中并将业务c的状态修改为执行完成。

可选地，可以使用Thrift接口的回调机制，整体的调度线程不再阻塞等待异步回调返回，使用Thrift线程完成异步调用并通过回调辅助完成业务的状态过程维护，整体分为两种状态过程：本地对象运算操作和远程调用。

步骤305，监听所述业务队列中所述下游业务的状态，若所述下游业务的状态为执行完成，则从所述业务队列中取出所述下游业务的业务模型。

当前业务实时监听业务队列中下游业务的状态，如果下游业务的状态修改为执行完成，则从业务队列中取出下游业务的业务模型。如图5所示，业务a的本地线程实时监听业务队列中业务b和业务c的状态，如果业务b的状态为执行完成，则从业务队列中取出业务b的业务模型。业务c类似，不再赘述。

步骤306，从所述业务模型的数据容器中取出执行结果，将所述下游业务的执行结果写入所述当前业务的数据容器。

如图6所示，业务a的本地线程从业务b的数据容器中取出业务b的执行结果，然后将业务b的执行结果写入业务a的数据容器中；同理，业务a的本地线程从业务c的数据容器中取出业务c的执行结果，然后将业务c的执行结果写入业务a的数据容器中。

步骤307，依次执行所述当前业务的验证逻辑、主业务逻辑和后置逻辑，从而得到所述当前业务的执行结果，并将所述当前业务的执行结果写入所述当前业务的数据容器。

业务a的本地线程依次执行业务a的业务模型中的验证逻辑、主业务逻辑和后置逻辑，从而得到业务a的执行结果并将业务a的执行结果写入业务a的数据容器。

本地线程一方面负责消费队列，完成本地的对象运算和异步调度任务，另一方面负责判断业务执行完毕后是否有新的业务可以放入业务员队列，通过这种方式提高业务接口的性能。

需要指出的是，以图4为例，由于业务b存在下游业务d，那么当调用业务b时，业务b的本地线程会将业务b入参写入业务d的数据容器，待业务d执行完成后，从业务d的数据容器中取出执行结果并写入业务b的数据容器，该过程与业务a类似，不再赘述；同理，由于业务d存在下游业务g，那么当调用业务d时，业务d的本地线程会将业务d入参写入业务g的数据容器，待业务g执行完成后，从业务g的数据容器中取出执行结果并写入业务d的数据容器，该过程与业务a类似，不再赘述。因此，本发明实施例通过编排和异步化方式提高业务接口的性能和业务模型的复用性，从而降低业务接口的耦合性。

另外，在本发明一个可参考实施例中处理业务调用请求的方法的具体实施内容，在上面所述处理务调用请求的方法中已经详细说明了，故在此重复内容不再说明。

图7是根据本发明实施例的处理业务调用请求的装置的主要模块的示意图。如图7所示，所述处理业务调用请求的装置700包括接收模块701、队列模块702、监听模块703和执行模块704；其中，接收模块701用于接收调用当前业务的调用请求，将所述调用请求中携带的入参写入下游业务的业务模型；队列模块702用于将所述下游业务的业务模型放入业务队列，以使异步线程执行所述下游业务的业务模型，将执行结果写入所述下游业务的业务模型并将所述下游业务的状态修改为执行完成；监听模块703用于监听所述业务队列中所述下游业务的状态，若所述下游业务的状态为执行完成，则从所述业务队列中取出所述下游业务的业务模型；执行模块704用于从所述下游业务的业务模型中取出执行结果，将所述下游业务的执行结果写入所述当前业务的业务模型，执行所述当前业务的业务模型，从而得到所述当前业务的执行结果。

可选地，所述业务模型包括数据容器、验证逻辑、主业务逻辑和后置逻辑；

其中，所述数据容器用于存储入参和执行结果；所述验证逻辑用于验证主业务逻辑是否具备执行条件；所述主业务逻辑用于对入参进行主业务处理从而得到出参；所述后置逻辑用于组装出参从而得到执行结果。

可选地，所述接收模块701还用于：

将所述调用请求中携带的入参写入下游业务的数据容器。

可选地，所述队列模块702还用于：

将所述下游业务的业务模型放入业务队列，并将所述下游业务的状态置为可执行，以使异步线程依次执行所述验证逻辑、所述主业务逻辑和所述后置逻辑之后，将执行结果写入所述数据容器。

可选地，所述执行模块704还用于：

从所述业务模型的数据容器中取出执行结果，将所述下游业务的执行结果写入所述当前业务的数据容器；

依次执行所述当前业务的验证逻辑、主业务逻辑和后置逻辑，从而得到所述当前业务的执行结果。

可选地，还包括配置模块，用于：

接收调用当前业务的调用请求之前，配置各个业务之间的上下游依赖关系；

对于每个业务，存储所述业务与其下游业务之间的对应关系。

可选地，采用键值对方式或JSON对象方式存储所述业务与其下游业务之间的对应关系。

需要说明的是，在本发明所述处理业务调用请求的装置的具体实施内容，在上面所述处理业务调用请求的方法中已经详细说明了，故在此重复内容不再说明。

图8示出了可以应用本发明实施例的处理业务调用请求的方法或处理业务调用请求的装置的示例性系统架构800。

如图8所示，系统架构800可以包括终端设备801、802、803，网络804和服务器805。网络804用以在终端设备801、802、803和服务器805之间提供通信链路的介质。网络804可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备801、802、803通过网络804与服务器805交互，以接收或发送消息等。终端设备801、802、803上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备801、802、803可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器805可以是提供各种服务的服务器，例如对用户利用终端设备801、802、803所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的物品信息查询请求等数据进行分析等处理，并将处理结果反馈给终端设备。

需要说明的是，本发明实施例所提供的处理业务调用请求的方法一般由服务器805执行，相应地，所述处理业务调用请求的装置一般设置在服务器805中。

应该理解，图8中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图9，其示出了适于用来实现本发明实施例的终端设备的计算机系统900的结构示意图。图9示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中，还存储有系统900操作所需的各种程序和数据。CPU 901、ROM 902以及RAM903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括接收模块、队列模块、监听模块和执行模块，其中，这些模块的名称在某种情况下并不构成对该模块本身的限定。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，该设备实现如下方法：接收调用当前业务的调用请求，将所述调用请求中携带的入参写入下游业务的业务模型；将所述下游业务的业务模型放入业务队列，以使异步线程执行所述下游业务的业务模型，将执行结果写入所述下游业务的业务模型并将所述下游业务的状态修改为执行完成；监听所述业务队列中所述下游业务的状态，若所述下游业务的状态为执行完成，则从所述业务队列中取出所述下游业务的业务模型。

作为另一方面，本发明实施例还提供了一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述任一实施例所述的方法。

根据本发明实施例的技术方案，因为采用当前业务将下游业务的业务模型放入业务队列，以使异步线程执行下游业务的业务模型，将执行结果写入下游业务的业务模型，当前业务从业务队列中取出下游业务的执行结果并将其写入当前业务的业务模型，执行当前业务的业务模型从而得到当前业务的执行结果的技术手段，所以克服了现有技术中业务接口耦合性强、灵活性差的技术问题。本发明实施例能够对业务接口进行业务模型复用和解耦，从而提高业务接口性能和灵活性，而且本发明实施例能够快速落地业务功能，降低业务模型之间的复杂度，从而降低修改或者升级业务功能的风险。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (11)

1.一种处理业务调用请求的方法，其特征在于，包括：

接收调用当前业务的调用请求，将所述调用请求中携带的入参写入下游业务的业务模型；

将所述下游业务的业务模型放入业务队列，以使异步线程执行所述下游业务的业务模型，将执行结果写入所述下游业务的业务模型并将所述下游业务的状态修改为执行完成；

监听所述业务队列中所述下游业务的状态，若所述下游业务的状态为执行完成，则从所述业务队列中取出所述下游业务的业务模型；

从所述下游业务的业务模型中取出执行结果，将所述下游业务的执行结果写入所述当前业务的业务模型，执行所述当前业务的业务模型，从而得到所述当前业务的执行结果。

2.根据权利要求1所述的方法，其特征在于，所述业务模型包括数据容器、验证逻辑、主业务逻辑和后置逻辑；

其中，所述数据容器用于存储入参和执行结果；所述验证逻辑用于验证主业务逻辑是否具备执行条件；所述主业务逻辑用于对入参进行主业务处理从而得到出参；所述后置逻辑用于组装出参从而得到执行结果。

3.根据权利要求2所述的方法，其特征在于，将所述调用请求中携带的入参写入下游业务的业务模型，包括：

将所述调用请求中携带的入参写入下游业务的数据容器。

4.根据权利要求2所述的方法，其特征在于，将所述下游业务的业务模型放入业务队列，以使异步线程执行所述下游业务的业务模型，将执行结果写入所述下游业务的业务模型并将所述下游业务的状态修改为执行完成，包括：

将所述下游业务的业务模型放入业务队列，并将所述下游业务的状态置为可执行，以使异步线程依次执行所述验证逻辑、所述主业务逻辑和所述后置逻辑之后，将执行结果写入所述数据容器。

5.根据权利要求2所述的方法，其特征在于，从所述下游业务的业务模型中取出执行结果，将所述下游业务的执行结果写入所述当前业务的业务模型，执行所述当前业务的业务模型，从而得到所述当前业务的执行结果，包括：

从所述业务模型的数据容器中取出执行结果，将所述下游业务的执行结果写入所述当前业务的数据容器；

依次执行所述当前业务的验证逻辑、主业务逻辑和后置逻辑，从而得到所述当前业务的执行结果。

6.根据权利要求1所述的方法，其特征在于，接收调用当前业务的调用请求之前，还包括：

配置各个业务之间的上下游依赖关系；

对于每个业务，存储所述业务与其下游业务之间的对应关系。

7.根据权利要求6所述的方法，其特征在于，采用键值对方式或JSON对象方式存储所述业务与其下游业务之间的对应关系。

8.一种处理业务调用请求的装置，其特征在于，包括：

接收模块，用于接收调用当前业务的调用请求，将所述调用请求中携带的入参写入下游业务的业务模型；

队列模块，用于将所述下游业务的业务模型放入业务队列，以使异步线程执行所述下游业务的业务模型，将执行结果写入所述下游业务的业务模型并将所述下游业务的状态修改为执行完成；

监听模块，用于监听所述业务队列中所述下游业务的状态，若所述下游业务的状态为执行完成，则从所述业务队列中取出所述下游业务的业务模型；

执行模块，用于从所述下游业务的业务模型中取出执行结果，将所述下游业务的执行结果写入所述当前业务的业务模型，执行所述当前业务的业务模型，从而得到所述当前业务的执行结果。

9.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行时，所述一个或多个处理器实现如权利要求1-7中任一所述的方法。

10.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-7中任一所述的方法。

11.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-7中任一项所述的方法。

Images