一种异常处理方法及其装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种异常处理方法及其装置。

背景技术

随着计算机的普及和互联网技术的迅猛发展，尤其是微服务架构的提出促使了系统架构从单一系统架构向分布式系统架构发展，而随着系统架构的快速迭代，服务之间的调用从系统内部服务调用转变到跨主机、跨应用集群等服务之间的调用，随之而来是的网络开销过大、服务不稳定等问题所造成的服务调用异常。

相关技术中，为了避免众多服务在被调用期间可能出现的异常，可定位到各个服务的代码段并在相应位置增加不同的异常处理代码，但是这样一来，当服务数量很大时定位到每个服务并在每个服务中添加异常处理代码，对于开发人员而言开发维护的代码数量是巨大的，对于人力成本的耗费是巨大的。

发明内容

本申请实施例提供一种异常处理方法、装置及电子装置，至少解决了以上提到的技术问题。

本申请实施例还提供一种异常处理方法，所述方法包括：从服务配置中心获取当前应用对应的异常配置信息，其中，所述当前应用包括在完成订单期间调用的至少一个服务，所述异常配置信息用于指示所述至少一个服务在完成所述订单期间出现异常时所设置的至少一个异常处理规则；利用所述异常配置信息配置所述当前应用；在所述订单出现异常时，调用所述至少一个异常处理规则，以对所述订单执行异常处理。

本申请实施例还提供一种异常处理方法，所述方法包括：接收至少一个节点发送的针对特定服务在调用从服务时的异常配置信息；响应于应用被启动，确定所述特定服务在所述应用中的特定异常配置信息；将所述特定异常配置信息发送到所述应用。

本申请实施例还提供一种异常处理方法，所述方法包括：根据从服务被调用后的返回信息确定所述从服务是否为异常处理；若为异常处理，从调用所述从服务的主服务对应的至少一个异常配置信息中确定与所述主服务匹配的异常配置信息。

本申请实施例还提供一种异常处理装置，所述装置包括：一个或多个处理器；存储器；以及一个或多个程序，其中所述一个或多个程序存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序包括用于执行以上方法的指令。

本申请实施例还提供一种存储一个或多个程序的计算机可读存储介质，所述一个或多个程序包括指令，所述指令当由计算设备执行时，使得所述计算设备执行以上方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

采用本申请，可利用服务配置中心直接对所属服务进行异常处理信息配置，缓解了技术人员对于代码维护的压力，并可向不同客户提供定制化异常处理服务。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是示出根据本申请的示例性实施例的分布式服务调用的场景示意图；

图2是示出根据本申请的示例性实施例的异常处理方法的流程图；

图3是示出根据本申请的示例性实施例的服务调用出现异常时的处理流程图；

图4是示出根据本申请的示例性实施例的异常处理的场景示意图；

图5是示出根据本申请的示例性实施例的异常处理的场景示意图；

图6是示出根据本申请的示例性实施例的设置服务的显示界面；

图7是示出根据本申请的示例性实施例的对服务设置异常配置信息的显示界面；

图8是示出根据本申请的示例性实施例的异常处理方法的流程图；

图9是示出根据本申请的示例性实施例的异常处理方法的流程图；

图10是示出根据本申请的示例性实施例的异常处理装置的框图；

图11是本申请实施例提供的计算机系统的架构的示意图；

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

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了缓解了技术人员对于代码维护的压力并可向不同客户提供定制化异常处理服务，根据本申请的示例性实施例的异常处理方法可利用服务配置中心直接对所属服务进行异常处理信息配置。

如图1所示，在实施中，客户端为了运行某一特定应用，例如，购物类应用，可需要多个服务相互调用。如图1所示，假设某一应用包括三个服务，服务A、服务B以及服务C，在执行该应用时，这三个服务之间的调用顺序是服务A调用服务B，服务B调用服务C。虽然附图中并未示出，但是在实际实施中，每个服务都可由一个服务集群提供。比如，以服务B为例，提供该服务B的设备可以是多个节点。

例如，假设用户在使用的应用是购物类应用时，用户在选购好商品后，生成订单、支付、仓内拣货、物流配送功能可以是该应用下的服务。对照于图1，生成订单服务相当于服务A，支付服务相当于服务B，仓内拣货服务相当于服务C，物流配送服务相当于服务D。

