本申请涉及服务调用路由处理技术领域，特别是涉及服务调用路由处理方法、装置及系统。
背景技术：
在“新零售”等线上线下相结合的业务模式下，零售商可以通过线上的应用程序(app)提供商品对象的信息，用户可以通过线上的app进行浏览、购买等行为。同时，零售商还可以开设线下的实体店铺，用户也可以通过线下的实体店铺进行商品对象的购买。同时，线上的订单也可以由线下的实体店铺进行发货等一系列的处理，并最终配送到用户指定的收货地址。但是，有些零售商可能受限于自身的资源或者能力，无法为用户提供完善的发货、配送等服务，甚至在具体进行商品的上架等处理时，也可能存在一些困难，导致效率低下，出错率高等情况。为了使得这种零售商也能够加入到“新零售”系统中，“新零售”平台方可以为零售商提供一些服务，例如，标准化的流程处理服务，零售商可以通过采购平台方的服务，来完善线上线下相结合的销售链路。例如，某零售商可以采购“上架”服务，此时，平台方可以为该零售商提供相对应的解决方案，等等。
通常，具体业务链路上的服务可以是由平台方来提供，但是，随着系统的发展，越来越多的外部商家需要与“新零售”平台进行合作。例如，某外部商家也能够提供“上架”服务，也希望加入到“新零售”系统中，使得其他零售商也可以采购该外部商家提供的服务来解决某类问题，进而，使得这种外部商家也能够通过销售这种服务的方式，来作为另一种收入来源。
但是，能够提供上述业务链路上相关服务的商家，其内部通常也会使用具体的erp系统来实现各种信息、数据的管理。例如，商家a内部使用了一种erp系统，其内部在具体实现商品上架处理时，采用的具体方式方法，与“新零售”系统平台方默认的上架处理的方法可能是不同的。此时，外部商家接入平台时，可能会希望继续沿用自己内部惯用的处理方式，而不是统一使用平台方的方案，后者需要对外部商家内部的软硬件系统进行改造升级，成本会比较高。
因此，如何灵活的支持业务场景，快速、低成本的进行新商家的接入，成为需要本领域技术人员解决的技术问题。
技术实现要素：
本申请提供了服务调用路由处理方法、装置及系统，能够灵活的支持业务场景，快速、低成本的进行新商家的接入。
本申请提供了如下方案：
一种服务调用路由处理系统，包括：
第一系统，用于提供服务接口，并存储服务接口与服务实现信息之间的对应关系，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
第二系统，用于通过所述服务接口发起对服务实现的调用请求；
流程引擎系统，用于部署到所述第二系统中，并从所述第一系统获得所述对应关系信息，根据所述第二系统的调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
一种服务调用路由处理方法，包括：
获得服务接口与服务实现之间的对应关系信息，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
在服务调用方通过所述服务接口发起对服务实现的调用请求时，根据所述调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
一种服务调用路由处理方法，包括：
提供服务接口，并存储服务接口与服务实现信息之间的对应关系，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
将所述对应关系信息提供给服务提供方关联的流程引擎系统，以便在所述服务提供方发起调用请求时，根据所述调用请求传入的信息以及所述对应关系，定位到目标服务接口下的目标服务实现。
一种服务调用路由处理装置，包括：
对应关系获得单元，用于获得服务接口与服务实现之间的对应关系信息，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
服务实现定位单元，用于在服务调用方通过所述服务接口发起对服务实现的调用请求时，根据所述调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
一种服务调用路由处理装置，包括：
信息存储单元，用于提供服务接口，并存储服务接口与服务实现信息之间的对应关系，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
信息提供单元，用于将所述对应关系信息提供给服务提供方关联的流程引擎系统，以便在所述服务提供方发起调用请求时，根据所述调用请求传入的信息以及所述对应关系，定位到目标服务接口下的目标服务实现。
一种电子设备，包括：
一个或多个处理器；以及
与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
获得服务接口与服务实现之间的对应关系信息，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
在服务调用方通过所述服务接口发起对服务实现的调用请求时，根据所述调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
根据本申请提供的具体实施例，本申请公开了以下技术效果：
通过本申请实施例，在通过将标准作业程序流程按照逻辑节点粒度进行拆分并抽象后定义出服务接口，并由服务提供方根据所述服务接口对应的定义信息提供出对应的服务实现代码的基础上，可以提供流程引擎子系统客户端，该客户端可以部署到服务调用方客户端中。具体在服务调用方进行调用的过程中，可以根据服务接口与服务实现之间的对应关系信息，以及被调用的流程对应的任务中指定的服务接口标识以及用于定位该服务接口下具体服务实现的参数信息，定位待调用的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方客户端向所述服务地址发起调用。以此实现对服务实现层级的路由，从而完整地支持业务场景，快速、低成本的进行新商家的接入。
当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的系统的示意图；
图2是本申请实施例提供的第一方法的流程图；
图3是本申请实施例提供的第二方法的流程图；
图4是本申请实施例提供的第一装置的示意图；
图5是本申请实施例提供的第二装置的示意图；
图6是本申请实施例提供的电子设备的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
首先需要说明的是，在“新零售”等线上与线下相结合的服务模式下，业务场景复杂，业务链路很长，实现了一整套从供应链到用户端的中台系统。在此过程中，服务平台中的业务方经常需要处理多种标准作业流程。例如，对于面向消费者的业务方，可能会涉及到处理下单流程，发货流程等。而对于面向商家的业务方，则可能更需要处理上架流程，仓调货流程，仓补货流程，仓配送流程，修改商品价格流程等等。其中，每个流程中都可能包括多个业务逻辑节点，例如，对于商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点。
现有技术中，平台方是使用了基于应用的开发模式，开发者按照应用维度进行代码开发，使得一个应用中通常包含了一个具体流程中的多个节点的实现。例如，对于前述例子中的商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点，在现有技术中，会将上述流程中各个节点上的实现代码组合在一起，绑定在同一个单元里，一起开发，一起部署，一起对外提供服务。此时，假设对于上述流程中的打包服务，除了平台方能够提供相应的实现之外，另外还有两个合作的商家a、b，也能够提供各自的实现，则需要加入到上述流程中时，但是原有的流程上的实现可能就无法满足新商家的需求。比如：原流程为start->节点a->节点b->节点c->end。当有一个新商家需要加入流程时，“节点a”对应的服务实现是按照平台的默认方式来实现的，无法满足该商家a的需求，需要基于对节点a节点新增一个实现方式：“a服务的实现2”。此时，如果按照传统的流程引擎，可以有以下几种方案：方案1：重新定义一个新流程，依旧包含“start->节点a->节点b->节点c->end”，修改“服务a”的实现方式为“a服务的实现2”。方案2：使用原流程，但需要修改流程对应的代码，在代码中写条件语句，用以判断选择哪个调用服务，也即硬编码方式。方案3：在原流程的基础上，新增分支流程，即新增选择节点，在选择节点上增加判断条件，同时，新增条件对应的选项，通过判断条件选择调用哪个服务。这三种方案各有缺陷：方案1，需要维护多套流程，维护成本高。一旦流程模板进行了修改，对应的所有流程均需要进行修改。方案2，业务逻辑依赖代码来实现，一旦有新流程接入，就需要对流程对应的代码进行修改，这是一种侵入式的实现方式，每次修改均需进行代码发布，发布风险高，且逻辑在代码中对于非技术人员不友好。方案3，一旦有新商家接入，都需要修改流程配置，无法保持一个相对稳态的流程。
而在本申请实施例中，为了能够更灵活地支持业务场景，快速、低成本的进行新商家的接入，首先可以将“新零售”等服务平台中的标准作业程序流程以节点为单位，抽象出标准服务接口(在本申请实施例中可以称为spi)，并提供第一系统，可以用于对具体的服务接口进行定义，并进行注册；之后，可以将这种服务接口的定义信息提供给具体的服务提供方(例如，服务平台本身，或者其他的外部商家等，在本申请实施例中，称为第三系统)，服务提供方则可以按照具体的服务对应的标准作业接口规范，提供具体的服务实现(在本申请实施例中可以称为bundle)。也就是说，在本申请实施例中，具体流程上的业务逻辑节点不再对应某一个固定的具体实现，而是以接口的形式存在，在定义服务接口时，只需要定义其入参、出参、功能等，而无需提供具体的实现代码。换言之，一个服务接口只需要定义出对应何种功能，需要哪些入参，哪些出参，而不需要提供具体的实现代码。具体的服务提供方则可以为具体的服务接口提供多种不同的服务实现，例如，对于“拣货”这种服务接口，在服务接口级别，无需确定具体如何实现拣货功能，但是，商家a能够提供具体的拣货服务，则可以为该服务接口提供具体的服务实现代码，也即，由商家a根据该商家a的具体拣货实现逻辑，提供关于该拣货服务的服务实现代码。另外，如果商家b也能够提供具体的拣货服务，则也可以根据该商家b内部的具体拣货实现逻辑，提供对应的拣货服务实现代码。通过这种方式，使得业务流程中的不同节点之间实现相互解耦，不同节点上的服务实现可以独立开发，独立部署，独立对外提供服务。并且，对于同一服务接口而言，可以由多个不同的服务提供方提供多种不同的服务实现代码，分别注册到流程引擎子系统中，使得同一个服务接口可以有“多态”实现。
也就是说，在本申请实施例中，可以由平台方抽象出具体的服务接口，然后由服务提供方提供具体的服务实现代码，每个服务提供方的服务实现代码都可以是按照服务提供方内部erp(企业管理计划)系统中的服务实现逻辑来进行开发的。另外，具体的服务提供方所提供的服务实现代码，可以直接保存在服务提供方自己的服务器上，后续在被具体的服务调用方调用时，这种服务实现代码也可以在服务提供方自己的服务器上运行，按照服务提供方内部的实现逻辑来执行具体的操作，并将处理结果返回给服务调用方。
在通过上述方式进行了服务接口的抽象及定义，并为具体的服务接口提供了至少一个服务实现之后，服务调用方(例如，具体的业务方，等等，在本申请实施例中，可以称为第二系统)则可以通过具体的服务接口调用该服务接口下的其中一个具体的服务实现，以此获得相应的服务。服务调用方在具体进行服务调用时，可以指定所需调用的服务的id或者名称，还可以对具体所需服务实现的信息进行指定，再由具体的路由引擎将具体的调用请求路由到具体某个服务实现对应的服务地址。其中，具体在进行服务实现的指定时，可以在调用代码中设定具体的参数信息。为了便于服务调用方进行调用参数的设定，服务提供方在提供服务实现代码时，还可以设定具体的路由规则。例如，可以一种形式下，可以直接指定具体的服务实现的id或者名称等标识信息，使得流程引擎能够直接通过服务实现的id或名称定位到具体所需调用的服务实现代码。或者，另一种实现形式下，还可以通过正则运算等方式来进行指定，此时，具体传入的参数可以是一些间接的信息，例如，可以是仓库类型，仓库id等信息，然后通过正则运算的方式定位到具体的服务实现代码。
例如，在某“新零售”模式的服务系统中，为了能够在该系统的标准业务链路上，为系统的标准服务接入不同合作方的erp系统，实现某一服务节点的多样化，本申请实施例针对具体业务链路上的每一种服务进行抽象，定义服务的标准接口，可以称之为spi，例如，包括拣货服务接口，打包服务接口，上架服务接口，等等。将服务的具体实现，称之为bundle，一个spi可以有多个bundle实现，做到服务实现的多态化。比如，在前述商品上架流程中，包括的拣货，打包，装箱，上架这四个节点，则在本申请实施例中，可以抽象为四个服务接口，分别为拣货服务接口，打包服务接口，装箱服务接口，上架服务接口。其中，拣货服务接口这个spi，可以由服务提供方1提供服务实现；打包服务接口这个spi，可以有服务提供方a提供的默认实现(defaultbundle)，也可以有服务提供方2提供的实现(例如，darunfabundle)，等等。
在进行了服务接口的抽象，并在服务粒度上开发了服务实现后，可以注册到服务系统中，这样，具体的实体店铺中的服务调用方便可以通过对上述服务实现的调用，来获得某种具体的功能。例如，实体店铺a中的服务调用方可以对服务提供方1提供的打包服务的实现进行调用，实现打包功能，对服务提供方2的上架服务的实现进行调用，实现上架功能；实体店铺b中的服务调用方可以对服务提供方1提供的拣货服务的实现进行调用，实现拣货功能，对服务提供方2的上架服务的实现进行调用，实现上架功能，等等。也就是说，同一服务调用方客户端在实现标准作业流程的过程中，可以通过对多种不同服务对应的实现的编排，包括设定不同服务之间的调用关系等，使用多个不同的服务提供方提供的服务实现来共同解决实际业务场景中的具体问题。
也就是说，在本申请实施例中，平台方不再以应用的粒度进行服务代码的开发，而是以服务接口的粒度进行开发，其中，具体的服务接口是将商品对象服务流程中按照节点粒度进行拆分后进行抽象并定义的。之后，服务提供方可以为具体的服务接口提供服务实现。其中，一个服务接口可能会对应多个服务实现，此时，在服务调用方进行服务调用的过程中进行服务路由的时候，需要能够正确的路由到一个服务接口下某一具体的服务实现，才能实现正确的调用。而传统的方案中，服务定义即服务实现，因此，传统的流程引擎只能根据服务名称路由到某一具体服务定义这一层，并不能解决上述问题。
为此，在本申请实施例中，主要针对上述问题，提供了相应的解决方案。在该方案中，可以提供一流程引擎，该流程引擎可以部署到服务调用方的客户端中，在服务调用方会上述定义的服务接口进行调用的过程中，该流程引擎可以根据具体传入的参数等信息，定位到该服务接口下的具体服务实现，并返回该服务实现的服务地址，调用方可以向该服务地址发起调用，以此实现到服务实现这一层的路由。
下面对本申请实施例提供的具体实现方案进行详细介绍。
实施例一
该实施例一首先提供了一种服务调用路由处理系统，如图1所示，该系统具体可以包括：
第一系统101，用于提供服务接口，并存储服务接口与服务实现信息之间的对应关系，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
第二系统102，用于通过所述服务接口发起对服务实现的调用请求；
流程引擎系统103，用于部署到所述第二系统中，并从所述第一系统获得所述对应关系信息，根据所述第二系统的调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
其中，第一系统101具体就可以是服务平台对应的系统，具体可以用于提供服务接口，并存储服务接口与服务实现之间的对应关系。其中，第一系统可以提供服务接口定义子系统，用于进行服务接口的定义以及注册；另外，还可以为服务提供方提供服务实现配置子系统，用于按照具体服务对应的标准接口规范，提供对应的服务实现。其中，具体的服务实现可以由平台方自己提供，也可以由外部的服务提供方(外部的商家等，在本申请实施例中可以称为第三系统)来提供。其中，第三系统中通常也会具有自己的erp系统，具体的服务实现可以用于与第三系统内的erp系统对接。也就是说，第三系统可以根据关联的企业管理计划erp系统中对目标节点的处理逻辑，为所述目标节点对应的服务接口提供服务实现，并注册到所述第一系统中，以便将所述第三系统中对所述目标节点的处理逻辑接入到所述第一系统中。
在完成具体的服务接口的定义以及服务实现的提供之后，第一系统可以对服务接口与服务实现信息之间的对应关系进行保存。其中，具体实现时，由于系统中的服务接口数量众多，因此，为了便于查询，还可以提供管理功能，此时，在进行服务的定义时，还可以指定服务的类别等信息，使得系统可以对具体的服务进行分类保存。例如，具体可以分为测试类、商品类、库存类、履约类，等等。这样，在具体实现时，具体保存的信息可以如表1所示：
表1
另外，在本申请实施例中，涉及到服务实现一层的路由，为了实现路由，调用方可以直接通过调用请求中的参数传入具体的服务实现的id或名称等标识信息。此时，流程引擎可以很方便的进行目标服务实现的定位。但是，在实际应用中，具体所需调用的服务实现可能会根据实际的运行情况进行动态设定。例如，某个服务调用方在调用“仓调货”这个接口时，具体的仓库类型有多种，根据不同的仓库类型，需要定位到不同的服务实现。例如，当仓库类型为某商家a的仓库时，需要调用该商家a提供的服务实现，当仓库类型为某商家b的仓库时，需要调用该商家b提供的服务实现，等等。为了支持这种情况的实现，还可以允许服务调用方在调用请求中使用间接的参数，而不是直接设定服务实现的标识。例如，在前述例子中，可以直接将传入的参数设定为仓库类型，此时，流程引擎可以根据具体传入的参数值，进行具体的正则运算或者其他的运算，定位出具体的目标服务实现。
针对上述可能会传入间接参数的情况，服务提供方在提供具体的服务实现时，还可以对服务实现对应的路由规则信息进行配置，例如，具体可以提供具体可用的参数，并且可以提供具体的匹配条件信息。其中，具体的参数可以是一个，也可以是多个。在需要设定多个参数时，具体的匹配条件可以通过正则表达式或者其他形式来进行表达。这样，第一系统在保存上述对应关系时，还可以对所述服务实现对应的路由规则信息进行保存。流程引擎在拉取具体的服务接口与服务实现之间的对应关系信息的同时，还可以拉取到具体的服务实现对应的路由规则信息。具体在进行路由时，可以根据传入的间接参数，以及对应的路由规则进行具体服务实现的定位。
也就是说，在这种情况下，第一系统中保存的信息会包括上述路由规则信息，具体如表2(其中省略了服务接口的类别、id、版本等信息)所示：
表2
通过上述第一系统保存了服务接口与服务实现信息之间的对应关系，或者还包括上述路由规则信息的情况下，第二系统102便可以通过所述服务接口发起对服务实现的调用请求。其中，第二系统具体可以是平台内的业务方系统，或者，还可以是其他的需要使用上述服务的商家等。例如，某商家在线下开设了实体店铺，同时在线上开设了对应的虚拟店铺，在用户通过线上进行下单之后，该商家无法为该用户提供具体的配送服务。此时，该商家便可以通过本申请实施例中提供的配送节点上的服务实现，来为用户提供具体的配送服务。其中，在具体进行服务接口调用的过程中，就会用到本申请实施例中提供的流程引擎，以便将具体的调用请求路由到具体某个服务实现的服务地址。
其中，具体的流程引擎系统可以部署在第二系统客户端内，并且，可以从所述第一系统获得所述对应关系信息。具体的，可以是在具体的第二系统第一次进行服务调用时，此时第二系统的终端设备本地还没有服务列表(也即本申请实施例中的对应关系信息)，因此，可以从第一系统中进行拉取获得具体的对应关系。其中，如果服务实现对应有路由规则，则也可以记录在上述对应关系中，因此，可以一并拉取到第二系统的终端设备本地。这样，在所述第二系统发起调用请求时，便可以根据所述调用请求传入的目标服务接口的标识信息以及用于与服务实现相关的参数信息，确定目标服务接口下的目标服务实现，并向所述第二系统返回所述目标服务实现的服务地址，以便所述第二系统向所述目标服务实现的服务地址发起调用。例如，对于前述“仓调货”这一服务的例子，如果调用参数中携带的是服务实现的id或者名称，则可以直接定位出该id或名称对应的服务实现，并路由到该服务实现的服务地址。或者，如果调用参数中携带的是仓库id等间接参数，则可以通过判断仓库id是哪个仓库，路由到该仓库对应的仓调货服务的实现对应的服务地址。或者，如果调用参数中携带的是仓库类型信息，此时，流程引擎还可以通过判断仓类型，路由到该仓库对应的仓调货服务的实现对应的服务地址，等等。
为了更好的理解上述路由的过程，下面通过更为具体的例子进行介绍。
假设仓内作业服务有系统内的默认实现defaultbundle，及某合作的商家提供的darunfabundle两个服务实现。在基于服务多态化实现路由方案下，一个完整的服务注册及服务调用具体步骤可以包括：
步骤一：仓内作业服务向服务配置中心注册服务多态化实现，包括系统内的默认实现defaultbundle与另一合作方商家的实现darunfabundle，服务配置中心记录spi与多态化实现bundle之间的关系，并更新服务列表；
步骤二：履约服务调用调用仓内作业服务，伪代码为：bundle.broker(“仓内作业服务”,“版本号”,patternfunction())；
步骤三：bundlebroker(流程引擎，也可以称为分布式多态服务调用组件)发现为第一次调用，此时本地还没有服务列表，因此，可以从服务配置中心拉取服务列表。非第一次调用时，这一步跳过；
步骤四：bundlebroker通过patternfunction()计算要路由的具体服务实现。patternfunction()的实现形式可以是，根据传入的服务实现的名称/id，直接定位到一个服务实现，或者根据传入其他的参数，通过正则或其他计算方式得到服务实现的名称或id。假设此处patternfunction()根据动态传入参数，计算结果为darunfabundle；
步骤五：bundlebroker根据服务名称，版本号，patternfunction()计算结果，最终定位到仓内作业服务对应的darunfabundle这一实现，此时，bundlebroker还可以从服务列表读取服务实现的服务地址，还可以根据一定的负载均衡算法确定某一服务实现的服务地址，并发起一次请求。
其中，在可选的实现方式下，具体服务实现的实现代码可以保存在具体的服务提供方的服务器中，而流程引擎具体可以部署在服务调用方客户端，也就是说，服务调用方可以在自己的客户端中引入本申请实施例中的流程引擎，服务提供方则可以在自己的服务器上提供具体的功能。双方之间通过服务调用方中的流程引擎作为桥梁，使得服务调用方能够根据自己的业务需求发起调用请求，流程引擎将具体的调用请求路由到具体的实现所在的服务地址，该服务地址也即该实现的代码在对应服务器中的保存服务地址，之后，具体的实现代码执行结果还可以返回给服务调用方，使得服务调用方实现对应的功能，以此实现对具体服务实现的远程调用。
也就是说，在本申请实施例中，第一系统保存的对应关系中具体记录的可以是服务实现的标识，服务地址等信息。在实际应用中，服务提供方一侧的服务器可能是以分布式服务器集群的形式存在，此时，具体的服务实现的实现代码可能会分布式地保存在多个服务器中，分别对应有不同的服务地址。例如，具体的第一系统中保存的信息可以如以下表3所示：
表3
此时，流程引擎系统在确定出目标服务实现后，还可以根据预置的负载均衡算法，从分布式服务器中确定目标服务器，并确定所述目标服务实现在该目标服务器中的服务地址，并返回给所述第二系统。这样，可以实现分布式的路由实现。
另外，如前文所述，第一系统可以在接收到具体某个第二系统内部署的流程引擎系统的拉取请求后，向该流程引擎系统提供具体的服务接口与服务实现信息之间的对应关系。在具体实现时，由于第一系统中记录的对应关系可能会经常发生更新，因此，为了便于具体的流程引擎及时地获得最新的对应关系信息，第一系统还可以对已经拉取过具体对应关系的第二系统的标识信息进行保存，另外还可以保存具体拉取的对应关系信息的版本等信息。这样，在对应关系发生更新时，第一系统可以向第二系统的流程引擎系统进行更新信息的推送。
通过本申请实施例，在通过将标准作业程序流程按照逻辑节点粒度进行拆分并抽象后定义出服务接口，并由服务提供方根据所述服务接口对应的定义信息提供出对应的服务实现代码的基础上，可以提供流程引擎子系统客户端，该客户端可以部署到服务调用方客户端中。具体在服务调用方进行调用的过程中，可以根据服务接口与服务实现之间的对应关系信息，以及被调用的流程对应的任务中指定的服务接口标识以及用于定位该服务接口下具体服务实现的参数信息，定位待调用的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方客户端向所述服务地址发起调用。以此实现对服务实现层级的路由，从而完整地支持业务场景，快速、低成本的进行新商家的接入。
实施例二
该实施例二是与实施例一对应的，从流程引擎系统的角度，提供了一种服务调用路由处理方法，参见图2，该方法具体可以包括：
s201：获得服务接口与服务实现之间的对应关系信息，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
s202：在服务调用方通过所述服务接口发起对服务实现的调用请求时，根据所述调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
具体实现时，所述服务调用方的调用请求中传入的信息包括：目标服务接口的标识信息以及用于与服务实现相关的参数信息；此时，具体可以根据目标服务接口的标识信息、与服务实现相关的参数信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
具体的，所述调用请求中传入的参数包括服务实现的标识信息；此时，可以根据所述对应关系信息确定所述目标服务接口对应的多个服务实现的标识信息；将所述参数中传入的标识信息对应的服务实现确定为所述目标服务实现。
或者，在另一种方式下，还可以获得所述服务实现对应的路由规则信息，所述路由规则中包括用于间接确定服务实现的参数，以及对应的匹配条件信息；此时，所述调用请求中传入的参数包括用于间接确定服务实现的参数；可以首先根据所述对应关系信息确定所述目标服务接口对应的服务实现的路由规则信息；然后，根据所传入的参数信息与服务实现对应的路由规则中的匹配条件的匹配结果，确定所述目标服务实现。
具体实现时，还可以向所述服务调用方返回所述目标服务实现的服务地址，以便所述服务调用方向所述目标服务实现的服务地址发起调用。
其中，所述服务实现对应的代码可以保存在所述服务提供方侧的服务器中，所述服务实现对应的服务地址为所述服务提供方侧的服务其中的保存地址；此时，所述服务调用方可以通过向所述服务地址发起远程调用的方式获得对应的服务。
其中，所述服务提供方侧的服务器可以为分布式服务器，所述服务实现代码对应在多个不同服务器中的不同服务地址；此时，可以根据预置的负载均衡算法，从分布式服务器中确定目标服务器，并确定所述目标服务实现在该目标服务器中的服务地址，并返回给所述第二系统。
实施例三
该实施例三也是与实施例一对应的，从第一系统的服务器的角度，提供了一种服务调用路由处理方法，参见图3，该方法具体可以包括：
s301：提供服务接口，并存储服务接口与服务实现信息之间的对应关系，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
s302：将所述对应关系信息提供给服务提供方关联的流程引擎系统，以便在所述服务提供方发起调用请求时，根据所述调用请求传入的信息以及所述对应关系，定位到目标服务接口下的目标服务实现。
具体的，可以根据服务提供方关联的流程引擎系统的拉取请求，将所述对应关系信息提供给流程引擎系统。
在实际应用中，第一系统还可以对已拉取所述对应关系的服务提供方的标识进行记录，并在所述对应关系信息发生更新时，将更新信息向所述服务提供方关联的流程引擎系统进行推送。
关于上述实施例二以及实施例三中的未详述部分，可以参见前述实施例一中的记载，这里不再赘述。
与实施例二相对应，本申请实施例还提供了一种服务调用路由处理装置，参见图4，该装置可以包括：
对应关系获得单元401，用于获得服务接口与服务实现之间的对应关系信息，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
服务实现定位单元402，用于在服务调用方通过所述服务接口发起对服务实现的调用请求时，根据所述调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
具体实现时，所述服务调用方的调用请求中传入的信息包括：目标服务接口的标识信息以及用于与服务实现相关的参数信息；
所述服务实现定位单元具体可以用于：根据目标服务接口的标识信息、与服务实现相关的参数信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
更为具体的，所述与服务实现相关的包括服务实现的标识信息；
此时，所述服务实现定位单元具体可以用于：根据所述对应关系信息确定所述目标服务接口对应的多个服务实现的标识信息；将所述参数中传入的标识信息对应的服务实现确定为所述目标服务实现。
另一种方式下，所述对应关系获得单元还可以用于，获得所述服务实现对应的路由规则信息，所述路由规则中包括用于间接确定服务实现的参数，以及对应的匹配条件信息；此时，所述与服务实现相关的参数包括用于间接确定服务实现的参数；
所述服务实现定位单元具体可以用于：根据所述对应关系信息确定所述目标服务接口对应的服务实现的路由规则信息；根据所传入的参数信息与服务实现对应的路由规则中的匹配条件的匹配结果，确定所述目标服务实现。
另外，该装置还可以包括：
服务地址返回单元，用于向所述服务调用方返回所述目标服务实现的服务地址，以便所述服务调用方向所述目标服务实现的服务地址发起调用。
其中，所述服务实现对应的代码保存在所述服务提供方侧的服务器中，所述服务实现对应的服务地址为所述服务提供方侧的服务其中的保存地址；所述服务调用方通过向所述服务地址发起远程调用的方式获得对应的服务。
其中，所述服务提供方侧的服务器为分布式服务器，所述服务实现代码对应在多个不同服务器中的不同服务地址；
服务地址返回单元具体可以用于：根据预置的负载均衡算法，从分布式服务器中确定目标服务器，并确定所述目标服务实现在该目标服务器中的服务地址，并返回给所述服务调用方。
与实施例三相对应，本申请实施例还提供了一种服务调用路由处理装置，参见图5，该装置可以包括：
信息存储单元501，用于提供服务接口，并存储服务接口与服务实现信息之间的对应关系，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
信息提供单元502，用于将所述对应关系信息提供给服务提供方关联的流程引擎系统，以便在所述服务提供方发起调用请求时，根据所述调用请求传入的信息以及所述对应关系，定位到目标服务接口下的目标服务实现。
其中，信息提供单元具体可以用于：根据服务提供方关联的流程引擎系统的拉取请求，将所述对应关系信息提供给流程引擎系统。
另外，该装置还可以包括：
对已拉取所述对应关系的服务提供方的标识进行记录；
在所述对应关系信息发生更新时，将更新信息向所述服务提供方关联的流程引擎系统进行推送。
另外，本申请实施例还提供了一种电子设备，包括：
一个或多个处理器；以及
与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
获得服务接口与服务实现之间的对应关系信息，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
在服务调用方通过所述服务接口发起对服务实现的调用请求时，根据所述调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
其中，图6示例性的展示出了计算机系统的架构，具体可以包括处理器610，视频显示适配器611，磁盘驱动器612，输入/输出接口613，网络接口614，以及存储器620。上述处理器610、视频显示适配器611、磁盘驱动器612、输入/输出接口613、网络接口614，与存储器620之间可以通过通信总线630进行通信连接。
其中，处理器610可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。
存储器620可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器620可以存储用于控制计算机系统600运行的操作系统621，用于控制计算机系统600的低级别操作的基本输入输出系统(bios)。另外，还可以存储网页浏览器623，数据存储管理系统624，以及服务调用处理系统625等等。上述服务调用处理系统625就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器620中，并由处理器610来调用执行。
输入/输出接口613用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
网络接口614用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。
总线630包括一通路，在设备的各个组件(例如处理器610、视频显示适配器611、磁盘驱动器612、输入/输出接口613、网络接口614，与存储器620)之间传输信息。
另外，该计算机系统600还可以从虚拟资源对象领取条件信息数据库641中获得具体领取条件的信息，以用于进行条件判断，等等。
需要说明的是，尽管上述设备仅示出了处理器610、视频显示适配器611、磁盘驱动器612、输入/输出接口613、网络接口614，存储器620，总线630等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上对本申请所提供的服务调用路由处理方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。
1.一种服务调用路由处理系统，其特征在于，包括：
第一系统，用于提供服务接口，并存储服务接口与服务实现信息之间的对应关系，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
第二系统，用于通过所述服务接口发起对服务实现的调用请求；
流程引擎系统，用于部署到所述第二系统中，并从所述第一系统获得所述对应关系信息，根据所述第二系统的调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
2.根据权利要求1所述的系统，其特征在于，
所述第二系统的调用请求中传入的信息包括：目标服务接口的标识信息以及用于与服务实现相关的参数信息；
所述流程引擎系统具体用于，根据目标服务接口的标识信息、与服务实现相关的参数信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
3.根据权利要求2所述的系统，其特征在于，
所述与服务实现相关的参数包括服务实现的标识信息；
所述流程引擎系统具体用于，
根据所述对应关系信息确定所述目标服务接口对应的多个服务实现的标识信息；
将所述参数中传入的标识信息对应的服务实现确定为所述目标服务实现。
4.根据权利要求2所述的系统，其特征在于，
所述第一系统还用于，存储服务实现对应的路由规则信息，所述路由规则中包括用于间接确定服务实现的参数，以及对应的匹配条件信息；
所述与服务实现相关的包括所述用于间接确定服务实现的参数；
所述流程引擎系统具体用于，
根据所述对应关系信息确定所述目标服务接口对应的服务实现的路由规则信息；
根据所传入的参数信息与服务实现对应的路由规则中的匹配条件的匹配结果，确定所述目标服务实现。
5.根据权利要求1所述的系统，其特征在于，
所述流程引擎系统还用于：向所述第二系统返回所述目标服务实现的服务地址，以便所述第二系统向所述目标服务实现的服务地址发起调用。
6.根据权利要求5所述的系统，其特征在于，
所述服务实现对应的代码保存在所述服务提供方侧的服务器中，所述服务实现对应的服务地址为所述服务提供方侧的服务其中的保存地址；
所述第二系统在对所述服务地址发起调用时具体用于，通过向所述服务地址发起远程调用的方式获得对应的服务。
7.根据权利要求6所述的系统，其特征在于，
所述服务提供方侧的服务器为分布式服务器，所述服务实现代码对应在多个不同服务器中的不同服务地址；
所述流程引擎系统具体用于，
在确定出目标服务实现后，根据预置的负载均衡算法，从分布式服务器中确定目标服务器，并确定所述目标服务实现在该目标服务器中的服务地址，并返回给所述第二系统。
8.根据权利要求1至7任一项所述的系统，其特征在于，
所述流程引擎系统具体用于，在所述第二系统首次发起调用请求时，从所述第一系统拉取所述对应关系信息。
9.根据权利要求8所述的系统，其特征在于，
所述第一系统还用于，对已拉取所述对应关系的第二系统的标识进行记录，在所述对应关系信息发生更新时，将更新信息向所述第二系统的流程引擎系统进行推送。
10.根据权利要求1至7任一项所述的系统，其特征在于，
同一个服务接口对应多个不同的服务实现。
11.一种服务调用路由处理方法，其特征在于，包括：
获得服务接口与服务实现之间的对应关系信息，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
在服务调用方通过所述服务接口发起对服务实现的调用请求时，根据所述调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
12.根据权利要求11所述的方法，其特征在于，
所述服务调用方的调用请求中传入的信息包括：目标服务接口的标识信息以及用于与服务实现相关的参数信息；
所述定位到目标服务接口下的目标服务实现，包括：
根据目标服务接口的标识信息、与服务实现相关的参数信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
13.根据权利要求12所述的方法，其特征在于，
所述与服务实现相关的包括服务实现的标识信息；
所述定位到目标服务接口下的目标服务实现，包括：
根据所述对应关系信息确定所述目标服务接口对应的多个服务实现的标识信息；
将所述参数中传入的标识信息对应的服务实现确定为所述目标服务实现。
14.根据权利要求12所述的方法，其特征在于，还包括：
获得所述服务实现对应的路由规则信息，所述路由规则中包括用于间接确定服务实现的参数，以及对应的匹配条件信息；
所述与服务实现相关的参数包括用于间接确定服务实现的参数；
所述定位到目标服务接口下的目标服务实现，包括：
根据所述对应关系信息确定所述目标服务接口对应的服务实现的路由规则信息；
根据所传入的参数信息与服务实现对应的路由规则中的匹配条件的匹配结果，确定所述目标服务实现。
15.根据权利要求11所述的方法，其特征在于，还包括：
向所述服务调用方返回所述目标服务实现的服务地址，以便所述服务调用方向所述目标服务实现的服务地址发起调用。
16.根据权利要求15所述的方法，其特征在于，
所述服务实现对应的代码保存在所述服务提供方侧的服务器中，所述服务实现对应的服务地址为所述服务提供方侧的服务其中的保存地址；所述服务调用方通过向所述服务地址发起远程调用的方式获得对应的服务。
17.根据权利要求16所述的方法，其特征在于，
所述服务提供方侧的服务器为分布式服务器，所述服务实现代码对应在多个不同服务器中的不同服务地址；
所述向所述服务调用方返回所述目标服务实现的服务地址，包括：
根据预置的负载均衡算法，从分布式服务器中确定目标服务器，并确定所述目标服务实现在该目标服务器中的服务地址，并返回给所述服务调用方。
18.一种服务调用路由处理方法，其特征在于，包括：
提供服务接口，并存储服务接口与服务实现信息之间的对应关系，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
将所述对应关系信息提供给服务提供方关联的流程引擎系统，以便在所述服务提供方发起调用请求时，根据所述调用请求传入的信息以及所述对应关系，定位到目标服务接口下的目标服务实现。
19.根据权利要求18所述的方法，其特征在于，
所述将所述对应关系信息提供给服务提供方关联的流程引擎系统，包括：
根据服务提供方关联的流程引擎系统的拉取请求，将所述对应关系信息提供给流程引擎系统。
20.根据权利要求18所述的方法，其特征在于，
对已拉取所述对应关系的服务提供方的标识进行记录；
在所述对应关系信息发生更新时，将更新信息向所述服务提供方关联的流程引擎系统进行推送。
21.一种服务调用路由处理装置，其特征在于，包括：
对应关系获得单元，用于获得服务接口与服务实现之间的对应关系信息，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
服务实现定位单元，用于在服务调用方通过所述服务接口发起对服务实现的调用请求时，根据所述调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
22.一种服务调用路由处理装置，其特征在于，包括：
信息存储单元，用于提供服务接口，并存储服务接口与服务实现信息之间的对应关系，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
信息提供单元，用于将所述对应关系信息提供给服务提供方关联的流程引擎系统，以便在所述服务提供方发起调用请求时，根据所述调用请求传入的信息以及所述对应关系，定位到目标服务接口下的目标服务实现。
23.一种电子设备，其特征在于，包括：
一个或多个处理器；以及
与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
获得服务接口与服务实现之间的对应关系信息，其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；所述服务实现信息包括服务实现对应的服务地址信息；
在服务调用方通过所述服务接口发起对服务实现的调用请求时，根据所述调用请求中传入的信息以及所述对应关系信息，定位到目标服务接口下的目标服务实现。
技术总结