CN111510393A - 流量调度方法、装置及系统 - Google Patents

Abstract

本申请实施例公开了流量调度方法、装置及系统，所述系统包括：服务端，包括文件子系统，用于保存服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；路由引擎，运行在服务调用方客户端中，用于从所述服务端获得所述服务实现关系表信息，以及服务流量分配策略信息，在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向该目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度。通过本申请实施例，能够更灵活的在多个不同的服务之间进行流量调度。

Description

流量调度方法、装置及系统

技术领域

本申请涉及流量调度处理技术领域，特别是涉及流量调度方法、装置及系统。

背景技术

在“新零售”等线上线下相结合的业务模式下，零售商可以通过线上的应用程序(App)提供商品对象的信息，用户可以通过线上的App进行浏览、购买等行为。同时，零售商还可以开设线下的实体店铺，用户也可以通过线下的实体店铺进行商品对象的购买。同时，线上的订单也可以由线下的实体店铺进行发货等一系列的处理，并最终配送到用户指定的收货地址。

在上述“新零售”的服务模式下，业务场景复杂，业务链路很长。例如，例如，对于商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点。通常，具体业务链路上各节点处的服务可以是由平台方来提供，但是，随着系统的发展，越来越多的外部商家需要与“新零售”平台进行合作。例如，某外部商家也能够提供“上架”服务，也希望加入到“新零售”系统中，这样，其他零售商也可以采购该外部商家提供的服务来解决某类问题，进而，使得这种外部商家也能够通过销售这种服务的方式，来作为另一种收入来源。

也就是说，同一个业务节点上可以由多个服务提供方来提供服务，服务调用方在具体进行业务处理的过程中，则可以自身的需求选择具体服务提供方所提供的服务。但是，在一些情况下，可能还需要针对各服务实际的运行情况等，进行流量调度，例如，在一些高并发访问等时期，将某节点上的流量分流到多个服务上，实现负载均衡，等等。但是，现有技术中，流量调度中间件都是基于机器维度的负载均衡和流量调度，例如，发现某台机器不可用，就记录下机器状态，后续的访问请求就不在访问这台机器。而负载均衡大多数也是常规的RR(Round-Robin)模式，来实现访问请求的均匀分布。但是，上述流量调度的方案都无法实现灵活的流量调度。

因此，针对同一个业务节点存在多个服务提供方所提供的服务的情况下，如何更灵活的在多个不同的服务之间进行流量调度，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了流量调度方法、装置及系统，能够更灵活的在多个不同的服务之间进行流量调度。

本申请提供了如下方案：

一种流量调度系统，包括：

服务端，包括文件子系统，用于保存服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

路由引擎，运行在服务调用方客户端中，用于从所述服务端获得所述服务实现关系表信息，以及服务流量分配策略信息，并保存在服务调用方客户端所在的终端设备本地，在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向该目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度。

一种流量调度方法，包括：

路由引擎通过服务端获得服务实现关系表信息，以及服务流量分配策略信息；所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；所述路由引擎运行在服务调用方客户端；

在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，获得多个服务实现的业务指标信息，并进行监控；

根据所监控到的业务指标信息以及所述服务流量分配策略信息，确定需要进行流量调度的目标服务实现，并在所述服务调用方客户端所在的终端设备本地，根据所述服务实现关系表，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。

一种流量调度方法，包括：

提供服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

根据路由引擎的拉取请求，将所述服务实现关系表信息，以及服务流量分配策略信息进行返回，以便所述路由引擎在根据服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度，所述路由引擎运行在服务调用方客户端。

一种流量调度装置，包括：

信息获得单元，用于通过服务端获得服务实现关系表信息，以及服务流量分配策略信息；所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；所述路由引擎运行在服务调用方客户端；

监控单元，用于在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，获得多个服务实现的业务指标信息，并进行监控；

流量调度单元，用于根据所监控到的业务指标信息以及所述服务流量分配策略信息，确定需要进行流量调度的目标服务实现，并在所述服务调用方客户端所在的终端设备本地，根据所述服务实现关系表，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。

一种流量调度装置，包括：

信息提供单元，用于提供服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

信息返回单元，用于根据路由引擎的拉取请求，将所述服务实现关系表信息，以及服务流量分配策略信息进行返回，以便所述路由引擎在根据服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度，所述路由引擎运行在服务调用方客户端。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

路由引擎通过服务端获得服务实现关系表信息，以及服务流量分配策略信息；所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，获得多个服务实现的业务指标信息，并进行监控；

根据所监控到的业务指标信息以及所述服务流量分配策略信息，确定需要进行流量调度的目标服务实现，并在所述服务调用方客户端所在的终端设备本地，根据所述服务实现关系表，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

根据路由引擎的拉取请求，将所述服务实现关系表信息，以及服务流量分配策略信息进行返回，以便所述路由引擎在根据服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度，所述路由引擎运行在服务调用方客户端。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，由于可以为服务调用方客户端提供路由引擎，在具体服务调用方进行服务接口调用的过程中，路由引擎可以确定出需要调用的服务实现，并将调用请求路由到该服务实现的服务地址，这样，可以使得具体的服务调用方可以在其本地发起对服务实现的调用，而服务提供方则可以在其内部的系统内提供对应的服务。在此基础上，还可以提供服务实现关系表信息，以及服务流量分配策略信息，路由引擎可以将其拉取到所在的业务系统本地，并且，路由引擎还可以在业务系统本地对多个服务实现的业务指标进行监控分析，如果发现某目标服务实现的业务指标存在异常，需要进行流量调度，则可以根据对应的服务流量调度策略信息，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。通过上述方式，由于具体的核心指标的监控操作是由路由引擎在业务系统本地完成，因此，一旦发现某目标服务实现的业务指标存在异常，则可以快速的进行调度，这样可以更高效地应对系统中的异常情况，最大限度的保障服务的可用性。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的系统架构的示意图；

图2-1至2-3是本申请实施例提供的系统示意图；

图3是本申请实施例提供的第一方法的流程图；

图4是本申请实施例提供的第二方法的流程图；

图5是本申请实施例提供的第一装置的示意图；

图6是本申请实施例提供的第二装置的示意图；

图7是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