假定用户在购物类应用上购买了生鲜类商品，则用户在生成该订单后，发送“生成订单”消息，“支付”服务收到该消息后接收用户付款后将“支付成功”的消息发送到“仓内拣货”服务，“仓内拣货”服务在实现了仓库内取货后，将“取出商品”消息发送到“物流配送”服务，随后“物流配送”服务接收到消息后发送货物，并发送“商品已成功配送”消息。由此可见，购物类的应用需要相互调用不同的服务在实现该功能。

在此过程中，如图1所示，当客户端需要某一服务时，可向服务配置中心查询并定订阅服务，仍以服务B为例，服务A所在的节点可向服务配置中心获取服务信息列表，并利用负载均衡算法从这些服务节点中选择一个服务节点，随后，利用这个服务节点的地址信息向该服务节点发出请求并获取到该服务节点的处理结果。

服务配置中心是指可接收各个服务节点发送的服务注册信息，包括可执行所订阅的服务节点的地址信息列表、服务路由规则等信息，对这些信息统一管理并提供标准的接口。当各个服务需要获取配置信息时，可向服务配置中心中对应的接口直接拉取。此外，当服务配置中心中的各种参数有更新的时候，也可通知到各个服务，使得各个服务可实时拉取更新信息，使之动态更新。

如图1所示，当服务A调用服务B时，需要通过服务配置中心来调用所需要的服务节点。仍是以购物类应用为例，当支付类的服务通过向“仓内拣货”发送“支付成功”的消息来调用“仓内拣货”服务时，“支付”服务需要通过服务配置中心来确定“仓内拣货”服务的节点以及路由到该节点的路径。

在调用过程中，可能会存在服务异常，例如，可能会出现服务超时，也就是说，在预定时间(例如，1s)内没有接收到服务B的返回结果，此时，可利用运行根据本申请的示例性实施例的异常处理方法对此进行处理。

以下将结合图2对本申请的示例性实施例的异常处理方法进行详细描述。

图2是示出根据本申请的示例性实施例的异常处理方法的流程图。所述方法是从客户端的角度进行的描述。在实施中，用户可启动其客户端上的应用，例如，购物类应用，随着所述应用被启动，可执行以下步骤。

在步骤S210，从服务配置中心获取当前应用对应的异常配置信息，其中，所述当前应用包括在完成订单期间调用的至少一个服务，所述异常配置信息用于指示所述至少一个服务在完成所述订单期间出现异常时所设置的至少一个异常处理规则。

如上所述，当前应用是由多个服务构成的，为了便于描述，将调用服务的服务方(例如，特定服务)称为主服务，并将被调用服务的服务方称为从服务。例如，服务A调用服务B，则服务A为主服务，服务B为从服务。应注意，以上仅为了描述，不具有任何限制含义。

具体来说，用户为了各种需求可启动客户端中的应用。该应用为了满足用户的需求，在执行过程中需要多个服务相互调用实现，而为了实现服务之间的调用，则客户端需要先向服务配置中心查询并订阅服务，获取服务信息列表，这些服务信息是各个服务预先向服务配置中心提供的，包括且不限于服务所在节点的地址以及服务执行所需的配置信息。

因此，当需要针对服务设置异常配置信息时，可通过在服务配置中心中设置并存储针对各种服务的异常配置信息。具体来说，用户根据需要下单购买商品，当前应用在完成该订单时可能会面对各种异常情况。

基于此，当前应用可在服务配置中心中以应用为单位对该应用内的至少一个服务根据需求设置异常配置信息，其中，所述异常配置信息可被存储为对应服务的标识信息以及与该服务匹配的异常处理规则。这里提及的异常处理规则包括针对服务的预设的异常类型而设置的异常处理服务。

针对服务A的异常配置信息可包括用于识别出服务A的各种识别信息(例如，服务A的服务名称)以及与服务A对应的各种异常处理规则，由于服务A可调用不同的从服务，比如，服务B、服务C、服务D，因此，所述异常处理规则包括服务A调用的从服务的接口信息以及针对这个从服务的不同异常类型的异常处理服务。

