本申请涉及服务降级处理技术领域，特别是涉及服务降级处理方法、装置及电子设备。
背景技术：
在“新零售”等线上线下相结合的业务模式下，零售商可以通过线上的应用程序(app)提供商品对象的信息，用户可以通过线上的app进行浏览、购买等行为。同时，零售商还可以开设线下的实体店铺，用户也可以通过线下的实体店铺进行商品对象的购买。同时，线上的订单也可以由线下的实体店铺进行发货等一系列的处理，并最终配送到用户指定的收货地址。但是，有些零售商可能受限于自身的资源或者能力，无法为用户提供完善的发货、配送等服务，甚至在具体进行商品的上架等处理时，也可能存在一些困难，导致效率低下，出错率高等情况。为了使得这种零售商也能够加入到“新零售”系统中，“新零售”平台方可以为零售商提供一些服务，例如，标准化的流程处理服务，零售商可以通过采购平台方的服务，来完善线上线下相结合的销售链路。例如，某零售商可以采购“上架”服务，此时，平台方可以为该零售商提供相对应的解决方案，等等。
通常，具体业务链路上的服务可以是由平台方来提供，但是，随着系统的发展，越来越多的外部商家需要与“新零售”平台进行合作。例如，某外部商家也能够提供“上架”服务，也希望加入到“新零售”系统中，使得其他零售商也可以采购该外部商家提供的服务来解决某类问题，进而，使得这种外部商家也能够通过销售这种服务的方式，来作为另一种收入来源。
但是，能够提供上述业务链路上相关服务的商家，其内部通常也会使用具体的erp系统来实现各种信息、数据的管理。例如，商家a内部使用了一种erp系统，其内部在具体实现商品上架处理时，采用的具体方式方法，与“新零售”系统平台方默认的上架处理的方法可能是不同的。此时，外部商家接入平台时，可能会希望继续沿用自己内部惯用的处理方式，而不是统一使用平台方的方案，后者需要对外部商家内部的软硬件系统进行改造升级，成本会比较高。
因此，如何灵活的支持业务场景，快速、低成本的进行新商家的接入，成为需要本领域技术人员解决的技术问题。
技术实现要素：
本申请提供了服务降级处理方法、装置及电子设备，能够在灵活的支持业务场景，快速、低成本的进行新商家的接入的同时，实现无侵入性的服务降级。
本申请提供了如下方案：
一种服务降级处理方法，包括：
第一服务器保存服务接口与服务实现之间的对应关系信息，以及服务实现对应的需监测的核心指标信息、异常规则信息、降级服务实现的信息；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
在所述服务实现被至少一个服务调用方客户端进行调用的过程中，对所述服务实现的运行情况进行监控；
如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，以便在服务调用方再次发起对所述服务实现的调用时，由流程引擎系统根据所述降级通知，返回所述降级服务实现的服务地址。
一种服务降级处理方法，包括：
第一客户端提供已定义的服务接口信息列表；所述服务接口是按照商品对象服务流程中的节点进行定义的；
在目标服务接口被选择后，接收为所述服务接口提供的服务实现信息，以及需监测的核心指标信息、异常规则信息、降级服务实现的信息；
将所述服务实现信息，将需监测的核心指标信息、异常规则信息、降级服务实现注册到第一服务器，以便在所述服务实现被至少一个服务调用方进行调用的过程中，对所述服务实现的运行情况进行监控，如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，利用对应的降级服务实现为服务调用方提供对应的服务。
一种服务降级处理方法，包括：
获得服务接口与服务实现之间的对应关系信息，其中，同一个服务接口对应多个服务实现，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
在服务调用方通过所述服务接口向服务实现发起调用请求时，根据所述调用请求中传入的信息，以及所述对应关系信息，定位目标服务接口下的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方向所述服务地址发起调用；
接收第一服务器推送的降级通知信息；
在服务调用方的调用请求再次被定位到所述目标服务实现时，根据所述降级通知，返回该目标服务实现对应的降级服务实现的服务地址。
一种服务降级处理装置，包括：
信息保存单元，用于保存服务接口与服务实现之间的对应关系信息，以及服务实现对应的需监测的核心指标信息、异常规则信息、降级服务实现的信息；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
监控单元，用于在所述服务实现被至少一个服务调用方客户端进行调用的过程中，对所述服务实现的运行情况进行监控；
降级通知单元，用于如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，以便在服务调用方再次发起对所述服务实现的调用时，由流程引擎系统根据所述降级通知，返回所述降级服务实现的服务地址。
一种服务降级处理装置，包括：
服务接口信息提供单元，用于提供已定义的服务接口信息列表；所述服务接口是按照商品对象服务流程中的节点进行定义的；
服务实现信息接收单元，用于在目标服务接口被选择后，接收为所述服务接口提供的服务实现信息，以及需监测的核心指标信息、异常规则信息、降级服务实现的信息；
注册单元，用于将所述服务实现信息，将需监测的核心指标信息、异常规则信息、降级服务实现注册到第一服务器，以便在所述服务实现被至少一个服务调用方进行调用的过程中，对所述服务实现的运行情况进行监控，如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，利用对应的降级服务实现为服务调用方提供对应的服务。
一种服务降级处理装置，包括：
信息获得单元，用于获得服务接口与服务实现之间的对应关系信息，其中，同一个服务接口对应多个服务实现，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
服务实现定位单元，用于在服务调用方通过所述服务接口向服务实现发起调用请求时，根据所述调用请求中传入的信息，以及所述对应关系信息，定位目标服务接口下的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方向所述服务地址发起调用；
降级通知接收单元，用于接收第一服务器推送的降级通知信息；
降级服务实现地址提供单元，用于在服务调用方的调用请求再次被定位到所述目标服务实现时，根据所述降级通知，返回该目标服务实现对应的降级服务实现的服务地址。
一种电子设备，包括：
一个或多个处理器；以及
与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
保存服务接口与服务实现之间的对应关系信息，以及服务实现对应的需监测的核心指标信息、异常规则信息、降级服务实现的信息；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
在所述服务实现被至少一个服务调用方客户端进行调用的过程中，对所述服务实现的运行情况进行监控；
如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，以便在服务调用方再次发起对所述服务实现的调用时，由流程引擎系统根据所述降级通知，返回所述降级服务实现的服务地址。
一种电子设备，包括：
一个或多个处理器；以及
与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
获得服务接口与服务实现之间的对应关系信息，其中，同一个服务接口对应多个服务实现，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
在服务调用方通过所述服务接口向服务实现发起调用请求时，根据所述调用请求中传入的信息，以及所述对应关系信息，定位目标服务接口下的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方向所述服务地址发起调用；
接收第一服务器推送的降级通知信息；
在服务调用方的调用请求再次被定位到所述目标服务实现时，根据所述降级通知，返回该目标服务实现对应的降级服务实现的服务地址。
根据本申请提供的具体实施例，本申请公开了以下技术效果：
通过本申请实施例，由于是通过将商品对象服务流程中的标准作业程序流程按照逻辑节点粒度进行拆分并抽象后进行定义的服务接口，然后针对该服务接口提供服务实现，使得流程中不同节点对应的服务实现之间实现相互独立，并提供了相应的流程引擎，可以路由到具体的服务实现层级，从而使得各个服务实现可以单独开发，单独部署，单独被调用。在上述实现架构的基础上，如果需要进行服务降级，则可以为具体的服务实现提供降级的服务实现，这种降级的服务实现作为具体服务接口下的一个具体服务实现，也是可以被单独调用的，因此，在发现某服务实现的核心指标发生异常时，便可以将具体的调用请求路由到该服务实现对应的降级服务实现，通过该降级服务实现为服务调用方提供服务。这样，无需侵入现有服务实现代码，或现有的降级服务实现，通过服务的多态能力，直接定义新的服务降级bundle，以便在服务监控到异常时，自动降级，保障服务的稳定性，可用性。另外，本申请实施例也无需在代码设计时就对所有的特性开关进行详尽梳理及设计，允许在服务运行过程中，随时修改降级bundle的逻辑，以应付越来越复杂的降级场景等，对研发人员能力有一定的包容性，对研发效率有极大的提高。
当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供系统的示意图；
图2是本申请实施例提供的时序示意图；
图3是本申请实施例提供的第一方法的流程图；
图4是本申请实施例提供的第二方法的流程图；
图5是本申请实施例提供的第三方法的流程图；
图6是本申请实施例提供的第一装置的示意图；
图7是本申请实施例提供的第二装置的示意图；
图8是本申请实施例提供的第三装置的示意图；
图9是本申请实施例提供的电子设备的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
首先需要说明的是，在“新零售”等线上与线下相结合的服务模式下，业务场景复杂，业务链路很长，实现了一整套从供应链到用户端的中台系统。在此过程中，服务平台中的业务方经常需要处理多种标准作业流程。例如，对于面向消费者的业务方，可能会涉及到处理下单流程，发货流程等。而对于面向商家的业务方，则可能更需要处理上架流程，仓调货流程，仓补货流程，仓配送流程，修改商品价格流程等等。其中，每个流程中都可能包括多个业务逻辑节点，例如，对于商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点。
现有技术中，平台方是使用了基于应用的开发模式，开发者按照应用维度进行代码开发，使得一个应用中通常包含了一个具体流程中的多个节点的实现。例如，对于前述例子中的商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点，在现有技术中，会将上述流程中各个节点上的实现代码组合在一起，绑定在同一个单元里，一起开发，一起部署，一起对外提供服务。此时，假设对于上述流程中的打包服务，除了平台方能够提供相应的实现之外，另外还有两个合作的商家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，一旦有新商家接入，都需要修改流程配置，无法保持一个相对稳态的流程。
而在本申请实施例中，为了能够更灵活地支持业务场景，快速、低成本的进行新商家的接入，如图1所示，首先可以将“新零售”等服务平台中的标准作业程序流程以节点为单位，抽象出标准服务接口(在本申请实施例中可以称为spi)，并提供第一系统101，可以用于对具体的服务接口进行定义，并进行注册；之后，可以将这种服务接口的定义信息提供给具体的服务提供方(例如，服务平台本身，或者其他的外部商家等，在本申请实施例中，称为第三系统103)，服务提供方则可以按照具体的服务对应的标准作业接口规范，提供具体的服务实现(在本申请实施例中可以称为bundle)。也就是说，在本申请实施例中，具体流程上的业务逻辑节点不再对应某一个固定的具体实现，而是以接口的形式存在，在定义服务接口时，只需要定义其入参、出参、功能等，而无需提供具体的实现代码。换言之，一个服务接口只需要定义出对应何种功能，需要哪些入参，哪些出参，而不需要提供具体的实现代码。具体的服务提供方则可以为具体的服务接口提供多种不同的服务实现，例如，对于“拣货”这种服务接口，在服务接口级别，无需确定具体如何实现拣货功能，但是，商家a能够提供具体的拣货服务，则可以为该服务接口提供具体的服务实现代码，也即，由商家a根据该商家a的具体拣货实现逻辑，提供关于该拣货服务的服务实现代码。另外，如果商家b也能够提供具体的拣货服务，则也可以根据该商家b内部的具体拣货实现逻辑，提供对应的拣货服务实现代码。通过这种方式，使得业务流程中的不同节点之间实现相互解耦，不同节点上的服务实现可以独立开发，独立部署，独立对外提供服务。并且，对于同一服务接口而言，可以由多个不同的服务提供方提供多种不同的服务实现代码，分别注册到流程引擎子系统中，使得同一个服务接口可以有“多态”实现。
也就是说，在本申请实施例中，可以由平台方抽象出具体的服务接口，然后由服务提供方提供具体的服务实现代码，每个服务提供方的服务实现代码都可以是按照服务提供方内部erp(企业管理计划)系统中的服务实现逻辑来进行开发的。另外，具体的服务提供方所提供的服务实现代码，可以直接保存在服务提供方自己的服务器上，后续在被具体的服务调用方调用时，这种服务实现代码也可以在服务提供方自己的服务器上运行，按照服务提供方内部的实现逻辑来执行具体的操作，并将处理结果返回给服务调用方。
在通过上述方式进行了服务接口的抽象及定义，并为具体的服务接口提供了至少一个服务实现之后，服务调用方(例如，具体的业务方，等等，在本申请实施例中，可以称为第二系统102)则可以通过具体的服务接口调用该服务接口下的其中一个具体的服务实现，以此获得相应的服务。服务调用方在具体进行服务调用时，可以指定所需调用的服务的id或者名称，还可以对具体所需服务实现的信息进行指定，再由具体的流程引擎系统将具体的调用请求路由到具体某个服务实现对应的服务地址。其中，具体在进行服务实现的指定时，可以在调用代码中设定具体的参数信息。为了便于服务调用方进行调用参数的设定，服务提供方在提供服务实现代码时，还可以设定具体的路由规则。例如，可以一种形式下，可以直接指定具体的服务实现的id或者名称等标识信息，使得流程引擎能够直接通过服务实现的id或名称定位到具体所需调用的服务实现代码。或者，另一种实现形式下，还可以通过正则运算等方式来进行指定，此时，具体传入的参数可以是一些间接的信息，例如，可以是仓库类型，仓库id等信息，然后通过正则运算的方式定位到具体的服务实现代码。
例如，在某“新零售”模式的服务系统中，为了能够在该系统的标准业务链路上，为系统的标准服务接入不同合作方的erp系统，实现某一服务节点的多样化，本申请实施例针对具体业务链路上的每一种服务进行抽象，定义服务的标准接口，可以称之为spi，例如，包括拣货服务接口，打包服务接口，上架服务接口，等等。将服务的具体实现，称之为bundle，一个spi可以有多个bundle实现，做到服务实现的多态化。比如，在前述商品上架流程中，包括的拣货，打包，装箱，上架这四个节点，则在本申请实施例中，可以抽象为四个服务接口，分别为拣货服务接口，打包服务接口，装箱服务接口，上架服务接口。其中，拣货服务接口这个spi，可以由服务提供方1提供服务实现；打包服务接口这个spi，可以有服务提供方a提供的默认实现(defaultbundle)，也可以有服务提供方2提供的实现(例如，darunfabundle)，等等。
在进行了服务接口的抽象，并在服务粒度上开发了服务实现后，可以注册到服务系统中，这样，具体的实体店铺中的服务调用方便可以通过对上述服务实现的调用，来获得某种具体的功能。例如，实体店铺a中的服务调用方可以对服务提供方1提供的打包服务的实现进行调用，实现打包功能，对服务提供方2的上架服务的实现进行调用，实现上架功能；实体店铺b中的服务调用方可以对服务提供方1提供的拣货服务的实现进行调用，实现拣货功能，对服务提供方2的上架服务的实现进行调用，实现上架功能，等等。也就是说，同一服务调用方客户端在实现标准作业流程的过程中，可以通过对多种不同服务对应的实现的编排，包括设定不同服务之间的调用关系等，使用多个不同的服务提供方提供的服务实现来共同解决实际业务场景中的具体问题。
以上所述对本申请实施例提供的基于服务粒度进行开发以及服务调用的方案进行了介绍，同时，服务的稳定性也是其中重要的一环。但是，随着业务的快速发展，一些平时正常运行的服务，可能会出现各种突发状况。尤其在分布式系统中，每个服务又存在很多不可控的因素，比如线程池处理缓慢，请求超时，资源不足，或者宕机，数据库故障，缓存故障，消息系统故障等等，都可能会引起服务不可用，此时就需要能够根据一些关键的数据进行自动服务降级，来保证业务的核心服务是可用的，即使是有损服务。又或者，在频繁的发布难免会出现发布出错，需要回滚，这段时间服务是不可用的，如何保证开发发布过程中的业务稳定性，也是服务降级需要做的事情。
在传统的降级实现方案中，一种比较常用的方案是服务熔断降级，也即，在某个异常条件被触发后，直接熔断整个服务，而不是一直等待服务超时，避免导致请求堆积，系统压力过大，造成服务崩溃等更严重的情况。服务熔断禁止服务消费方/客户端直接“裸调”服务器端，需包装一层熔断逻辑。这种方式，一方面对于客户端的要求较高，有一定的代码侵入性；另一方面，服务熔断期间，基本无法保证核心业务的正常运转。第三，若服务器端服务一直无法运转，客户端将一直无法得到正常服务。比如服务器端宕机等。
另一种常用的降级方案是限流降级，也即是当服务性能压力过大时为避免系统崩溃而采取的一种常见方式，当到达限流阀值，后续请求将被降级，可能是排队，或者直接报错引导。限流降级可能会导致部分请求一直无法正常消费。
再一种常用的降级方案是特性开关(featuretoggle)降级，线上运行服务存在问题时，可以通过配置中心推送特性开关，及时关闭非核心服务、当前不想暴露的服务，或访问降级服务，达到降级目的。但是此种方式需要代码设计时详细考虑每一特性的开关及代码设计，对研发人员的要求非常高，且代码侵入性强。
而在本申请实施例中，由于是在服务粒度上进行的代码开发，一个服务下可以存在多个服务实现，并且，还可以通过配置路由规则，使得流程引擎能够路由到具体的服务实现的层级，因此，为服务降级方案提供了全新的思路。具体的，在本申请实施例中，可以为具体的服务实现配置具体的“降级实现”。例如，某服务下包括a、b、c三种服务实现，其中，对于a这种服务实现，可以配置一种降级实现，例如，服务实现d；或者，服务实现a也可以将服务实现b或c作为自己的降级实现，等等。同时，还可以配置具体的核心指标以及降级规则，这样，在具体的服务调用与被调用的过程中，可以进行监控，一旦发现某服务实现在运行过程中，其某项核心指标发生异常，则可以向服务配置中心推送降级规则，服务配置中心则可以向所有调用该服务实现的客户端的流程引擎推送降级规则。具体的流程引擎接收到降级规则后，可以向调用方返回降级实现的服务地址，调用方则可以向该降低服务的服务地址发起调用，通过该降级实现获得对应的功能。
例如，假设服务b是在平台上定义的一种服务实现，并有正常的情况下访问的bundle，暂且称之为正常bundle，有服务降级情况下要提供服务bundle，暂且称之为降级bundle；本申请实施例方案中的服务路由采用的是基于服务多态化实现的路由方案。未定义降级规则前，服务a访问服务b。则具体的处理流程可以如图2所示：
1、服务a调用服务b，此时服务a的bundlebroker(流程引擎)根据patternfunction计算出要调用的服务b的具体实现，计算结果为服务b正常bundle；
2、服务a根据bundlebroker返回的服务地址发起一次调用，此时调用到服务b正常bundle；
当服务b在服务平台配置了降级bundle，配置了核心指标的异常规则后，可以包括以下步骤：
1、服务平台保存正常bundle与降级bundle之间的降级关系；
2、向监控中心推送核心指标的异常规则；
3、监控中心监控服务实现的运行情况，并发现异常；
4、监控中心向服务平台报告异常；
5、服务平台向服务配置中心推送降级规则；
6、服务配置中心向所有调用服务b的bundlebroker推送降级规则；服务a的bundlebroker收到降级规则；
7、服务a调用服务b，服务a的bundlebroker计算要调用的服务具体实现，为服务b:正常bundle；服务abundlebroker根据降级规则过滤，发现服务b降级，返回服务b：降级bundle的服务地址；服务a发起一次调用；此时调用到服务b降级bundle。
当然，在实际应用中，若服务之间的调用关系存储在服务平台或者监控平台，由服务平台或者监控平台直接对调用服务b的所有服务推送降级规则，略过服务配置中心，也属于本方案的一种实现方式。
通过上述方式，无需侵入现有服务实现代码，或现有的降级服务实现，通过服务的多态能力，直接定义新的服务降级bundle，以便在服务监控到异常时，自动降级，保障服务的稳定性，可用性。另外，本申请实施例也无需在代码设计时就对所有的特性开关进行详尽梳理及设计，允许在服务运行过程中，随时修改降级bundle的逻辑，以应付越来越复杂的降级场景等，对研发人员能力有一定的包容性，对研发效率有极大的提高。
下面通过具体的实施例对本申请所提供方案的具体实现进行详细介绍。
实施例一
该实施例一首先从服务配置中心服务器的角度，提供了一种服务降级处理方法，参见图3，该方法具体可以包括：
s301：第一服务器保存服务接口与服务实现之间的对应关系信息，以及服务实现对应的需监测的核心指标信息、异常规则信息、降级服务实现的信息；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
其中，第一服务器具体可以是服务配置中心的服务器，具体的服务接口，以及服务实现信息，都可以保存在该第一服务器中，因此，该第一服务器可以保存保存服务接口与服务实现之间的对应关系信息。另外，在本申请实施例中，在提供服务实现时，还可以为该服务实现配置需监测的核心指标信息、异常规则信息、降级服务实现，因此，第一服务器中也可以保存上述信息。
具体实现时，一个服务实现对应的降级服务实现，可以是同一个服务提供方提供的两个服务实现。或者，在另一种实现方式下，由于所述服务接口可以对应有多个服务实现，其中，所述多个服务实现中可以包括所述服务接口的默认服务实现，例如，服务平台自己提供的服务实现可以作为默认服务实现，等等，此时，非默认服务实现可以以所述默认服务实现为降级服务实现，等等。
具体实现时，第一服务器中保存的信息具体可以如表1所示：
表1
s302：在所述服务实现被至少一个服务调用方客户端进行调用的过程中，对所述服务实现的运行情况进行监控；
第一服务器还可以对服务实现的运行情况进行监控，具体可以对其核心指标等信息进行检查，判断其是否出现预先配置的异常规则，进而确定该服务实现是否发生异常。
s303：如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，以便在服务调用方再次发起对所述服务实现的调用时，由流程引擎系统根据所述降级通知，返回所述降级服务实现的服务地址。
在发现某个服务实现的核心指标符合所述异常规则时，则可以向调用该服务实现的服务调用方客户端内部署的流程引擎子系统客户端推送降级通知，这样，在服务调用方客户端再次发起对所述服务实现的调用时，流程引擎子系统客户端便可以根据所述降级通知，返回所述降级服务实现的服务地址。
也就是说，在本申请实施例中，服务器中还可以对每个服务实现分别对应的服务调用方信息进行记录，例如，具体的，服务器端保存的信息可以如表2所示：
表2
这样，在需要进行服务降级时，就可以向具体的服务调用方推送具体的降级通知。
总之，在本申请实施例中，由于是通过将商品对象服务流程按照逻辑节点粒度进行拆分并抽象后进行定义的服务接口，然后针对该服务接口提供服务实现，使得流程中不同节点对应的服务实现之间实现相互独立，并提供了相应的流程引擎子系统，可以路由到具体的服务实现层级，从而使得各个服务实现可以单独开发，单独部署，单独被调用。在上述实现架构的基础上，如果需要进行服务降级，则可以为具体的服务实现提供降级的服务实现，这种降级的服务实现作为具体服务接口下的一个具体服务实现，也是可以被单独调用的，因此，在发现某服务实现的核心指标发生异常时，便可以将具体的调用请求路由到该服务实现对应的降级服务实现，通过该降级服务实现为服务调用方提供服务。这样，无需侵入现有服务实现代码，或现有的降级服务实现，通过服务的多态能力，直接定义新的服务降级bundle，以便在服务监控到异常时，自动降级，保障服务的稳定性，可用性。另外，本申请实施例也无需在代码设计时就对所有的特性开关进行详尽梳理及设计，允许在服务运行过程中，随时修改降级bundle的逻辑，以应付越来越复杂的降级场景等，对研发人员能力有一定的包容性，对研发效率有极大的提高。
实施例二
该实施例二是与实施例一对应的，从第一客户端(具体可以是提供给服务提供方使用的客户端)的角度，提供了一种服务降级处理方法，参见图4，该方法具体可以包括：
s401：第一客户端提供已定义的服务接口信息列表；所述服务接口是按照商品对象服务流程中的节点进行定义的；
s402：在目标服务接口被选择后，确定为所述服务接口提供的服务实现信息，以及需监测的核心指标信息、异常规则信息、降级服务实现的信息；
s403：将所述服务实现信息，将需监测的核心指标信息、异常规则信息、降级服务实现注册到第一服务器，以便在所述服务实现被至少一个服务调用方进行调用的过程中，对所述服务实现的运行情况进行监控，如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，利用对应的降级服务实现为服务调用方提供对应的服务。
其中，所述服务实现信息包括服务实现对应的路由规则信息，以便所述服务调用方通过所述路由规则定位到所述服务实现，并向其发起调用。
具体的，所述路由规则信息可以包括输入参数信息，以及条件信息，以便在调用请求中的输入参数符合某路由规则中的条件信息，将所述调用请求定位到该路由规则对应的服务实现。
另外，所述服务实现信息还可以包括服务实现对应的服务地址信息，以便在定位到所述服务实现。
实施例三
该实施例三是从流程引擎系统的角度，提供了一种服务降级处理方法，参见图5，该方法具体可以包括：
s501：获得服务接口与服务实现之间的对应关系信息，其中，同一个服务接口对应多个服务实现，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
s502：在服务调用方通过所述服务接口向服务实现发起调用请求时，根据所述调用请求中传入的信息，以及所述对应关系信息，定位目标服务接口下的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方向所述服务地址发起调用；
s503：接收第一服务器推送的降级通知信息；
s504：在服务调用方的调用请求再次被定位到所述目标服务实现时，根据所述降级通知，返回该目标服务实现对应的降级服务实现的服务地址。
关于上述实施例一至实施例三中的未详述部分，可以参见前述实施例中的记载，这里不再赘述。
与前述实施例一相对应，本申请实施例还提供了一种服务降级处理装置，参见图6，该装置具体可以包括：
信息保存单元601，用于保存服务接口与服务实现之间的对应关系信息，以及服务实现对应的需监测的核心指标信息、异常规则信息、降级服务实现的信息；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
监控单元602，用于在所述服务实现被至少一个服务调用方客户端进行调用的过程中，对所述服务实现的运行情况进行监控；
降级通知单元603，用于如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，以便在服务调用方再次发起对所述服务实现的调用时，由流程引擎系统根据所述降级通知，返回所述降级服务实现的服务地址。
其中，所述服务接口对应有多个服务实现，所述多个服务实现中包括所述服务接口的默认服务实现；其中，非默认服务实现以所述默认服务实现为降级服务实现。
具体实现时，该装置还可以包括：
统计信息提供单元，用于向服务提供方的客户端提供关于所述服务实现的异常次数统计信息。
与前述实施例二相对应，本申请实施例还提供了一种服务降级处理装置，参见图7，该装置具体可以包括：
服务接口信息提供单元701，用于提供已定义的服务接口信息列表；所述服务接口是按照商品对象服务流程中的节点进行定义的；
服务实现信息接收单元702，用于在目标服务接口被选择后，接收为所述服务接口提供的服务实现信息，以及需监测的核心指标信息、异常规则信息、降级服务实现的信息；
注册单元703，用于将所述服务实现信息，将需监测的核心指标信息、异常规则信息、降级服务实现注册到第一服务器，以便在所述服务实现被至少一个服务调用方进行调用的过程中，对所述服务实现的运行情况进行监控，如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，利用对应的降级服务实现为服务调用方提供对应的服务。
其中，所述服务实现信息包括服务实现对应的路由规则信息，以便所述服务调用方通过所述路由规则定位到所述服务实现，并向其发起调用。
所述路由规则信息包括输入参数信息，以及条件信息，以便在调用请求中的输入参数符合某路由规则中的条件信息，将所述调用请求定位到该路由规则对应的服务实现。
其中，所述服务实现信息包括服务实现对应的服务地址信息，以便在定位到所述服务实现。
与前述实施例三相对应，本申请实施例还提供了一种服务降级处理装置，参见图8，该装置具体可以包括：
信息获得单元801，用于获得服务接口与服务实现之间的对应关系信息，其中，同一个服务接口对应多个服务实现，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
服务实现定位单元802，用于在服务调用方通过所述服务接口向服务实现发起调用请求时，根据所述调用请求中传入的信息，以及所述对应关系信息，定位目标服务接口下的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方向所述服务地址发起调用；
降级通知接收单元803，用于接收第一服务器推送的降级通知信息；
降级服务实现地址提供单元804，用于在服务调用方的调用请求再次被定位到所述目标服务实现时，根据所述降级通知，返回该目标服务实现对应的降级服务实现的服务地址。
另外，本申请实施例还提供了一种电子设备，包括：
一个或多个处理器；以及
与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
保存服务接口与服务实现之间的对应关系信息，以及服务实现对应的需监测的核心指标信息、异常规则信息、降级服务实现的信息；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
在所述服务实现被至少一个服务调用方客户端进行调用的过程中，对所述服务实现的运行情况进行监控；
如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，以便在服务调用方再次发起对所述服务实现的调用时，由流程引擎系统根据所述降级通知，返回所述降级服务实现的服务地址。
以及另一种电子设备，包括：
一个或多个处理器；以及
与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
获得服务接口与服务实现之间的对应关系信息，其中，同一个服务接口对应多个服务实现，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
在服务调用方通过所述服务接口向服务实现发起调用请求时，根据所述调用请求中传入的信息，以及所述对应关系信息，定位目标服务接口下的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方向所述服务地址发起调用；
接收第一服务器推送的降级通知信息；
在服务调用方的调用请求再次被定位到所述目标服务实现时，根据所述降级通知，返回该目标服务实现对应的降级服务实现的服务地址。
其中，图9示例性的展示出了计算机系统的架构，具体可以包括处理器910，视频显示适配器911，磁盘驱动器912，输入/输出接口913，网络接口914，以及存储器920。上述处理器910、视频显示适配器911、磁盘驱动器912、输入/输出接口913、网络接口914，与存储器920之间可以通过通信总线930进行通信连接。
其中，处理器910可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。
存储器920可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器920可以存储用于控制电子设备900运行的操作系统921，用于控制电子设备900的低级别操作的基本输入输出系统(bios)。另外，还可以存储网页浏览器923，数据存储管理系统924，以及服务降级处理系统925等等。上述服务降级处理系统925就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器920中，并由处理器910来调用执行。
输入/输出接口913用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
网络接口914用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。
总线930包括一通路，在设备的各个组件(例如处理器910、视频显示适配器911、磁盘驱动器912、输入/输出接口913、网络接口914，与存储器920)之间传输信息。
另外，该电子设备900还可以从虚拟资源对象领取条件信息数据库941中获得具体领取条件的信息，以用于进行条件判断，等等。
需要说明的是，尽管上述设备仅示出了处理器910、视频显示适配器911、磁盘驱动器912、输入/输出接口913、网络接口914，存储器920，总线930等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上对本申请所提供的服务降级处理方法、装置及电子设备，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。
1.一种服务降级处理方法，其特征在于，包括：
第一服务器保存服务接口与服务实现之间的对应关系信息，以及服务实现对应的需监测的核心指标信息、异常规则信息、降级服务实现的信息；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
在所述服务实现被至少一个服务调用方客户端进行调用的过程中，对所述服务实现的运行情况进行监控；
如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，以便在服务调用方再次发起对所述服务实现的调用时，由流程引擎系统根据所述降级通知，返回所述降级服务实现的服务地址。
2.根据权利要求1所述的方法，其特征在于，
所述服务接口对应有多个服务实现，所述多个服务实现中包括所述服务接口的默认服务实现；其中，非默认服务实现以所述默认服务实现为降级服务实现。
3.根据权利要求1所述的方法，其特征在于，还包括；
向服务提供方的客户端提供关于所述服务实现的异常次数统计信息。
4.一种服务降级处理方法，其特征在于，包括：
第一客户端提供已定义的服务接口信息列表；所述服务接口是按照商品对象服务流程中的节点进行定义的；
在目标服务接口被选择后，接收为所述服务接口提供的服务实现信息，以及需监测的核心指标信息、异常规则信息、降级服务实现的信息；
将所述服务实现信息，将需监测的核心指标信息、异常规则信息、降级服务实现注册到第一服务器，以便在所述服务实现被至少一个服务调用方进行调用的过程中，对所述服务实现的运行情况进行监控，如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，利用对应的降级服务实现为服务调用方提供对应的服务。
5.根据权利要求4所述的方法，其特征在于：
所述服务实现信息包括服务实现对应的路由规则信息，以便所述服务调用方通过所述路由规则定位到所述服务实现，并向其发起调用。
6.根据权利要求5所述的方法，其特征在于：
所述路由规则信息包括输入参数信息，以及条件信息，以便在调用请求中的输入参数符合某路由规则中的条件信息，将所述调用请求定位到该路由规则对应的服务实现。
7.根据权利要求4所述的方法，其特征在于：
所述服务实现信息包括服务实现对应的服务地址信息，以便在定位到所述服务实现。
8.一种服务降级处理方法，其特征在于，包括：
获得服务接口与服务实现之间的对应关系信息，其中，同一个服务接口对应多个服务实现，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
在服务调用方通过所述服务接口向服务实现发起调用请求时，根据所述调用请求中传入的信息，以及所述对应关系信息，定位目标服务接口下的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方向所述服务地址发起调用；
接收第一服务器推送的降级通知信息；
在服务调用方的调用请求再次被定位到所述目标服务实现时，根据所述降级通知，返回该目标服务实现对应的降级服务实现的服务地址。
9.一种服务降级处理装置，其特征在于，包括：
信息保存单元，用于保存服务接口与服务实现之间的对应关系信息，以及服务实现对应的需监测的核心指标信息、异常规则信息、降级服务实现的信息；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
监控单元，用于在所述服务实现被至少一个服务调用方客户端进行调用的过程中，对所述服务实现的运行情况进行监控；
降级通知单元，用于如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，以便在服务调用方再次发起对所述服务实现的调用时，由流程引擎系统根据所述降级通知，返回所述降级服务实现的服务地址。
10.一种服务降级处理装置，其特征在于，包括：
服务接口信息提供单元，用于提供已定义的服务接口信息列表；所述服务接口是按照商品对象服务流程中的节点进行定义的；
服务实现信息接收单元，用于在目标服务接口被选择后，接收为所述服务接口提供的服务实现信息，以及需监测的核心指标信息、异常规则信息、降级服务实现的信息；
注册单元，用于将所述服务实现信息，将需监测的核心指标信息、异常规则信息、降级服务实现注册到第一服务器，以便在所述服务实现被至少一个服务调用方进行调用的过程中，对所述服务实现的运行情况进行监控，如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，利用对应的降级服务实现为服务调用方提供对应的服务。
11.一种服务降级处理装置，其特征在于，包括：
信息获得单元，用于获得服务接口与服务实现之间的对应关系信息，其中，同一个服务接口对应多个服务实现，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
服务实现定位单元，用于在服务调用方通过所述服务接口向服务实现发起调用请求时，根据所述调用请求中传入的信息，以及所述对应关系信息，定位目标服务接口下的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方向所述服务地址发起调用；
降级通知接收单元，用于接收第一服务器推送的降级通知信息；
降级服务实现地址提供单元，用于在服务调用方的调用请求再次被定位到所述目标服务实现时，根据所述降级通知，返回该目标服务实现对应的降级服务实现的服务地址。
12.一种电子设备，其特征在于，包括：
一个或多个处理器；以及
与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
保存服务接口与服务实现之间的对应关系信息，以及服务实现对应的需监测的核心指标信息、异常规则信息、降级服务实现的信息；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
在所述服务实现被至少一个服务调用方客户端进行调用的过程中，对所述服务实现的运行情况进行监控；
如果所述服务实现的核心指标符合所述异常规则，则向所述服务调用方关联的流程引擎系统推送降级通知，以便在服务调用方再次发起对所述服务实现的调用时，由流程引擎系统根据所述降级通知，返回所述降级服务实现的服务地址。
13.一种电子设备，其特征在于，包括：
一个或多个处理器；以及
与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
获得服务接口与服务实现之间的对应关系信息，其中，同一个服务接口对应多个服务实现，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；
在服务调用方通过所述服务接口向服务实现发起调用请求时，根据所述调用请求中传入的信息，以及所述对应关系信息，定位目标服务接口下的目标服务实现，并返回该目标服务实现对应的服务地址，以便所述服务调用方向所述服务地址发起调用；
接收第一服务器推送的降级通知信息；
在服务调用方的调用请求再次被定位到所述目标服务实现时，根据所述降级通知，返回该目标服务实现对应的降级服务实现的服务地址。
技术总结