首先需要说明的是，在“新零售”等线上与线下相结合的服务模式下，业务场景复杂，业务链路很长，在有的系统中，实现了一整套从供应链到用户端的中台系统。在此过程中，服务平台中的业务方经常需要处理多种标准作业流程。例如，对于面向消费者的业务方，可能会涉及到处理下单流程，发货流程等。而对于面向商家的业务方，则可能更需要处理上架流程，仓调货流程，仓补货流程，仓配送流程，修改商品价格流程等等。其中，每个流程中都可能包括多个业务逻辑节点，例如，对于商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点。

在传统的方式下，具体链路上各个节点上的服务，都是有平台来提供，但是，如背景技术部分所述，有些第三方的服务提供方其实也能够提供某些节点上的服务，例如，某服务提供方能够提供拣货服务，配送服务，等等。为了使得第三方的服务提供方能够通过上述服务平台为更多的服务调用方提供服务，相应的，也为了使得服务调用方能够获得更多服务提供方所提供的服务，可以将第三方的服务提供方所提供的服务也接入到系统中。

但是，能够提供上述业务链路上相关服务的服务提供方，其内部通常也会使用具体的ERP系统来实现各种信息、数据的管理。例如，商家A内部使用了一种ERP系统，其内部在具体实现商品上架处理时，采用的具体方式方法，与前述服务平台方默认的上架处理的方法可能是不同的。此时，外部商家接入平台时，可能会希望继续沿用自己内部惯用的处理方式，而不是统一使用平台方的方案，否则需要对服务提供方内部的软硬件系统进行改造升级，成本会比较高。

而现有技术中，平台方是使用了基于应用的开发模式，开发者按照应用维度进行代码开发，使得一个应用中通常包含了一个具体流程中的多个节点的实现。例如，对于前述例子中的商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点，在现有技术中，会将上述流程中各个节点上的实现代码组合在一起，绑定在同一个单元里，一起开发，一起部署，一起对外提供服务。此时，假设对于上述流程中的打包服务，除了平台方能够提供相应的实现之外，另外还有两个合作的商家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内部ERP系统中定义的具体拣货实现逻辑，提供关于该拣货服务的服务实现代码。另外，如果商家B也能够提供具体的拣货服务，则也可以根据该商家B内部ERP系统中定义的具体拣货实现逻辑，提供对应的拣货服务实现代码。通过这种方式，使得业务流程中的不同节点之间实现相互解耦，同一节点上的不同服务实现可以独立开发，独立部署，独立对外提供服务。并且，对于同一服务接口而言，可以由多个不同的服务提供方提供多种不同的服务实现代码，分别注册到流程引擎子系统中，使得同一个服务接口可以有“多态”实现。

也就是说，在本申请实施例中，可以由平台方抽象出具体的服务接口，然后由服务提供方提供具体的服务实现代码，每个服务提供方的服务实现代码都可以是按照服务提供方内部ERP(企业管理计划)系统中的服务实现逻辑来进行开发的。另外，具体的服务提供方所提供的服务实现代码，可以直接保存在服务提供方自己的服务器上，后续在被具体的服务调用方调用时，这种服务实现代码也可以在服务提供方自己的服务器上运行，按照服务提供方内部的实现逻辑来执行具体的操作，并将处理结果返回给服务调用方。

在通过上述方式进行了服务接口的抽象及定义，并为具体的服务接口提供了至少一个服务实现之后，还可以为服务调用方(例如，具体的业务方，等等，在本申请实施例中，可以称为第二系统)提供路由引擎(本申请实施例中可以成为BundleBroker)，这种路由引擎可以运行在具体的服务调用方客户端内，通过该路由引擎，可以通过具体的服务接口调用该服务接口下的其中一个具体的服务实现，以此获得相应的服务。服务调用方在具体进行服务调用时，可以指定所需调用的服务的id或者名称，还可以对具体所需服务实现的信息进行指定，再由具体的路由引擎将具体的调用请求路由到具体某个服务实现对应的服务地址。其中，具体在进行服务实现的指定时，可以在调用代码中设定具体的参数信息。为了便于服务调用方进行调用参数的设定，服务提供方在提供服务实现代码时，还可以设定具体的路由规则，并保存在服务中心。这样，具体的业务方客户端启动时，具体的路由引擎可以从服务中心拉取一份路由规则信息表，保存到业务方客户端本地。这样，可以在具体的业务方系统运行的过程中，通过路由信息表进行具体的路由，将服务调用方的调用请求路由到具体某个服务实现对应的地址，然后由该服务实现对应的服务提供方提供对应的服务。其中，路由规则的设定方式可以有多种，例如，可以一种形式下，可以直接指定具体的服务实现的id或者名称等标识信息，使得路由引擎能够直接通过服务实现的id或名称定位到具体所需调用的服务实现代码。或者，另一种实现形式下，还可以通过正则运算等方式来进行指定，此时，具体传入的参数可以是一些间接的信息，例如，可以是仓库类型，仓库Id等信息，然后通过正则运算的方式定位到具体的服务实现代码。

例如，在某“新零售”模式的服务系统中，为了能够在该系统的标准业务链路上，为系统的标准服务接入不同合作方的ERP系统，实现某一服务节点的多样化，本申请实施例针对具体业务链路上的每一种服务进行抽象，定义服务的标准接口，可以称之为SPI，例如，包括拣货服务接口，打包服务接口，上架服务接口，等等。将服务的具体实现，称之为Bundle，一个SPI可以有多个Bundle实现，做到服务实现的多态化。比如，在前述商品上架流程中，包括的拣货，打包，装箱，上架这四个节点，则在本申请实施例中，可以抽象为四个服务接口，分别为拣货服务接口，打包服务接口，装箱服务接口，上架服务接口。其中，拣货服务接口这个SPI，可以由服务提供方1提供服务实现；打包服务接口这个SPI，可以有服务提供方A提供的默认实现(Default Bundle)，也可以有服务提供方2提供的实现(例如，DaRunFaBundle)，等等。