以购物类应用为例，当服务A为生成订单服务时，服务A的异常配置信息可包括生成订单服务的标识信息以及与生成订单对应的各种异常处理规则，例如，与商品无法加入购物车对应的异常处理规则，又例如，当购买商品为预售商品时对应的异常处理规则，对应的从服务可以是以上提到的支付服务、仓内拣货服务以及物流配送服务。

在具体实施中，所述至少一个异常处理规则包括预设商户信息以及所述预设商户信息在面对异常时调用的异常处理服务。也就是说，不同的商户信息可对应于不同的异常处理服务。为了更好地描述，以下将结合图4和图5对这部分进行详细描述。

如图4所示，某购物类应用可具有网上店铺的同时还有多个线下实体店，例如：在全国不同的城市及同一城市不同的位置开设了多个线下实体中心，并且不同的实体中心入驻的商户也可能不同。

线下实体店及线上网店均可以通过该购物应用进行统一管理，但不同的商户在面对应用运行过程中的同一服务出现异常时，可以采用不同的处理方式，此外，同一异常也可能因为商户的不同而采用不同的处理方式。

为了便于描述，如图4所示，设定网上商城还具有三个线下实体店，三个线下实体店的商户入驻情况为：实体中心10入驻了商户1、商户2和商户3，实体中心20入驻了商户1、商户2、商户3以及实体中心30入驻了商户1、商户2、商户3和商户4。为了便于描述，相同商品的商户统一描述为同一商户，此外，为了便于理解，以下将商户1具体为生鲜商户，商户2具体为餐饮商户并且商户3为服装商户，而实体中心的位置分别为北京、上海和广州。

在实体中心位于北京的情况下，当配送服务异常时，可采用的方式如下表1所示：

表1

如表1所示，生鲜商户、餐饮商户以及服装商户均位于北京的实体中心，但是在“物流配送”服务均面临“缺货”的异常处理时，所采用的异常处理方式完全不同。生鲜商户由于生鲜产品的时效性比较强，因此采用“电话通知”的处理方式及时向用户告知生鲜产品已缺货。餐饮商户由于配送时间的限制(例如，一小时内必达)，在面对缺货时，选择极速退款，使得用户可尽快选择其他餐饮商户。服装商户由于时效性不强，面对缺货时，可通过短信通知用户即可。

在实体中心位于广州的情况下，当配送服务异常时，可采用如下表2所示：

表2

如表2所示，这些商户与表1中的商户的差别仅在于地域差别，但是在“物流配送”服务面临“缺货”的异常处理时，所采用的异常处理方式可能会不同。由于广州的温度较高，因此生鲜商户在面临缺货的异常处理时，采用“极速退款”的方式。餐饮商户在面临缺货的异常处理时，可采用与北京商户相同的异常处理方式，选择极速退款的处理方式，使得用户可尽快选择其他餐饮商户。服装商户也可采用与北京商户相同的异常处理方式，可通过短信通知用户即可。

在实体中心位于上海的情况下，当配送服务异常时，可采用如下表3所示：

表3

位于上海的实体中心由于位置处于郊区，过往经验是用户通常不接受直接退款，更愿意接受经济上的补偿或者有可替代方案，因此，生鲜商户在面对缺货的情况，选择向用户的账户发送延迟送货的优惠券，餐饮商户在面对缺货的情况，选择电话通知用户并在电话通知中向用户提供可替代餐饮，服装商户由于时限性要求不强，可短信通知用户。

由以上三个表可以看出，位于同一实体中心的不同商户会由于商品的特征信息不同面对同一异常类型时采用不同的异常处理方式，此外，即使是同一商户也会由于处于不同的实体中心(区域信息不同)而采用不同的异常处理方式。这些异常处理方式可由商户根据自身需求提供给服务配置中心。

此外，在实施中，还存在这样一种情况，商户销售商品的渠道不同而导致异常处理服务不同，也就是说，同一种商品在线上和线下面对异常情况的处理方式可能是不同，如下表4示出，在购买同一服装时由于购买途径不同，在面对缺货这一异常处理的类型时，可采用不同的处理方式。具体来说，当在网上商城购买服装，商品缺货时，则直接接入客服，由客服向客户解释原因以及提供备选方案。当在实体中心购买商品时面对缺货的异常处理的类型时，可直接通知库房的管理人员，库房的管理人员可申请向其他库房调用该商品。

表4