在具体业务处理链路中的节点粒度上进行了服务接口的抽象，并在服务粒度上开发了服务实现后，可以注册到服务系统中，这样，具体的实体店铺中的服务调用方便可以通过对上述服务实现的调用，来获得某种具体的功能。例如，实体店铺A中的服务调用方可以对服务提供方1提供的打包服务的实现进行调用，实现打包功能，对服务提供方2的上架服务的实现进行调用，实现上架功能；实体店铺B中的服务调用方可以对服务提供方1提供的拣货服务的实现进行调用，实现拣货功能，对服务提供方2的上架服务的实现进行调用，实现上架功能，等等。也就是说，同一服务调用方客户端在实现标准作业流程的过程中，可以通过对多种不同服务对应的实现的编排，包括设定不同服务之间的调用关系等，使用多个不同的服务提供方提供的服务实现来共同解决实际业务场景中的具体问题。

以上所述对本申请实施例提供的基于服务粒度进行开发以及服务调用的方案进行了介绍，同时，服务的稳定性也是其中重要的一环。但是，随着业务的快速发展，一些平时正常运行的服务实现，可能由于突发的流量非常大，导致无法为更多的服务调用方提供服务，而同一服务接口下的其他服务实现则相对比较空闲，等等。在这种情况下，就需要进行流量调度，实现多个服务实现之间的负载均衡。

而现有技术中的负载均衡处理通常只能实现访问请求的均匀分布，但是，至少存在以下缺陷：首先，无法实现单次访问请求失败后，无缝路由其他可用服务实现或者降级服务实现；其次，无法实现灵活的流量调度策略，而在本申请实施例的场景中，对于同一服务接口上的多种不同服务实现而言，彼此之间的权重等可能并不是完全对等的，可能需要根据实际情况，进行更灵活的调整，而不是简单的进行均匀分配；再者，无法实现灵活的自动化运维，只有在机器服务不可用的情况下，才会终止对该机器的服务路由，而本申请实施例场景下，由于主要涉及到的都是与用户下单、配送等相关的业务链路，而对配送时效等方面通常具有严格的要求，例如，30分钟送达等等。因此，期望的是在某些业务指标超过阈值时，能够自动化实现流量调度，避免出现某些用户订单出现延误等情况。

可见，针对本申请实施例中所需的流量调度的需求，现有技术中的方案都无法很有效的进行解决。而在本申请实施例中，由于对每个业务节点进行了服务接口的抽象，并且还可以实现服务的多态化，另外还可以通过服务中心维护具体的服务实现路由表，其中可以保存同一服务接口对应的多个服务实现的地址信息以及路由条件信息。同时，可以为服务调用方客户端提供路由引擎，在具体服务调用方进行服务调用的过程中，路由引擎可以首先将路由表拉取到服务调用方本地，然后，根据具体调用请求中传入的参数，从路由表中匹配出所需调用的服务实现，然后，将具体的调用请求路由到具体服务实例的服务地址。这样，使得具体的服务调用方可以在其本地发起对服务实现的调用，而服务提供方也可以在其内部的系统内提供对应的服务。进而，本申请实施例还可以在该方案的基础上，提供相应的流量调度策略的实现。

具体的，在本申请实施例中，除了可以在服务中心保存上述服务实现路由表，还可以保存服务实现关系表信息(可以用于保存同一服务接口下多个服务实现之间的主备关系信息)，以及服务流量分配策略信息，业务方客户端中的路由引擎则可以从服务中心拉取到上述服务实现关系表以及流量分配策略信息。另外，各个具体服务实现所在系统还可以将具体的系统参数实时上报给服务中心，具体的路由引擎还可以将对各个服务实现的调用情况等也上报给服务中心，服务中心则日志子系统则可以采用日志的形式进行记录，同时，路由引擎也可以从中拉取具体的日志信息，并通过对日志进行分析，结合具体拉取到的服务流量分配策略信息，对同一服务接口的多个不同服务实现进行流量分配。其中，具体流量分配策略可以根据实际的需求进行配置，例如，日常服务实现50％，备用服务实现30％，降级服务实现20％，等等。另外，如果需要，还可以通过对服务中心的具体服务流量分配策略信息进行更新。这样，由于具体的核心指标监控是由具体的路由引擎来执行，并且流量分配策略信息也预先被拉取到服务调用方所在的业务系统本地，因此，在需要进行流量调整时，可以实现快速(通常可以实现毫秒级)的服务实现切换，另外，具体流量分配策略中的条件可以根据具体系统参数的阈值等进行设定，具体的分配比例也是可以调节的，因此，可以实现更灵活的流量分配。

下面对本申请实施例提供的具体技术方案进行详细介绍。

实施例一

首先，该实施例一提供了一种流量调度系统，参见图1，该系统具体可以包括：

服务端101，包括文件子系统1011，用于保存服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；具体实现时，如前文所述，服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的。也就是说，同一服务接口下可以包括多个服务实现，并彼此之间可以相互独立。

路由引擎102，运行在服务调用方客户端中，用于从所述服务端获得所述服务实现关系表信息，以及服务流量分配策略信息，并保存在服务调用方客户端所在的终端设备本地，在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向该目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度。

首先需要说明的是，在本申请实施例中，所述服务接口可以是按照商品对象相关的业务处理链路中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的。其中，所述商品对象服务业务链路中包括多个不同的节点，相应的，所述服务接口可以包括根据所述不同节点所需业务功能的不同进行定义的多个不同的服务接口。其中，同一个服务接口对应有多个不同的服务提供方提供的不同的服务实现，所述服务实现是根据对应的服务提供方内部的企业资源计划ERP系统中的处理逻辑提供的，以此实现服务的“多态化”实现。

其中，在具体实现时，所述商品对象相关的业务处理链路中的节点包括：需要由服务提供方的人力和/或机器人资源进行任务处理的作业节点。所述服务端还可以保存所述业务处理链路对应的流程信息，所述流程信息中包括多个节点信息，节点之间的流转关系信息，以及所述节点上配置的任务信息；所述流程信息用于被服务调用方所调用，以便根据上游节点上的任务完成情况以及所述流转关系进行流转，产生下游节点上需要处理的任务，并根据所述需要处理的任务生成所述服务接口调用请求。