总而言之，为了能够针对同一应用中的执行主体不同，导致调用的服务面对异常处理是所调用的异常处理服务不同，则需要标准化对同一服务的异常配置并且可向各种商家展示该服务已有的异常配置。

此外，还可针对用户的会员等级不同，面对同样的异常处理类型，采用不同的异常处理方式，为了更清楚地描述，以下将参照表5举例说明。

表5

以购物类应用中的售后服务为例，在面对质量问题要求退货的异常处理类型，根据存储的与用户对应的用户信息确定异常处理的方式。如表5所示，可按照用户级别执行不同的异常处理方式，当用户级别为白金会员时，在面对质量问题要求退款时，可采用极速退款的方式，当用户为白银会员时，在面对质量问题要求退款时，可接入客服了解情况后由客户判断是否直接退款。当用户为普通会员时，可按照正常流程在收到退货商品后进行退款。

在步骤S220，利用所述异常处理信息配置所述当前应用。具体来说，所述应用在接收并加载这些异常配置信息后，可并根据这些异常配置信息中的标识信息确定所述应用中对应的服务，随后，利用该服务对应的异常处理信息对该服务进行配置。

在步骤S230，在所述订单出现异常时，调用所述至少一个异常处理规则，以对所述订单执行异常处理。

在实施中，当利用所述异常配置信息对主服务进行配置后，主服务可在调用从服务时对从服务进行监听，为了更好地描述该部分，以下将结合图3进行详细描述，图3示出了根据本申请的示例性实施例的服务调用出现异常时的处理流程图。

为了便于描述，以下将在服务A调用服务B的情况下进行描述，当服务A调用服务B时，服务A可全程监听服务B的处理是否为异常处理，例如，监听服务B的响应速度是否变慢，若确定服务B为异常处理，可根据服务A的异常处理规则确定该服务A出现的异常是否与异常处理规则中的异常类型匹配。若不匹配，示例性地，可触发异常报警操作，并将服务B的错误信息返回到服务A。

在确定在服务A出现的异常为异常处理规则中的指定异常时，可以根据与指定异常对应的异常处理方式来处理，例如，可调用服务C，服务C执行完成后，可以向调用服务A的服务返回相应的调用应答数据。

示例性地，当按照异常处理规则对异常执行处理仍然存在异常，则可如上所示可触发异常报警操作，并将调用服务的错误信息返回到服务A。

在本申请中，可参照图6和图7在服务配置中心上设置并展示对服务的配置界面。

图6示出根据本申请的示例性实施例的设置服务的显示界面；图7示出根据本申请的示例性实施例的对服务设置异常配置信息的显示界面。

为了使服务配置中心能够准确识别出需要异常配置处理的服务，可在如图4所示的界面上添加对所述服务的描述(标识信息)，包括该服务的服务名称、该服务调用的从服务的接口、服务版本信息以及服务分组。

随后，用户可在如图5所示的输入框中输入针对该服务设置的异常配置信息，包括针对该服务设置的异常类型以及针对各种异常类型的异常调用服务。

如图6所示，可在显示界面上输入所述服务的识别信息(例如，服务名称)，并选择所述服务的当前状态(是否运行)等信息后，可确定所述异常配置信息所针对的从服务，也就是被调用的服务，也可以是在附图中所指示的拦截服务。

此外，用户可以在指定异常对应的输入框中输入确定异常类型的数据，示例性的，可包括条件key、操作符及数值(如图6所示，显示界面中可以包括条件key的输入框，操作符的输入框及数值的输入框)，以完成针对被调用服务的指定异常所对应的异常配置信息。

更进一步地，用户可在该显示界面上按照如上方式输入对其它服务的异常配置信息。也就是说，不同用户均可利用该显示界面输入不同的异常配置信息，此处的用户包括线下商户以及线上商户，此外，此处的用户还可以是不同商品来源的用户，例如，可以是餐厅商户或者是生鲜商户。

在确定针对当前应用中各个服务的异常配置信息后，当前应用的终端设备可以将该异常配置信息发送至服务配置中心，服务配置中心接收到异常配置信息后，可以将该异常配置信息作为针对当前应用的配置信息存储起来。

在一种可能的实现方式中，用户还可以通过终端设备的查询界面，查询针对当前应用中的某一服务的异常处理规则的详细情况，或者可以修改、删除该异常处理规则，这样一来，由于针对当前应用的任一服务的异常处理规则均是可以通过终端设备进行配置和查看的，使得服务之间调用的异常处理可以定制化及可视化，便于用户进行相应的管理和维护。

此外，图5是示出了根据本申请的示例性实施例的异常处理的另一场景示意图。

如图5所示，在物流配送的应用场景下，“仓内拣货”服务可调用“拣货完成”服务，为了对“仓内拣货”服务进行异常监控，可通过不同的商户向服务配置中心提供关于“仓内拣货”服务的异常配置信息，如图所示，外卖商家、实体商店、餐饮商家以及线上商家可分别针对“仓内拣货”服务经由图6所示的界面输入不同的异常处理规则，并将这些异常处理规则作为与所述服务对应的异常配置信息存储在服务配置中心，如图6所示，所述异常处理规则包括针对外卖商家的异常处理规则、针对实体商店的异常处理规则、针对餐饮商家的异常处理规则以及针对线上商家的异常处理规则。

随后，在各个应用商家启动各自的客户端上的应用后，这些异常处理规则可被发送到不同的应用中并对该应用中的“仓内拣货”服务进行配置。

随后，在各个商家所在的客户端，“仓内拣货”服务可对“拣货完成”服务进行监听，并“拣货完成”服务可能出现三种情况：全拣、全部缺货出以及部分缺货出。当“仓内拣货”服务监测到“全部缺货出”时，确定“仓内拣货”服务出现异常。

此时，针对不同的商户可采用不同的异常配置规则。例如，针对外卖商家出现“全部缺货出”的情况，可调用极速退款、短信、电话、优惠券等服务并在特定情况下可调用“客服介入”服务。针对实体商店出现“全部缺货出”的情况，可调用“客户介入”服务。针对预售缺货出现“全部缺货出”的情况，可调用“客户介入”服务。针对餐饮商家出现“全部缺货出”的情况，可调用极速退款、短信、电话、优惠券等服务。

此外，所述方法还可应用在配送场景中，具体来说，商家根据用户订单对商品进行配送，并在商品配送完成时会向商家返回配送信息，包括配送成功、用户拒收以及超时配送。

商家可将用户拒收以及超时配送设置为异常，因此，“配送完成”服务在调用“履约完成”服务查看配送信息时，发现返回的结果指示为配送信息为用户拒收以及超时配送。此时，可按照商家预先设置的异常处理方式对其进行异常兜底处理，例如，针对用户拒收的异常订单，可向用户发放订单等金额的代金券并短信通知用户；针对超时配送的异常订单，可向用户发放礼品卡并短信通知用户。

以上已经从客户端的角度上对根据本申请的示例性实施例的异常处理方法进行了描述，以下将从服务配置中心以及服务节点的角度来描述根据本申请的示例性实施例的异常处理方法。

图8是示出根据本申请的示例性实施例的异常处理方法的流程图，其中，图8中示出的方法是由服务配置中心所执行的方法。

在步骤S810，接收至少一个节点发送的针对特定服务在调用从服务时的异常配置信息。

在本申请中，为了使不同节点上的用户(例如，技术人员)采用相同的格式对特定服务设置异常配置信息，服务配置中心可向这些节点发送用于设置异常配置信息的格式，因此，异常配置信息是针对所述至少一个节点标准化格式生成的信息，如上所述，所述异常配置信息可以是用户在所述至少一个节点的显示界面上输入的信息。

此外，所述至少一个节点包括线上店铺对应的节点以及线下店铺对应的节点。也就是说，任何可能会调用到所述特定服务的节点均可根据自身需求设置异常处理规则，此外，还可查看存储在服务配置中心上的与特定服务对应的异常配置信息。

在步骤S820，响应于应用被启动，确定所述特定服务在所述应用中的特定异常配置信息。服务配置中心管理的应用节点被启动后，所述服务配置中心可向所述节点发送配置信息，在本申请中，所述服务配置中心可确定与所述应用的各个服务对应的异常配置信息。

在步骤S830，将所述特定异常配置信息发送到所述应用。在本申请中，当该应用的异常配置信息发出更新时，所述服务配置中心可通过注册时的注册信息将配置信息已更新的信息广播到相应节点。