例如，在一种具体的业务处理链路中，可以是根据交易订单将商品对象配送至指定收货地址的业务处理链路，此时，所述节点可以包括：拣货、打包、配送。具体的，参见图2，假设当前接收到了一个交易订单，则开始进入到流程中的第一个节点，也即拣货节点，此时，服务调用方客户端就可以产生对拣货服务接口进行调用的请求。相应的，该客户端中的路由引擎就可以根据具体调用请求中传入的参数等信息，确定出当前需要调用的目标服务实现，例如，确定出的是由拣货服务提供方B提供的拣货服务实现B，则可以根据路由表中记录的服务地址信息，将该调用请求路由到该拣货服务实现B的服务地址。拣货服务实现B在接收到具体的调用请求后，可以根据具体的交易订单中包括的商品对象信息，具体关联的作业场所(实体店铺等)中具体商品对象对应的货架区域等信息，生成具体的拣货任务，并发送到具体拣货员等用户关联的客户端中，由拣货员执行对应的拣货任务。其中，对于一个交易订单而言，由于其中可能会包括多个商品对象，这些商品对象对应的货品可能分布在不同的货架区域，因此，生成的拣货任务可能会有多个，分别分配给不同的拣货员执行拣货操作，等等。在拣货任务完成后，拣货服务实现B可以反馈给业务调用方客户端，然后，服务调用方客户端便可以根据具体流程中的流转信息，将具体的业务处理流程流转到下游的“打包”节点。相应的，业务系统中可以产生对打包接口的调用请求，路由引擎由可以对具体的打包服务实现进行确定，并进行路由，例如，选择的是打包服务实现B，则打包服务实现B可以将具体的打包任务分配给具体的打包员甲执行。类似的，服务调用方中还可以根据具体的节点流转关系调用配送服务接口，路由引擎由可以对具体的配送服务实现进行确定，并进行路由，例如，选择的是配送服务实现A，则配送服务实现A可以将具体的配送任务分配给具体的配送员甲执行，等等。

本申请实施例就可以是在上述系统架构的基础上，在同一服务接口的不同服务实现之间进行流量调度。其中，具体实现时，所述服务端的文件子系统中首先可以保存有服务实现路由表信息，所述服务实现路由表中保存有同一服务接口对应的多个服务实现的地址信息以及路由条件信息，这些具体的信息可以是由服务提供方进行配置的。具体实现时，所述路由引擎具体可以用于，在第一状态(也即，正常调用状态，未发生调用失败或者系统参数达到阈值等情况)下，根据所述服务调用方的业务系统中产生的调用请求中携带的参数信息，确定需调用的服务实现，并将所述调用请求路由到该服务实现对应的服务地址。也就是说，在本申请实施例中，具体的服务实现路由信息表可以由路由引擎从服务端拉取到具体的服务调用方的业务系统本地，在本地进行保存。这样，在对具体的服务实现进行调用的过程中，路由引擎可以直接根据本地保存的信息确定出所需调用的目标服务实现，然后再将具体的调用请求路由到该目标服务实现。

具体的服务实现路由表的具体形式可以有多种，例如，一种形式下可以如表1所示：

表1

通过这种服务实现路由信息表，路由引擎可以在业务系统本地实现对具体服务实现的路由。另外，在本申请实施例中，具体的文件子系统除了该服务实现路由信息表，还可以保存有服务实现关系表，以及流量分配策略信息。其中，具体的服务实现关系表，可以用于记录同一个服务接口下各个服务实现的主备关系信息，其中，这种主备关系具体可以包括主用与备用关系，或者还可以包一些降级关系，等等。并且，对于同一服务接口对应的各个服务实现而言，都可以分别具有各自对应的备用服务实现，降级服务实现，等等。其中，具体的主备关系信息可以是由服务提供方进行配置的，也就是说，某个服务提供方在针对某个服务接口提供了服务实现后，还可以通过服务端提供的配置界面等，对该服务实现与该服务接口下其他服务实现之间的主备关系进行配置。其中，关于与某服务实现具有备用关系的服务实现而言，具体可以是由同一个服务提供方提供的，例如，某服务提供方为了提高服务的可用性，可以在提供一个服务实现的同时，还提供一个备用的服务实现。也就是说，如果某服务实现B是服务实现A的备用实现，则这两个服务实现A、B通常可以是由同一个服务提供方进行提供，可以在同一个服务提供方的系统内运行。而关于与某服务实现具有降级关系的服务实现而言，则具体可以是由不同服务提供方提供的。也就是说，如果某某服务实现C是服务实现A的降级实现，则这两个服务实现A、C可能会由不同的服务提供方进行提供。此时，具体在为某个服务实现配置降级实现时，可以将同一服务接口下的各个服务实现进行展示，服务提供方可以从中选择其中一个作为其服务实现的降级实现，等等。另外，服务端还可以将平台自己提供的服务实现设定为默认的降级实现，也即，如果某个服务提供方没有为其服务实现配置降级实现，或者在降级实现也不可用的情况下，还可以将平台自己提供的服务实现作为降级实现，以提高服务的可用性，等等。

具体实现是，服务实现关系表的具体保存形式也可以有多种，例如，在其中一种形式下，可以如表2所示：

表2

需要说明的是，对于“备用服务实现”而言，通常可能不会直接被服务调用方进行调用，只有在实际被调用的服务实现不可用，或者存在其他异常时，才会考虑调用备用服务实现。

另外，除了前述服务实现路由表以及服务实现关系表，还可以在文件子系统中保存服务实现对应的服务流量分配策略信息，该分配策略信息具体还可以对应触发条件信息，以及对应的具体分配比例等信息。其中，触发条件通常可以与具体服务实现一侧系统的业务指标信息来进行确定。所述业务指标具体可以包括多种，在本申请实施例中，主要可以可以包括具体服务实现的服务参数，包括错误率，超时率，所述服务实现的平均响应时间信息，所述服务实现的调用成功率信息，和/或，同时调用同一服务实现的服务调用方数量信息，等等。对于该信息，由于具体对服务实现的路由都是通过路由引擎来完成的，因此，还可以由路由引擎将具体对服务实现的调用请求，是否成功，是否超时等信息，向日志子系统进行上报。这样，日志子系统就可以对各个服务实现对应的核心指标信息进行记录。当然，具体实现时，在进行流量调度时，除了可以参考前述业务指标，还可以结合服务实现系统的系统参数信息进行调度，例如，包括负载度，cpu占用，内存占用，线程数量等。为了能够获得这种系统参数信息，本申请实施例中还可以在服务端中配置日志子系统1012，这样，上述信息可以由具体运行所述服务实现的服务系统向服务端的日志子系统进行上报。