在实施中，面对同一异常处理类型的异常处理方式可根据用户设置进行更新，更新的方式可以是按时间更新，例如，每季度更新，还可以是按商品属性更新，例如，不同时令生鲜的异常处理方式不同，又或者按促销互动更新，例如，大促时的延迟送达加倍赔偿等。

当异常处理方式发生改变时，对应的异常处理信息也会随之改变，此时，与该异常处理信息对应的服务节点可向服务配置中心发送更新信息。服务配置中心可根据注册时的节点信息，通知到各个相关服务节点。图9是示出根据本申请的示例性实施例的异常处理方法的流程图。所述

在步骤S910，根据从服务被调用后的返回信息确定所述从服务是否为异常处理。

在步骤S920，若为异常处理，从调用所述从服务的主服务对应的至少一个异常配置信息中确定与所述主服务匹配的异常配置信息。可选地，所述至少一个异常配置信息包括所述从服务被不同接口调用时设置的异常配置信息。

综上可述，根据本申请的示例性实施例的异常处理方法可利用服务配置中心直接对所属服务进行异常处理信息配置，缓解了技术人员对于代码维护的压力，并可向不同客户提供定制化异常处理服务。更进一步地，针对某一特定服务，不同用户可根据需求设置不同的异常配置信息，使得所述服务可根据应用场景不同采用不同的异常处理方式，从而能够做到千人千面。更进一步地，所述方法可使异常配置信息标准化，从而方便不同的用户定制不同的异常配置规则。更进一步地，所述方法对于用户是无感知地，提高了用户体验。更进一步地，可通过可视化地用户界面对各个服务设置不同的异常配置信息，便于用户进行相应的管理和维护。更进一步地，所述方法可实现线上线下的联动，增强用户体验。

为了更清楚地明白本申请的示例性实施例的发明构思，以下将参照图10描述本申请的示例性实施例的异常处理装置的框图。本领域普通技术人员将理解：图10中的装置仅示出了与本示例性实施例相关的组件，所述装置中还包括除了图10中示出的组件之外的通用组件。

图10示出本申请的示例性实施例的异常处理装置的框图。所述异常处理装置是指可执行根据本申请的示例性实施例的异常处理方法的装置。参考图10，在硬件层面，该装置包括处理器、内部总线和计算机可读存储介质，其中，所述计算机可读存储介质包括易失性存储器和非易失性存储器。处理器从非易失性存储器中读取对应的计算机程序然后运行。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

具体来说，所述处理器执行以下操作：从服务配置中心获取当前应用对应的异常配置信息，其中，所述当前应用包括在完成订单期间调用的至少一个服务，所述异常配置信息用于指示所述至少一个服务在完成所述订单期间出现异常时所设置的至少一个异常处理规则；利用所述异常配置信息配置所述当前应用；在所述订单出现异常时，调用所述至少一个异常处理规则，以对所述订单执行异常处理。

可选地，所述至少一个异常处理规则包括商户信息以及所述商户信息在面对异常时调用的异常处理服务。

所述商户信息包括所述商户所在的区域信息、所述商户销售商品的渠道信息以及所述商户销售商品的特征信息。

所述处理器在实现步骤在所述订单出现异常时调用所述至少一个异常处理规则以对所述订单执行异常处理包括：从所述订单信息中获取当前商户信息；确定与所述当前商户信息对应的异常处理规则；调用所述异常处理规则中的异常处理服务对所述订单执行异常处理。

所述异常处理规则还被配置为与执行所述当前订单的用户信息相关。

所述处理器还可实现步骤：接收服务配置中心广播的针对所述当前应用的异常配置信息更新通知；响应于所述异常配置信息更新通知，从所述服务配置中心接收针对所述当前应用的至少一个更新异常配置信息。

所述处理器还可实现步骤从所述服务配置中心接收针对所述应用的至少一个更新异常配置信息后包括：确定所述至少一个异常处理信息对应的至少一个待更新服务；将所述至少一个待更新服务的异常配置信息更新为对应的更新异常配置信息。

根据本申请的示例性实施例，所述服务器还可执行以下步骤：接收至少一个节点发送的针对特定服务在调用从服务时的异常配置信息；响应于应用被启动，确定所述特定服务在所述应用中的特定异常配置信息；将所述特定异常配置信息发送到所述应用。

可选地，所述至少一个节点包括线上店铺对应的节点以及线下店铺对应的节点。

可选地，所述异常配置信息是针对所述至少一个节点标准化格式生成的信息。

可选地，所述异常配置信息是在所述至少一个节点的显示界面上获取的异常处理信息。

根据本申请的示例性实施例，所述服务器还可执行以下步骤：根据从服务被调用后的返回信息确定所述从服务是否为异常处理；若为异常处理，从调用所述从服务的主服务对应的至少一个异常配置信息中确定与所述主服务匹配的异常配置信息。

可选地，所述至少一个异常配置信息包括所述从服务被不同接口调用时设置的异常配置信息。

综上可述，根据本申请的示例性示例的异常处理装置可利用服务配置中心直接对所属服务进行异常处理信息配置，缓解了技术人员对于代码维护的压力，并可向不同客户提供定制化异常处理服务。更进一步地，针对某一特定服务，不同用户可根据需求设置不同的异常配置信息，使得所述服务可根据应用场景不同采用不同的异常处理方式，从而能够做到千人千面。更进一步地，所述方法可使异常配置信息标准化，从而方便不同的用户定制不同的异常配置规则。更进一步地，所述方法对于用户是无感知地，提高了用户体验。更进一步地，可通过可视化地用户界面对各个服务设置不同的异常配置信息，便于用户进行相应的管理和维护。更进一步地，所述方法可实现线上线下的联动，增强用户体验。

其中，图11示例性的展示出了计算机系统的架构，具体可以包括处理器1010，视频显示适配器1011，磁盘驱动器1012，输入/输出接口1013，网络接口1014，以及存储器1020。上述处理器1010、视频显示适配器1011、磁盘驱动器1012、输入/输出接口1013、网络接口1014，与存储器1020之间可以通过通信总线1030进行通信连接。

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

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

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

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

总线1030包括一通路，在设备的各个组件(例如处理器1010、视频显示适配器1011、磁盘驱动器1012、输入/输出接口1013、网络接口1014，与存储器1020)之间传输信息。

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

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

其中，图12示例性的展示出了电子设备的架构，例如，设备1100可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理，飞行器等。

参照图12，设备1100可以包括以下一个或多个组件：处理组件1102，存储器1104，电源组件1106，多媒体组件1108，音频组件1110，输入/输出(I/O)的接口1112，传感器组件1114，以及通信组件1116。

处理组件1102通常控制设备1100的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件1102可以包括一个或多个处理器1120来执行指令，以完成本公开技术方案提供的方法的全部或部分步骤。此外，处理组件1102可以包括一个或多个模块，便于处理组件1102和其他组件之间的交互。例如，处理部件1102可以包括多媒体模块，以方便多媒体组件1108和处理组件1102之间的交互。

存储器1104被配置为存储各种类型的数据以支持在设备1100的操作。这些数据的示例包括用于在设备1100上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器1104可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件1106为设备1100的各种组件提供电力。电源组件1106可以包括电源管理系统，一个或多个电源，及其他与为设备1100生成、管理和分配电力相关联的组件。

多媒体组件1108包括在设备1100和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件1108包括一个前置摄像头和/或后置摄像头。当设备1100处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件1110被配置为输出和/或输入音频信号。例如，音频组件1110包括一个麦克风(MIC)，当设备1100处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1104或经由通信组件1116发送。在一些实施例中，音频组件1110还包括一个扬声器，用于输出音频信号。

I/O接口1112为处理组件1102和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件1114包括一个或多个传感器，用于为设备1100提供各个方面的状态评估。例如，传感器组件1114可以检测到设备1100的打开/关闭状态，组件的相对定位，例如所述组件为设备1100的显示器和小键盘，传感器组件1114还可以检测设备1100或设备1100一个组件的位置改变，用户与设备1100接触的存在或不存在，设备1100方位或加速/减速和设备1100的温度变化。传感器组件1114可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件1114还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件1114还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件1116被配置为便于设备1100和其他设备之间有线或无线方式的通信。设备1100可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信部件1116经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信部件1116还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，设备1100可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1104，上述指令可由设备1100的处理器1120执行以完成本公开技术方案提供的方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

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

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

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