这里需要说明的是，在本申请实施例中，虽然由服务端的日志子系统对具体服务实现的业务指标信息进行记录，但是，具体的监控操作的实现则可以由具体的路由引擎来完成。也就是说，并不是直接由服务端对各个服务实现的业务指标进行监控，具体的流量分配策略的触发也不是由该服务端来完成，而是全部由路由引擎来完成，这样可以使得监控到业务指标满足具体流量分配策略对应的条件时，可以直接在业务方本地进行流量的分配，而不需要服务端获得监控结果后再进行一步一步的通知给路由引擎，因此，可以实现快速的流量分配策略执行。

其中，为了达到上述目的，可以由路由引擎从所述日志子系统实时拉取收集到的日志信息，然后，路由引擎可以在具体的业务系统本地对这种日志信息进行分析，如果某服务接口下的服务实现的业务指标符合某个具体流量分配策略的触发条件，则可以根据所述流量分配策略在该服务接口下的各个服务实现之间进行流量分配。例如，具体的触发条件可以设定为：如果某服务接口下的某个服务实现对应的超时率高于某阈值，则进行流量分配，分配比例为该服务实现占50％，该服务实现的备用服务实现30％，该服务实现的降级服务实现20％，等等。这样，在触发了一项流量分配策略后，路由引擎的工作状态将会进入到第二状态，此时，在具体服务调用方的业务系统发出该服务接口的新的调用请求时，如果根据服务实现路由表确定出所需的服务实现恰好是该需要进行流量调度的目标服务实现，则可以首先按照确定出的流量分配比例，重新在该服务接口下的各个可用服务实现中进行服务实现的选择，然后再将具体的调用请求路由到该新确定出的服务实现所在的服务地址。也即，如果是在第一状态下，在接收到一条关于该服务接口的调用请求时，将会根据服务实现路由表，确定出第一目标服务实现，然后将所述新的调用请求路由到所述第一目标服务实现对应的服务地址；但是，一旦该目标服务实现进入到第二状态，则针对同样对该服务接口的调用请求而言，可即使按照路由表是确定出需要路由到该第一目标服务实现，也需要首先根据该目标服务实现与所属接口下其他可用服务实现之间的流量比例信息，重新确定需调用的第二目标服务实现，并将所述新的调用请求路由到所述第二目标服务实现对应的服务地址，以此实现灵活的流量比例分配。

其中，具体在对业务指标进行监控时，对于需要由服务提供方配备的人力和/或机器人资源提供对应服务的情况下，还可以获得多个服务实现对应的服务提供方在所在节点上所配备的人力和/或机器人资源数量信息，此时，可以根据所述同一服务实现的服务调用方数量信息，以及该服务实现对应的所配备人力和/或机器人资源数量信息，确定是否达到该服务实现对应的服务提供方的服务上限，并进而确定是否需要对其进行流量调度。

另外，服务实现对应的业务指标存在异常的现象可能只是临时的，随着系统负荷的降低，或者，实际业务并发量的降低等，其业务指标可能又会逐渐恢复正常。因此，路由引擎还可以在所述获得的业务指标信息发生变化以至于不再满足服务流量分配策略信息的条件时，切换回所述第一状态，也即，重新按照服务实现路由表进行服务实现的路由。

具体实现时，所述路由引擎还可以用于，在将其中一调用请求路由到第一服务实现后，如果对所述第一服务实现调用失败，则可以直接根据所述服务实现关系表确定所述第一服务实现所在服务接口下其他可用的第二服务实现，并重新将所述调用请求路由到该第二服务实现。也就是说，可以实现单次访问请求失败后，无缝路由其他可用服务或者降级服务，并且，由于具体的切换操作以及对第二服务实现的确定等操作都是在业务系统本地即可完成，因此可以实现毫秒级的切换，效率高，避免对业务系统的实际业务处理流程造成影响或者延误。

总之，通过本申请实施例，由于可以为服务调用方客户端提供路由引擎，在具体服务调用方进行服务接口调用的过程中，路由引擎可以确定出需要调用的服务实现，并将调用请求路由到该服务实现的服务地址，这样，可以使得具体的服务调用方可以在其本地发起对服务实现的调用，而服务提供方则可以在其内部的系统内提供对应的服务。在此基础上，还可以提供服务实现关系表信息，以及服务流量分配策略信息，路由引擎可以将其拉取到所在的业务系统本地，并且，路由引擎还可以在业务系统本地对多个服务实现的核心指标进行监控分析，如果发现某目标服务实现的核心指标存在异常，需要进行流量调度，则可以根据对应的服务流量调度策略信息，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。通过上述方式，由于具体的核心指标的监控操作是由路由引擎在业务系统本地完成，因此，一旦发现某目标服务实现的核心指标存在异常，则可以快速的进行调度，这样可以更高效地应对系统中的异常情况，最大限度的保障服务的可用性。

实施例二

该实施例二是与实施例一相对应的，从路由引擎的角度，提供了一种流量调度方法，参见图3，该方法具体可以包括：

S301：路由引擎通过服务端获得服务实现关系表信息，以及服务流量分配策略信息；所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

S302：在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，获得多个服务实现的业务指标信息，并进行监控；

S303：根据所监控到的业务指标信息以及所述服务流量分配策略信息，确定需要进行流量调度的目标服务实现，并在所述服务调用方客户端所在的终端设备本地，根据所述服务实现关系表，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。

其中，所述服务接口是按照商品对象相关的业务处理链路中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的。

其中，所述商品对象服务业务链路中包括多个不同的节点，相应的，所述服务接口可以包括根据所述不同节点所需业务功能的不同进行定义的多个不同的服务接口。其中，同一个服务接口对应有多个不同的服务提供方提供的不同的服务实现，所述服务实现是根据对应的服务提供方内部的企业资源计划ERP系统中的处理逻辑提供的，以此实现服务的“多态化”实现。

其中，在具体实现时，所述商品对象相关的业务处理链路中的节点包括：需要由服务提供方的人力和/或机器人资源进行任务处理的作业节点。所述服务端还可以保存所述业务处理链路对应的流程信息，所述流程信息中包括多个节点信息，节点之间的流转关系信息，以及所述节点上配置的任务信息；所述流程信息用于被服务调用方所调用，以便根据上游节点上的任务完成情况以及所述流转关系进行流转，产生下游节点上需要处理的任务，并根据所述需要处理的任务生成所述服务接口调用请求。其中，所述业务处理链路包括：根据交易订单将商品对象配送至指定收货地址的业务处理链路，所述节点包括：拣货、打包、配送。

具体实现时，路由引擎还可以包括：通过所述服务端获得服务实现路由表信息，所述服务实现路由表中保存有同一服务接口对应的多个服务实现的地址信息以及路由条件信息；这样，在第一状态下，可以根据所述服务调用方的业务系统中产生的调用请求中携带的参数信息，确定需调用的服务实现，并将所述调用请求路由到该服务实现对应的服务地址。

另外，在确定出需要进行流量调度的目标服务实现的第二状态下，接收到新的调用请求时，如果根据所述调用请求中的参数信息以及所述服务实现路由表确定出需调用的是该目标服务实现，则可以根据所述流量比例信息，以及所述服务实现关系信息，重新确定所需调用的服务实现，并将所述新的调用请求路由到该信确定的服务实现对应的服务地址。

另外，在所述目标服务实现对应的核心指标信息发生变化以至于不再满足服务流量分配策略信息的条件时，切换回所述第一状态。

其中，为了实现对服务实现的业务指标的监控，路由引擎还可以从所述服务端的日志子系统获得记录有多个服务实现的业务指标的实时状态信息的日志信息；然后，根据所述日志信息对所述多个服务的业务指标进行分析，以便确定是否存在需要进行流量调度的目标服务实现。

其中，路由引擎可以将在根据所述服务接口调用请求向服务实现进行路由的过程中，对服务实现的被调用情况信息提交到所述服务端的日志子系统，以便所述日志子系统通过从多个调用引擎提交的信息进行汇总，将所获得的多个服务实现的实时服务参数信息确定为所述业务指标信息。

其中，所述实时服务参数信息包括：所述服务实现的平均响应时间信息，所述服务实现的调用成功率信息，和/或，同时调用同一服务实现的服务调用方数量信息。具体在对业务指标进行监控时，对于需要由服务提供方配备的人力和/或机器人资源提供对应服务的情况下，还可以获得多个服务实现对应的服务提供方在所在节点上所配备的人力和/或机器人资源数量信息，此时，可以根据所述同一服务实现的服务调用方数量信息，以及该服务实现对应的所配备人力和/或机器人资源数量信息，确定是否达到该服务实现对应的服务提供方的服务上限，并进而确定是否需要对其进行流量调度。

具体实现时，路由引擎还可以在将其中一调用请求路由到第一服务实现后，如果对所述第一服务实现调用失败，则根据所述服务实现关系表确定所述第一服务实现所在服务接口下其他可用的第二服务实现，并重新将所述调用请求路由到该第二服务实现。

实施例三

该实施例三是与实施例一相对应的，从服务端的角度，提供了一种流量调度方法，参见图4，该方法具体可以包括：

S401：提供服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

S402：根据路由引擎的拉取请求，将所述服务实现关系表信息，以及服务流量分配策略信息进行返回，以便所述路由引擎在根据服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度，所述路由引擎运行在服务调用方客户端。

其中，所述业务指标包括所述服务实例的服务参数信息；此时，还可以接收各服务调用方客户端内的路由引擎提交的对服务实现的调用情况信息，并进行日志记录及汇总，以便将记录的日志信息实时提供给各服务调用方客户端内的路由引擎，以便所述路由引擎根据所述日志信息获得所述核心指标信息。

另外，还可以提供用于对所述服务流量分配策略进行调整的操作选项；接收到更新后的服务流量分配策略信息后，推送到所述路由引擎，以便所述路由引擎对所在业务系统本地保存的服务流量分配策略进行更新。

关于前述实施例二以及实施例三中的未详述部分，可以参见前述实施例一中的记载，这里不再赘述。

与实施例二相对应，本申请实施例还提供了一种流量调度装置，参见图5，该装置具体可以包括：

信息获得单元501，用于通过服务端获得服务实现关系表信息，以及服务流量分配策略信息；所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

监控单元502，用于在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，获得多个服务实现的业务指标信息，并进行监控；

流量调度单元503，用于根据所监控到的业务指标信息以及所述服务流量分配策略信息，确定需要进行流量调度的目标服务实现，并在所述服务调用方客户端所在的终端设备本地，根据所述服务实现关系表，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。

其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的。

其中，所述商品对象服务业务链路中包括多个不同的节点，相应的，所述服务接口可以包括根据所述不同节点所需业务功能的不同进行定义的多个不同的服务接口。其中，同一个服务接口对应有多个不同的服务提供方提供的不同的服务实现，所述服务实现是根据对应的服务提供方内部的企业资源计划ERP系统中的处理逻辑提供的，以此实现服务的“多态化”实现。

其中，在具体实现时，所述商品对象相关的业务处理链路中的节点包括：需要由服务提供方的人力和/或机器人资源进行任务处理的作业节点。所述服务端还可以保存所述业务处理链路对应的流程信息，所述流程信息中包括多个节点信息，节点之间的流转关系信息，以及所述节点上配置的任务信息；所述流程信息用于被服务调用方所调用，以便根据上游节点上的任务完成情况以及所述流转关系进行流转，产生下游节点上需要处理的任务，并根据所述需要处理的任务生成所述服务接口调用请求。其中，所述业务处理链路包括：根据交易订单将商品对象配送至指定收货地址的业务处理链路，所述节点包括：拣货、打包、配送。

具体实现时，该装置还可以包括：

路由表获得单元，用于通过所述服务端获得服务实现路由表信息，所述服务实现路由表中保存有同一服务接口对应的多个服务实现的地址信息以及路由条件信息；

第一调用单元，用于在第一状态下，可以根据服务接口调用请求中携带的参数信息，确定需调用的服务实现，并将所述调用请求路由到该服务实现对应的服务地址。

另外，该装置还可以包括：

第二调用单元，用于在确定出需要进行流量调度的目标服务实现的第二状态下，接收到新的调用请求时，如果根据所述调用请求中的参数信息以及所述服务实现路由表确定出需调用的是该目标服务实现，则可以根据所述流量比例信息，以及所述服务实现关系信息，重新确定所需调用的服务实现，并将所述新的调用请求路由到该信确定的服务实现对应的服务地址。

另外，该装置还可以包括：

状态切换单元，用于在所述目标服务实现对应的核心指标信息发生变化以至于不再满足服务流量分配策略信息的条件时，切换回所述第一状态。

其中，监控单元具体可以包括：

日志信息获得子单元，用于从所述服务端的日志子系统获得记录有多个服务实现的业务指标的实时状态信息的日志信息；

分析子单元，用于根据所述所述日志信息对所述多个服务实现的业务指标进行分析，以便确定是否存在需要进行流量调度的目标服务实现。

另外，该装置还可以包括：

调用情况提交单元，用于将在根据所述服务接口调用请求向服务实例进行路由的过程中，对服务实例的被调用情况信息提交到所述服务端的日志子系统，以便所述日志子系统通过从多个调用引擎提交的信息进行汇总，将所获得的多个服务实现的实时服务参数信息确定为所述业务指标信息。

其中，所述实时服务参数信息包括：所述服务实现的平均响应时间信息，所述服务实现的调用成功率信息，和/或，同时调用同一服务实现的服务调用方数量信息。

具体实现时，该装置还可以包括：

数量信息获得单元，用于获得多个服务实现对应的服务提供方在所在节点上所配备的人力和/或机器人资源数量信息；

所述流量调度单元具体可以用于：

根据所述同一服务实现的服务调用方数量信息，以及该服务实现对应的所配备人力和/或机器人资源数量信息，确定是否达到该服务实现对应的服务提供方的服务上限，并进而确定是否需要对其进行流量调度。

具体实现时，该装置还可以包括：

重新路由单元，用于在将其中一调用请求路由到第一服务实现后，如果对所述第一服务实现调用失败，则根据所述服务实现关系表确定所述第一服务实现所在服务接口下其他可用的第二服务实现，并重新将所述调用请求路由到该第二服务实现。

与实施例三相对应，本申请实施例还提供了一种流量调度装置，参见图6，该装置具体可以包括：

信息提供单元601，用于提供服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

信息返回单元602，用于根据路由引擎的拉取请求，将所述服务实现关系表信息，以及服务流量分配策略信息进行返回，以便所述路由引擎在根据服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度，所述路由引擎运行在服务调用方客户端。

其中，所述业务指标包括所述服务实例的服务参数信息；此时，该装置还可以包括：

接收单元，用于接收各服务调用方业务系统内的路由引擎提交的对服务实现的调用情况信息，并进行日志记录及汇总，以便将记录的日志信息实时提供给各服务调用方业务系统内的路由引擎，以便所述路由引擎根据所述日志信息获得所述核心指标信息。

另外，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

路由引擎通过服务端获得服务实现关系表信息，以及服务流量分配策略信息；所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，获得多个服务实现的业务指标信息，并进行监控；

根据所监控到的业务指标信息以及所述服务流量分配策略信息，确定需要进行流量调度的目标服务实现，并在所述服务调用方客户端所在的终端设备本地，根据所述服务实现关系表，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。

另外还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

根据路由引擎的拉取请求，将所述服务实现关系表信息，以及服务流量分配策略信息进行返回，以便所述路由引擎在根据服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度，所述路由引擎运行在服务调用方客户端。

其中，图7示例性的展示出了计算机系统的架构，具体可以包括处理器710，视频显示适配器711，磁盘驱动器712，输入/输出接口713，网络接口714，以及存储器720。上述处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720之间可以通过通信总线730进行通信连接。

其中，处理器710可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器720可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器720可以存储用于控制计算机系统700运行的操作系统721，用于控制计算机系统700的低级别操作的基本输入输出系统(BIOS)。另外，还可以存储网页浏览器723，数据存储管理系统724，以及流量调度处理系统725等等。上述流量调度处理系统725就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器720中，并由处理器710来调用执行。

输入/输出接口713用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口714用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线730包括一通路，在设备的各个组件(例如处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720)之间传输信息。

另外，该计算机系统700还可以从虚拟资源对象领取条件信息数据库741中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，存储器720，总线730等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的流量调度方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (23)

1.一种流量调度系统，其特征在于，包括：

服务端，包括文件子系统，用于保存服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

路由引擎，运行在服务调用方客户端中，用于从所述服务端获得所述服务实现关系表信息，以及服务流量分配策略信息，并保存在服务调用方客户端所在的终端设备本地，在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向该目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度。

2.根据权利要求1所述的系统，其特征在于，

所述服务端还保存有服务实现路由表信息，所述服务实现路由表中保存有同一服务接口对应的多个服务实现的地址信息以及路由条件信息；

所述路由引擎具体用于，在第一状态下，根据所述服务调用方的业务系统中产生的调用请求中携带的参数信息，确定需调用的第一目标服务实现，并将所述调用请求路由到所述第一目标服务实现对应的服务地址。

3.一种流量调度方法，其特征在于，包括：

路由引擎通过服务端获得服务实现关系表信息，以及服务流量分配策略信息；所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；所述路由引擎运行在服务调用方客户端；

在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，获得多个服务实现的业务指标信息，并进行监控；

根据所监控到的业务指标信息以及所述服务流量分配策略信息，确定需要进行流量调度的目标服务实现，并在所述服务调用方客户端所在的终端设备本地，根据所述服务实现关系表，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。

4.根据权利要求3所述的方法，其特征在于，

所述服务接口是按照商品对象相关的业务处理链路中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的。

5.根据权利要求4所述的方法，其特征在于，

所述商品对象服务业务链路中包括多个不同的节点，所述服务接口包括根据所述不同节点所需业务功能的不同进行定义的多个不同的服务接口。

6.根据权利要求4所述的方法，其特征在于，

同一个服务接口对应有多个不同的服务提供方提供的不同的服务实现，所述服务实现是根据对应的服务提供方内部的企业资源计划ERP系统中的处理逻辑提供的。

7.根据权利要求4所述的方法，其特征在于，

所述商品对象相关的业务处理链路中的节点包括：需要由服务提供方的人力和/或机器人资源进行任务处理的作业节点。

8.根据权利要求7所述的方法，其特征在于，

所述服务端还用于保存所述业务处理链路对应的流程信息，所述流程信息中包括多个节点信息，节点之间的流转关系信息，以及所述节点上配置的任务信息；所述流程信息用于被服务调用方所调用，以便根据上游节点上的任务完成情况以及所述流转关系进行流转，产生下游节点上需要处理的任务，并根据所述需要处理的任务生成所述服务接口调用请求。

9.根据权利要求7或8所述的方法，其特征在于，

所述业务处理链路包括：根据交易订单将商品对象配送至指定收货地址的业务处理链路，所述节点包括：拣货、打包、配送。

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

通过所述服务端获得服务实现路由表信息，所述服务实现路由表中保存有同一服务接口对应的多个服务实现的地址信息以及路由条件信息；

在第一状态下，根据所述服务接口调用请求中携带的参数信息，确定需调用的目标服务实现，并将所述调用请求路由到该服务实现对应的服务地址。

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

在确定出需要进行流量调度的目标服务实现的第二状态下，接收到新的调用请求时，如果根据所述调用请求中的参数信息以及所述服务实现路由表确定出需调用的是该目标服务实现，则根据所述流量比例信息，以及所述服务实现关系信息，重新确定所需调用的服务实现，并将所述新的调用请求路由到该信确定的服务实现对应的服务地址。

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

在所述目标服务实现对应的业务指标信息发生变化以至于不再满足服务流量分配策略信息的条件时，切换回所述第一状态。

13.根据权利要求3所述的方法，其特征在于，

所述获得多个服务实现的业务指标信息，并进行监控，包括：

从所述服务端的日志子系统获得记录有多个服务实现的业务指标的实时状态信息的日志信息；

根据所述日志信息对所述多个服务实现的业务指标进行分析，以便确定是否存在需要进行流量调度的目标服务实现。

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

将在根据所述服务接口调用请求向目标服务实现进行路由的过程中，对服务实现的被调用情况信息提交到所述服务端的日志子系统，以便所述日志子系统通过从多个调用引擎提交的信息进行汇总，将所获得的多个服务实现的实时服务参数信息确定为所述业务指标信息。

15.根据权利要求14所述的方法，其特征在于，

所述实时服务参数信息包括：所述服务实现的平均响应时间信息，所述服务实现的调用成功率信息，和/或，同时调用同一服务实现的服务调用方数量信息。

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

获得多个服务实现对应的服务提供方在所在节点上所配备的人力和/或机器人资源数量信息；

所述根据所监控到的业务指标信息以及所述服务流量分配策略信息，确定需要进行流量调度的目标服务实现，包括：

根据所述同一服务实现的服务调用方数量信息，以及该服务实现对应的所配备人力和/或机器人资源数量信息，确定是否达到该服务实现对应的服务提供方的服务上限，并进而确定是否需要对其进行流量调度。

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

在将其中一调用请求路由到第一服务实现后，如果对所述第一服务实现调用失败，则根据所述服务实现关系表确定所述第一服务实现所在服务接口下其他可用的第二服务实现，并重新将所述调用请求路由到该第二服务实现。

18.一种流量调度方法，其特征在于，包括：

提供服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

根据路由引擎的拉取请求，将所述服务实现关系表信息，以及服务流量分配策略信息进行返回，以便所述路由引擎在根据服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度，所述路由引擎运行在服务调用方客户端。

19.根据权利要求18所述的方法，其特征在于，

所述业务指标包括所述服务实例的服务参数信息；

所述方法还包括：

接收各服务调用方客户端内的路由引擎提交的对服务实现的调用情况信息，并进行日志记录及汇总，以便将记录的日志信息实时提供给各服务调用方客户端内的路由引擎，以便所述路由引擎根据所述日志信息获得所述业务指标信息。

20.一种流量调度装置，其特征在于，包括：

信息获得单元，用于通过服务端获得服务实现关系表信息，以及服务流量分配策略信息；所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；所述路由引擎运行在服务调用方客户端；

监控单元，用于在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，获得多个服务实现的业务指标信息，并进行监控；

流量调度单元，用于根据所监控到的业务指标信息以及所述服务流量分配策略信息，确定需要进行流量调度的目标服务实现，并在所述服务调用方客户端所在的终端设备本地，根据所述服务实现关系表，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。

21.一种流量调度装置，其特征在于，包括：

信息提供单元，用于提供服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

信息返回单元，用于根据路由引擎的拉取请求，将所述服务实现关系表信息，以及服务流量分配策略信息进行返回，以便所述路由引擎在根据服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度，所述路由引擎运行在服务调用方客户端。

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

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

路由引擎通过服务端获得服务实现关系表信息，以及服务流量分配策略信息；所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

在根据所述服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，获得多个服务实现的业务指标信息，并进行监控；

根据所监控到的业务指标信息以及所述服务流量分配策略信息，确定需要进行流量调度的目标服务实现，并在所述服务调用方客户端所在的终端设备本地，根据所述服务实现关系表，在该目标服务实现与同一服务接口下其他可用服务实现之间进行流量调度。

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

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供服务实现关系表信息，以及服务流量分配策略信息，其中，所述服务实现关系表中保存有同一服务接口下多个可用服务实现之间的主备关系信息；

根据路由引擎的拉取请求，将所述服务实现关系表信息，以及服务流量分配策略信息进行返回，以便所述路由引擎在根据服务调用方所在的业务处理链路中产生的服务接口调用请求确定目标服务实现，并向所述目标服务实现进行路由的过程中，根据服务实现的业务指标信息以及所述服务流量分配策略信息，对所述服务实现进行流量调度，所述路由引擎运行在服务调用方客户端。

Images