本申请涉及计算机
技术领域：
，尤其涉及一种服务远程调用的容灾方法及设备。
背景技术：
：服务远程调用由于涉及到网络传输和第三方服务，增加了服务调用的不确定性。当发生网络拥塞或者第三方服务不可用时，远程调用就会失败。为了解决远程调用失败的问题，现有技术中存在如下两种常用的容灾方法：(1)、客户端重试。在客户端重试的容灾方法中，客户端节点本地启动定时任务重试调用。在客户端重试的容灾方法中受本地内存空间限制，重试队列中任务数量有限；当同时有大量调用失败的情况时，本地重试队列将急剧扩张，对内存压力较大。因此，在客户端重试的容灾方法只适用于短时间、少量报错的情况，无法处理长时间大量报错出现的情况。(2)熔断降级。在熔断降级的容灾方法中，监控远程调用错误量，当错误量超过阈值时，请求被熔断一段时间；在熔断时间窗内，请求直接返回默认值，而不真正进行远程调用，但熔断降级的容灾方法不适用于对服务有强依赖的业务。因此，寻求一种适用于大量请求失败和服务长时间不可用时的容灾处理方法，成为本领域技术人员亟需解决的技术问题。技术实现要素：有鉴于现有技术的上述缺陷，本申请的一个目的是提供一种服务远程调用的容灾方法及设备，以解决现有技术中出现大量请求失败和服务长时间不可用时导致的问题，从而提高大量请求失败时的缓存请求并重试的能力。为实现上述目的，本申请提供了一种服务远程调用的容灾方法，其特征在于，所述方法包括：一种服务远程调用的容灾方法，其特征在于，所述方法包括：建立客户端与服务端之间的远程调用连接；向所述服务端发起调用请求；若调用失败，当检查到所述调用请求对应的消息中的当前重试次数小于预设的最大重试次数，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1；将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求。在本申请的较佳实施方式中，所述若调用失败，当检查到所述调用请求对应的消息中的当前重试次数小于预设的最大重试次数，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1，包括：若调用失败，则检查所述调用请求对应的消息中的当前重试次数和预设的最大重试次数，判断所述消息中的当前重试次数是否小于所述预设的最大重试次数；若是，则将所述调用请求封装成更新后的消息，并将所述当前重试次数加1再赋值给所述更新后的消息中的当前重试次数。在本申请的较佳实施方式中，所述将所述调用请求封装成更新后的消息，包括：将所述调用请求中的请求参数打包并封装成所述更新后的消息。在本申请的较佳实施方式中，所述将所述调用请求中的请求参数打包并封装成所述更新后的消息的同时，还包括：将所述调用请求对应的调用上下文状态数据封装成请求上下文对象；将所述调用请求对应的、用于接收调用返回值的回调对象和所述请求上下文对象均作为所述更新后的消息的参数。在本申请的较佳实施方式中，判断所述消息中的当前重试次数是否小于所述预设的最大重试次数之后，还包括：若否，则直接回调用于指示业务调用失败的第一响应信息并结束重试调用。在本申请的另一较佳实施方式中，所述方法还包括：若调用成功，则直接回调用于指示业务调用成功的第二响应信息并结束调用或重试调用。在本申请的较佳实施方式中，所述将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求，包括：将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至所述更新后的消息的缓存时间达到预设的消息超时时间时，将所述调用请求转发至交换机，以使所述交换机将所述更新后的消息转发至请求队列；消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求。在本申请的较佳实施方式中，所述消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求，包括：对所述请求队列中的所述更新后的消息进行解析，得到所述更新后的消息中的接口名、方法名及请求参数；基于所述更新后的消息中的接口名、方法名及请求参数，向所述服务端发起所述重试调用请求。在本申请的较佳实施方式中，所述向所述服务端发起重试调用请求，包括：确定重试间隔时间，按照所述重试间隔时间向所述服务端发起重试调用请求，其中，所述重试间隔时间为用户预置的间隔时间，或由所述用户预置的初始重试间隔时间采用指数退避算法确定直至达到预置的最大重试间隔时间。本申请还提供了一种服务远程调用的容灾设备，其特征在于，所述设备包括：连接建立装置，用于建立客户端与服务端之间的远程调用连接；发起调用装置，用于向所述服务端发起调用请求；请求封装装置，用于若调用失败，当检查到所述调用请求对应的消息中的当前重试次数小于预设的最大重试次数，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1；重试缓存装置，用于将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求。在本申请的较佳实施方式中，所述请求封装装置用于：若调用失败，则检查所述调用请求对应的消息中的当前重试次数和预设的最大重试次数，判断所述消息中的当前重试次数是否小于所述预设的最大重试次数；若是，则将所述调用请求封装成更新后的消息，并将所述当前重试次数加1再赋值给所述更新后的消息中的当前重试次数。在本申请的较佳实施方式中，所述请求封装装置用于：将所述调用请求中的请求参数打包并封装成所述更新后的消息。在本申请的较佳实施方式中，所述请求封装装置还用于：将所述调用请求对应的调用上下文状态数据封装成请求上下文对象；将所述调用请求对应的、用于接收调用返回值的回调对象和所述请求上下文对象均作为所述更新后的消息的参数。在本申请的较佳实施方式中，所述重试缓存装置用于：将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至所述更新后的消息的缓存时间达到预设的消息超时时间时，将所述调用请求转发至交换机，以使所述交换机将所述更新后的消息转发至请求队列；消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求。在本申请的较佳实施方式中，所述重试缓存装置用于：确定重试间隔时间，按照所述重试间隔时间向所述服务端发起重试调用请求，其中，所述重试间隔时间为用户预置的间隔时间，或由所述用户预置的初始重试间隔时间采用指数退避算法确定直至达到预置的最大重试间隔时间。与现有技术相比，本申请提供的一种服务远程调用的容灾方法及设备具有以下技术效果：本申请通过首先建立客户端与服务端之间的远程调用连接，当需要向服务端发起远程调用时，向所述服务端发起调用请求；若调用失败，当检查到所述调用请求对应的消息中的当前重试次数小于预设的最大重试次数，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1；将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求，实现了对调用失败对应的调用请求的缓存，不仅提高了同时出现大量请求失败时的调用请求的缓存，提高了对调用请求进行重试的能力。以下将结合附图对本申请的构思、具体结构及产生的技术效果作进一步说明，以充分地了解本申请的目的、特征和效果。附图说明图1是本申请一个方面提供的一种服务远程调用的容灾方法的流程示意图；图2是本申请一个方面提供的一种服务远程调用的容灾方法的实际应用场景中的较佳实施例的流程示意图。图3是本申请一个方面提供的一种服务远程调用的容灾方法中的微服务通信框架容灾调用模块结构图；图4是本申请一个方面提供的一种服务远程调用的容灾方法中的调用请求对应的消息或更新后的消息的包体及其包体中包含的参数意图；图5是本申请一个方面提供的一种服务远程调用的容灾方法的实际应用场景示意图；图6是本申请一个方面提供的一种服务远程调用的容灾设备的结构示意图。具体实施方式以下参考说明书附图介绍本申请的多个优选实施例，使其技术内容更加清楚和便于理解。本申请可以通过许多不同形式的实施例来得以体现，本申请的保护范围并非仅限于文中提到的实施例。在附图中，结构相同的部件以相同数字标号表示，各处结构或功能相似的组件以相似数字标号表示。附图所示的每一组件的尺寸和厚度是任意示出的，本申请并没有限定每个组件的尺寸和厚度。为了使图示更清晰，附图中有些地方适当夸大了部件的厚度。如图1所示，本申请一个方面的一种实施例提供了一种服务远程调用的容灾方法的流程示意图，应用于服务远程调用过程中的客户端集群中的任一客户端节点对应的客户端。该方法包括步骤s11、步骤s12、步骤s13、步骤s14及步骤s15，其中，具体包括如下步骤：步骤s11，建立客户端与服务端之间的远程调用连接。在所述步骤s11中，在客户端与服务端之间进行远程调用之前，需要在客户端与服务端之间建立起用于远程调用的连接，如图2中的虚线的下半部分所示，为本领域传统的微服务通信框架远程调用结构图。在建立客户端与服务端之间的远程调用连接过程中，首先，服务端集群中的服务端节点启动时，将该服务端节点自身的ip地址、端口号等服务元信息注册到注册中心；接着，客户端集群中的客户端节点在进行服务远程调用时，通过所述注册中心查询远程调用的服务端节点对应的ip地址及端口号等服务原信息，并通过ip地址与该服务端节点建立用于服务远程调用的连接，实现通过注册中心来建立客户端节点与服务端节点之间的远程调用连接。在完成客户端节点与服务端节点之间的远程调用连接后，客户端节点可以向服务端节点发起远程调用，以便所述服务端节点在接收到调用请求后，执行相应的业务方法来处理调用请求，执行完成后再将执行结果返回至客户端节点，以完成服务远程调用。当客户端集群中的客户端需要向服务端发起远程调用时，步骤s12，向所述服务端发起调用请求。若调用失败，执行步骤s13和步骤s14，若调用成功，则执行步骤s15。其中，所述步骤s13，当检查到所述调用请求对应的消息中的当前重试次数retrycount小于预设的最大重试次数totalcount，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1，即retrycount 1，以实现在调用失败时，对调用请求打包成消息，并对更新后的消息中的当前重试次数进行累计加1。所述步骤s14，将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求。若调用成功，所述步骤s15，直接回调用于指示业务调用成功的第二响应信息并结束调用或重试调用。例如，在所述步骤s15中，当所述调用请求是第一次调用时，若调用成功，所述步骤s15直接回调用于指示业务调用成功的第二响应信息并结束调用；当所述调用请求并非第一次调用，即属于重试的调用请求，若调用成功，所述步骤s15直接回调用于指示业务调用成功的第二响应信息并结束重试调用，以实现对远程调用成功时的回调响应。通过上述步骤s11至步骤s15，通过外部的请求延迟队列实现了对调用失败时的调用请求的缓存，不仅提高了同时出现大量请求失败时的调用请求的缓存，提高了对调用请求进行重试的能力；还实现了在调用成功时，回调用于指示业务调用成功的第二响应信息并结束调用或重试调用，进而实现对远程调用成功时的回调响应。接着本申请的上述实施例，在所述步骤s12向所述服务端发起调用请求后，若调用成功，则直接回调observer.onsuccess()，用于通知业务调用成功，并结束调用流程或重试调用流程；若调用失败，则所述步骤s13当检查到所述调用请求对应的消息中的当前重试次数retrycount小于预设的最大重试次数totalcount，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1，具体包括：若调用失败，则检查所述调用请求对应的消息中的当前重试次数和预设的最大重试次数，判断所述消息中的当前重试次数是否小于所述预设的最大重试次数；若是，则将所述调用请求封装成更新后的消息，并将所述当前重试次数加1再赋值给所述更新后的消息中的当前重试次数。例如，当调用失败时，所述步骤s13检查所述调用请求对应的消息中的当前重试次数retrycount和预设的最大重试次数totalcount的值(当调用请求为第一次调用时，当前重试次数retrycount为0)，以便根据所述调用请求对应的消息中的当前重试次数retrycount和预设的最大重试次数totalcount的值来确定是否需要重试调用。判断所述消息中的当前重试次数retrycount是否小于所述预设的最大重试次数totalcount，若是，则表示所述调用请求对应的消息已重试调用的次数小于预设的最大重试次数，还可以继续进行重试调用，则将所述调用请求封装成更新后的消息，并在每次发送该更新后的消息之前，将所述当前重试次数加1，再赋值给所述更新后的消息中的当前重试次数retrycount，即retrycount＝retrycount 1，以实现当调用失败且调用请求对应的消息中的当前重试次数小于所述预设的最大重试次数时，对调用请求进行封装处理并将处理后得到的更新后的消息放入请求延迟队列进行缓存，从而实现对调用失败的请求的缓存，以便后续进行调用的重试。接着本申请的上述实施例，所述步骤s13中的所述判断所述消息中的当前重试次数是否小于所述预设的最大重试次数之后，还包括：若否，则直接回调用于指示业务调用失败的第一响应信息并结束重试调用。例如，在步骤s13中判断所述调用请求对应的消息中的当前重试次数retrycount是否小于所述预设的最大重试次数totalcount，若否，表示所述调用请求对应的消息已重试调用的次数大于等于预设的最大重试次数，则不再重试调用请求，直接回调observer.onerror()，通知业务调用失败，并结束重试调用流程，以实现对超过预设的最大重试次数的调用请求的结束处理，以节省出更多的调用内存资源来满足别的调用请求。接着本申请的上述实施例，所述步骤s13中的将所述调用请求封装成更新后的消息，具体包括：将所述调用请求中的请求参数打包并封装成所述更新后的消息。例如，当调用失败时，所述步骤s13检查到的所述调用请求对应的消息中的当前重试次数retrycount小于所述预设的最大重试次数totalcount时，表示所述调用请求对应的消息已重试调用的次数小于预设的最大重试次数，还可以继续进行重试调用，则将所述调用请求中的请求参数进行打包并封装成更新后的消息，所述更新后的消息包括包头和包体，如图3和图4所示，图3中示出调用请求对应的消息或更新后的消息的包头及包头中包含的参数，图4中示出调用请求对应的消息或更新后的消息的包体及其包体中包含的参数，图3和图4中的各个参数的简要说明如表1所示。表1消息中的各个参数字段的说明表字段说明retrycount当前重试次数totalcount最大重试次数retrypolicy重试策略expiration消息超时时间interface接口名method方法名context请求上下文requestjson请求参数observer业务注册的回调对象接着本申请的上述实施例，所述客户端集群的任意客户端节点都可以消费请求队列中的调用请求，所以发起重试调用请求的客户端节点可能和第一发起调用请求的客户端节点不同，则为了便于在重试调用完成后把调用成功与否的结果通知到业务，并完成后续的业务流程，本申请实施例中的所述步骤s13中的所述将所述调用请求中的请求参数打包并封装成所述更新后的消息的同时，还包括：将所述调用请求对应的调用上下文状态数据封装成请求上下文对象；将所述调用请求对应的、用于接收调用返回值的回调对象和所述请求上下文对象均作为所述更新后的消息的参数。例如，本申请的实施例中，在进行业务容灾调用时，除了传入调用请求中的请求参数外，还需传入请求上下文对象context这一参数，并注册业务的回调对象observer，即回调方法。在步骤s13中将请求参数打包并封装在消息中时，还将调用请求对应的调用上下文状态数据封装成请求上下文对象，并将所述调用请求对应的、用于接收调用返回值的回调对象和所述请求上下文对象均作为所述更新后的消息的参数，以便通过所述请求上下文对象context对象传递调用请求的上下文状态数据，通过回调对象observer接收调用返回值的回调对象，使得用户可以把业务自身需要的参数包装进上请求下文对象context中。在回调对象observer被回调时，所述请求上下文对象context会连同返回值一起被传递给回调对象observer对应的回调方法，以便用户在回调方法中获取调用时的请求上下文数据，并继续后续的业务逻辑，使得客户端集群中的客户端节点不保留任何调用上下文状态，而是把调用上下文状态数据封装成请求下文对象context，并把所述请求上下文对象context作为消息或更新后的消息中的参数，同消息或更新后的消息一起传递，因此，所述客户端集群中的任意客户端节点都可以消费调用请求对应的更新后的消息，进行重试调用。并在容灾调用完成时，回调业务的所述回调对象observer，并把所述请求上下文对象context对象传递给所述回调对象observer，以便所述回调对象observer根据所述请求上下文对象context对象中的参数继续完成后续的业务逻辑，从而实现在客户端接收到调用的返回值(调用成功与否)后回调业务，完成后续业务逻辑。接着本申请的上述实施例，所述步骤s14将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求，具体包括：将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至所述更新后的消息的缓存时间达到预设的消息超时时间时，将所述调用请求转发至交换机，以使所述交换机将所述更新后的消息转发至请求队列；在此，所述预设的消息超时时间可以包括但不限于任何时长的时间等。消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求。在此，所述请求延迟队列用于存储调用失败的请求及其对应封装后的消息，所述请求队列用于存储客户端节点即将进行重试调用的请求，以便客户端节点能够随时消费该请求队列中的消息，以发起重试调用请求。例如，所述步骤s13将调用失败的调用请求打包并封装后，在所述步骤s14中将调用请求需要再次重试时对应的更新后的消息发送至外部的请求延迟队列进行缓存，使得更新后的消息在请求延迟队列中堆积，并记录消息在请求延迟队列中缓存的缓存时间；当请求延迟队列中的消息的缓存时间达到所述预设的消息超时时间expiration，则将超时对应的消息的调用请求转发至交换机，以使所述交换机将所述调用请求的更新后的消息转发至请求队列；以便客户端能够消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求，从而实现调用请求及其消息进入请求延迟队列进行缓存后，可以在后续被客户端消费转发至请求队列中的消息，如图2中的上半部分的客户端集群向请求延迟队列发送重试调用请求的框架图。接着本申请的上述实施例，所述步骤s14中的消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求，包括：对所述请求队列中的所述更新后的消息进行解析，得到所述更新后的消息中的接口名、方法名及请求参数；基于所述更新后的消息中的接口名、方法名及请求参数，向所述服务端发起所述重试调用请求。例如，客户端对转发至所述请求队列中的调用请求对应的更新后的消息进行解析，从所述更新后的消息中解析出的接口名interface、方法名method及请求参数requestjson等参数，使得客户端能够基于解析后得到的接口名interface、方法名method及请求参数requestjson等参数向所述服务端发起远程调用的重试调用请求，从而转至步骤s12以执行向服务端的远程调用过程，以实现在客户端对从请求延迟队列转发至请求队列中的消息进行消费，从而实现对远程调用的重试。接着本申请的上述实施例，所述步骤s14中的所述向所述服务端发起重试调用请求，包括：确定重试间隔时间，按照所述重试间隔时间向所述服务端发起重试调用请求，其中，所述重试间隔时间为用户预置的间隔时间，或由所述用户预置的初始重试间隔时间采用指数退避算法确定直至达到预置的最大重试间隔时间。需要说明的是，本申请的实施例中在进行调用重试时，可以采用多种重试策略retrypolicy，下面主要从两种重试策略进行展开说明：重试策略一、客户端的用户可以设定用于进行远程调用的重试时的预设的最大重试次数totalcount和重试间隔时间，当客户端在消费请求队列中的消息时，可以按照设置的所述重试间隔时间对请求队列中的消息，向服务端发送重试调用请求，若调用失败，则再次间隔所述重试间隔时间再次想服务端发起下一次的重试调用请求，直至调用成功或达到所述预设的最大重试次数totalcount，从而实现按照不变的重试间隔时间向服务端发起重试调用请求。在此，所述重试间隔时间大于所述调用请求在请求延迟队列中缓存的所述预设的消息超时时间，以便需要重试的调用请求能够在请求延迟队列中缓存到期后，进入请求队列被客户端消费。重试策略二、所述指数退避算法即指数后退算法，所述指数退避算法是以冲突窗口大小为基准的，每个节点有一个冲突计数器，退避的时间与冲突次数具有指数关系，冲突次数越多，退避的时间就可能越长，若达到限定的冲突次数，该节点就停止发送数据。在本申请的实施例中，客户端的用户可以设置用于进行后续调用重试时的初始重试间隔时间，随着调用失败的发生，第一次发起重试调用请求的重试间隔时间为初始重试间隔时间，第二次、第三次及后续第n(即totalcount)次向服务端发起重试调用请求的重试间隔时间为：basesleeptimems*math.max(1，random.nextint(1＜＜(retryconut 1)))，直至调用成功或达到预置的最大重试次数，从而实现在客户端按照指数退避算法来对重试间隔时间进行变化，从而采用不同的重试间隔时间向服务端发起重试调用请求。其中，basesleeptimems表示初始重试间隔时间，retryconut表示当前重试次数。如图5所示，在本申请实施例中提供的一种服务远程调用的容灾方法的实际应用场景中，在客户端与服务端之间建议远程调用连接后，当客户端需要向服务端发起远程调用时，所述客户端向所述服务端发起远程调用。根据返回值确定调用是否成功，若调用成功，则回调observer.onsuccess()，用于通知业务调用成功，并结束调用流程或重试调用流程；若调用失败，则检查所述调用请求对应的消息中的当前重试次数retrycount和预设的最大重试次数totalcount的值(当调用请求为第一次调用时，当前重试次数retrycount为0)，以便根据所述调用请求对应的消息中的当前重试次数retrycount和预设的最大重试次数totalcount的值来确定是否需要重试调用。判断所述消息中的当前重试次数retrycount是否小于所述预设的最大重试次数totalcount，若否，表示所述调用请求对应的消息已重试调用的次数大于等于预设的最大重试次数，则不再重试调用请求，直接回调observer.onerror()，通知业务调用失败，并结束重试调用流程，以实现对超过预设的最大重试次数的调用请求的结束处理，以节省出更多的调用内存资源来满足别的调用请求；若是，则表示所述调用请求对应的消息已重试调用的次数小于预设的最大重试次数，还可以继续进行重试调用，则将所述调用请求封装成更新后的消息，并在每次发送该更新后的消息之前，将所述当前重试次数加1，再赋值给所述更新后的消息中的当前重试次数retrycount，即retrycount＝retrycount 1，并对调用请求进行封装处理并将处理后得到的更新后的消息放入请求延迟队列进行缓存，从而实现对调用失败的请求的缓存，以便后续进行调用的重试。在调用重试过程中，当请求延迟队列中的消息的缓存时间达到所述预设的消息超时时间expiration，则将超时对应的消息的调用请求转发至交换机，以使所述交换机将所述调用请求的更新后的消息转发至请求队列，以便客户端能够消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求，从而转至步骤s12以执行向服务端的远程调用过程，以实现在客户端对从请求延迟队列转发至请求队列中的消息进行消费，从而实现对远程调用的重试。根据本申请的另一方面，如6所示，本申请一个方面的一种实施例还提供了一种服务远程调用的容灾设备的结构示意图，该设备包括连接建立装置11、发起调用装置12、请求封装装置13、重试缓存装置14及调用成功装置15，其中，具体包括如下执行步骤：连接建立装置11，用于建立客户端与服务端之间的远程调用连接。在所述连接建立装置11中，在客户端与服务端之间进行远程调用之前，需要在客户端与服务端之间建立起用于远程调用的连接，如图2中的虚线的下半部分所示，为本领域传统的微服务通信框架远程调用结构图。在建立客户端与服务端之间的远程调用连接过程中，首先，服务端集群中的服务端节点启动时，将该服务端节点自身的ip地址、端口号等服务元信息注册到注册中心；接着，客户端集群中的客户端节点在进行服务远程调用时，通过所述注册中心查询远程调用的服务端节点对应的ip地址及端口号等服务原信息，并通过ip地址与该服务端节点建立用于服务远程调用的连接，实现通过注册中心来建立客户端节点与服务端节点之间的远程调用连接。在完成客户端节点与服务端节点之间的远程调用连接后，客户端节点可以向服务端节点发起远程调用，以便所述服务端节点在接收到调用请求后，执行相应的业务方法来处理调用请求，执行完成后再将执行结果返回至客户端节点，以完成服务远程调用。当客户端集群中的客户端需要向服务端发起远程调用时，发起调用装置12，用于向所述服务端发起调用请求。若调用失败，执行请求封装装置13和重试缓存装置14，若调用成功，则执行调用成功装置15。其中，所述请求封装装置13，用于当检查到所述调用请求对应的消息中的当前重试次数retrycount小于预设的最大重试次数totalcount，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1，即retrycount 1，以实现在调用失败时，对调用请求打包成消息，并对更新后的消息中的当前重试次数进行累计加1。所述重试缓存装置14，用于将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求。若调用成功，所述调用成功装置15，用于直接回调用于指示业务调用成功的第二响应信息并结束调用或重试调用。例如，在所述调用成功装置15中，当所述调用请求是第一次调用时，若调用成功，所述调用成功装置15直接回调用于指示业务调用成功的第二响应信息并结束调用；当所述调用请求并非第一次调用，即属于重试的调用请求，若调用成功，所述调用成功装置15直接回调用于指示业务调用成功的第二响应信息并结束重试调用，以实现对远程调用成功时的回调响应。通过上述连接建立装置11、发起调用装置12、请求封装装置13、重试缓存装置14及调用成功装置15，通过外部的请求延迟队列实现了对调用失败时的调用请求的缓存，不仅提高了同时出现大量请求失败时的调用请求的缓存，提高了对调用请求进行重试的能力；还实现了在调用成功时，回调用于指示业务调用成功的第二响应信息并结束调用或重试调用，进而实现对远程调用成功时的回调响应。接着本申请的上述实施例，所述发起调用装置12具体用于：若调用失败，则检查所述调用请求对应的消息中的当前重试次数和预设的最大重试次数，判断所述消息中的当前重试次数是否小于所述预设的最大重试次数；若是，则将所述调用请求封装成更新后的消息，并将所述当前重试次数加1再赋值给所述更新后的消息中的当前重试次数。例如，当调用失败时，所述请求封装装置13检查所述调用请求对应的消息中的当前重试次数retrycount和预设的最大重试次数totalcount的值(当调用请求为第一次调用时，当前重试次数retrycount为0)，以便根据所述调用请求对应的消息中的当前重试次数retrycount和预设的最大重试次数totalcount的值来确定是否需要重试调用。判断所述消息中的当前重试次数retrycount是否小于所述预设的最大重试次数totalcount，若是，则表示所述调用请求对应的消息已重试调用的次数小于预设的最大重试次数，还可以继续进行重试调用，则将所述调用请求封装成更新后的消息，并在每次发送该更新后的消息之前，将所述当前重试次数加1，再赋值给所述更新后的消息中的当前重试次数retrycount，即retrycount＝retrycount 1，以实现当调用失败且调用请求对应的消息中的当前重试次数小于所述预设的最大重试次数时，对调用请求进行封装处理并将处理后得到的更新后的消息放入请求延迟队列进行缓存，从而实现对调用失败的请求的缓存，以便后续进行调用的重试。接着本申请的上述实施例，所述请求封装装置13还用于：若否，则直接回调用于指示业务调用失败的第一响应信息并结束重试调用。例如，在请求封装装置13中判断所述调用请求对应的消息中的当前重试次数retrycount是否小于所述预设的最大重试次数totalcount，若否，表示所述调用请求对应的消息已重试调用的次数大于等于预设的最大重试次数，则不再重试调用请求，直接回调observer.onerror()，通知业务调用失败，并结束重试调用流程，以实现对超过预设的最大重试次数的调用请求的结束处理，以节省出更多的调用内存资源来满足别的调用请求。接着本申请的上述实施例，所述请求封装装置13具体用于：将所述调用请求中的请求参数打包并封装成所述更新后的消息。例如，当调用失败时，所述请求封装装置13检查到的所述调用请求对应的消息中的当前重试次数retrycount小于所述预设的最大重试次数totalcount时，表示所述调用请求对应的消息已重试调用的次数小于预设的最大重试次数，还可以继续进行重试调用，则将所述调用请求中的请求参数进行打包并封装成更新后的消息，所述更新后的消息包括包头和包体，如图3和图4所示，图3中示出调用请求对应的消息或更新后的消息的包头及包头中包含的参数，图4中示出调用请求对应的消息或更新后的消息的包体及其包体中包含的参数，图3和图4中的各个参数的简要说明如表1所示。表1消息中的各个参数字段的说明表字段说明retrycount当前重试次数totalcount最大重试次数retrypolicy重试策略expiration消息超时时间interface接口名method方法名context请求上下文requestjson请求参数observer业务注册的回调对象接着本申请的上述实施例，所述客户端集群的任意客户端节点都可以消费请求队列中的调用请求，所以发起重试调用请求的客户端节点可能和第一发起调用请求的客户端节点不同，则为了便于在重试调用完成后把调用成功与否的结果通知到业务，并完成后续的业务流程，本申请实施例中的所述请求封装装置13还用于：将所述调用请求对应的调用上下文状态数据封装成请求上下文对象；将所述调用请求对应的、用于接收调用返回值的回调对象和所述请求上下文对象均作为所述更新后的消息的参数。例如，本申请的实施例中，在进行业务容灾调用时，除了传入调用请求中的请求参数外，还需传入请求上下文对象context这一参数，并注册业务的回调对象observer，即回调方法。在请求封装装置13中将请求参数打包并封装在消息中时，还将调用请求对应的调用上下文状态数据封装成请求上下文对象，并将所述调用请求对应的、用于接收调用返回值的回调对象和所述请求上下文对象均作为所述更新后的消息的参数，以便通过所述请求上下文对象context对象传递调用请求的上下文状态数据，通过回调对象observer接收调用返回值的回调对象，使得用户可以把业务自身需要的参数包装进上请求下文对象context中。在回调对象observer被回调时，所述请求上下文对象context会连同返回值一起被传递给回调对象observer对应的回调方法，以便用户在回调方法中获取调用时的请求上下文数据，并继续后续的业务逻辑，使得客户端集群中的客户端节点不保留任何调用上下文状态，而是把调用上下文状态数据封装成请求下文对象context，并把所述请求上下文对象context作为消息或更新后的消息中的参数，同消息或更新后的消息一起传递，因此，所述客户端集群中的任意客户端节点都可以消费调用请求对应的更新后的消息，进行重试调用。并在容灾调用完成时，回调业务的所述回调对象observer，并把所述请求上下文对象context对象传递给所述回调对象observer，以便所述回调对象observer根据所述请求上下文对象context对象中的参数继续完成后续的业务逻辑，从而实现在客户端接收到调用的返回值(调用成功与否)后回调业务，完成后续业务逻辑。接着本申请的上述实施例，所述重试缓存装置14具体用于：将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至所述更新后的消息的缓存时间达到预设的消息超时时间时，将所述调用请求转发至交换机，以使所述交换机将所述更新后的消息转发至请求队列；在此，所述预设的消息超时时间可以包括但不限于任何时长的时间等。消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求。在此，所述请求延迟队列用于存储调用失败的请求及其对应封装后的消息，所述请求队列用于存储客户端节点即将进行重试调用的请求，以便客户端节点能够随时消费该请求队列中的消息，以发起重试调用请求。例如，所述请求封装装置13将调用失败的调用请求打包并封装后，在所述重试缓存装置14中将调用请求需要再次重试时对应的更新后的消息发送至外部的请求延迟队列进行缓存，使得更新后的消息在请求延迟队列中堆积，并记录消息在请求延迟队列中缓存的缓存时间；当请求延迟队列中的消息的缓存时间达到所述预设的消息超时时间expiration，则将超时对应的消息的调用请求转发至交换机，以使所述交换机将所述调用请求的更新后的消息转发至请求队列；以便客户端能够消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求，从而实现调用请求及其消息进入请求延迟队列进行缓存后，可以在后续被客户端消费转发至请求队列中的消息，如图2中的上半部分的客户端集群向请求延迟队列发送重试调用请求的框架图。接着本申请的上述实施例，所述重试缓存装置14具体用于：对所述请求队列中的所述更新后的消息进行解析，得到所述更新后的消息中的接口名、方法名及请求参数；基于所述更新后的消息中的接口名、方法名及请求参数，向所述服务端发起所述重试调用请求。例如，客户端对转发至所述请求队列中的调用请求对应的更新后的消息进行解析，从所述更新后的消息中解析出的接口名interface、方法名method及请求参数requestjson等参数，使得客户端能够基于解析后得到的接口名interface、方法名method及请求参数requestjson等参数向所述服务端发起远程调用的重试调用请求，从而转至发起调用装置12以执行向服务端的远程调用过程，以实现在客户端对从请求延迟队列转发至请求队列中的消息进行消费，从而实现对远程调用的重试。接着本申请的上述实施例，所述重试缓存装置14具体用于：确定重试间隔时间，按照所述重试间隔时间向所述服务端发起重试调用请求，其中，所述重试间隔时间为用户预置的间隔时间，或由所述用户预置的初始重试间隔时间采用指数退避算法确定直至达到预置的最大重试间隔时间。需要说明的是，本申请的实施例中在进行调用重试时，可以采用多种重试策略retrypolicy，下面主要从两种重试策略进行展开说明：重试策略一、客户端的用户可以设定用于进行远程调用的重试时的预设的最大重试次数totalcount和重试间隔时间，当客户端在消费请求队列中的消息时，可以按照设置的所述重试间隔时间对请求队列中的消息，向服务端发送重试调用请求，若调用失败，则再次间隔所述重试间隔时间再次想服务端发起下一次的重试调用请求，直至调用成功或达到所述预设的最大重试次数totalcount，从而实现按照不变的重试间隔时间向服务端发起重试调用请求。在此，所述重试间隔时间大于所述调用请求在请求延迟队列中缓存的所述预设的消息超时时间，以便需要重试的调用请求能够在请求延迟队列中缓存到期后，进入请求队列被客户端消费。重试策略二、所述指数退避算法即指数后退算法，所述指数退避算法是以冲突窗口大小为基准的，每个节点有一个冲突计数器，退避的时间与冲突次数具有指数关系，冲突次数越多，退避的时间就可能越长，若达到限定的冲突次数，该节点就停止发送数据。在本申请的实施例中，客户端的用户可以设置用于进行后续调用重试时的初始重试间隔时间，随着调用失败的发生，第一次发起重试调用请求的重试间隔时间为初始重试间隔时间，第二次、第三次及后续第n(即totalcount)次向服务端发起重试调用请求的重试间隔时间为：bases1eeptimems*math.max(1，random.nextint(1＜＜(retryconut 1)))，直至调用成功或达到预置的最大重试次数，从而实现在客户端按照指数退避算法来对重试间隔时间进行变化，从而采用不同的重试间隔时间向服务端发起重试调用请求。其中，basesleeptimems表示初始重试间隔时间，retryconut表示当前重试次数。如图5所示，在本申请实施例中提供的一种服务远程调用的容灾方法的实际应用场景中，在客户端与服务端之间建议远程调用连接后，当客户端需要向服务端发起远程调用时，所述客户端向所述服务端发起远程调用。根据返回值确定调用是否成功，若调用成功，则回调observer.onsuccess()，用于通知业务调用成功，并结束调用流程或重试调用流程；若调用失败，则检查所述调用请求对应的消息中的当前重试次数retrycount和预设的最大重试次数totalcount的值(当调用请求为第一次调用时，当前重试次数retrycount为0)，以便根据所述调用请求对应的消息中的当前重试次数retrycount和预设的最大重试次数totalcount的值来确定是否需要重试调用。判断所述消息中的当前重试次数retrycount是否小于所述预设的最大重试次数totalcount，若否，表示所述调用请求对应的消息已重试调用的次数大于等于预设的最大重试次数，则不再重试调用请求，直接回调observer.onerror()，通知业务调用失败，并结束重试调用流程，以实现对超过预设的最大重试次数的调用请求的结束处理，以节省出更多的调用内存资源来满足别的调用请求；若是，则表示所述调用请求对应的消息已重试调用的次数小于预设的最大重试次数，还可以继续进行重试调用，则将所述调用请求封装成更新后的消息，并在每次发送该更新后的消息之前，将所述当前重试次数加1，再赋值给所述更新后的消息中的当前重试次数retrycount，即retrycount＝retrycount 1，并对调用请求进行封装处理并将处理后得到的更新后的消息放入请求延迟队列进行缓存，从而实现对调用失败的请求的缓存，以便后续进行调用的重试。在调用重试过程中，当请求延迟队列中的消息的缓存时间达到所述预设的消息超时时间expiration，则将超时对应的消息的调用请求转发至交换机，以使所述交换机将所述调用请求的更新后的消息转发至请求队列，以便客户端能够消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求，从而转至执行发起调用装置12中的向服务端的远程调用的过程，以实现在客户端对从请求延迟队列转发至请求队列中的消息进行消费，从而实现对远程调用的重试。综上所述，本申请通过首先建立客户端与服务端之间的远程调用连接，当需要向服务端发起远程调用时，向所述服务端发起调用请求；若调用失败，当检查到所述调用请求对应的消息中的当前重试次数小于预设的最大重试次数，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1；将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求，实现了对调用失败对应的调用请求的缓存，不仅提高了同时出现大量请求失败时的调用请求的缓存，提高了对调用请求进行重试的能力。以上详细描述了本申请的较佳具体实施例。应当理解，本领域的普通技术无需创造性劳动就可以根据本申请的构思作出诸多修改和变化。因此，凡本
技术领域：
中技术人员依本申请的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案，皆应在由权利要求书所确定的保护范围内。当前第1页1 2 3
技术特征：1.一种服务远程调用的容灾方法，其特征在于，所述方法包括：
建立客户端与服务端之间的远程调用连接；
向所述服务端发起调用请求；
若调用失败，当检查到所述调用请求对应的消息中的当前重试次数小于预设的最大重试次数，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1；
将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求。
2.如权利要求1所述的方法，其特征在于，所述若调用失败，当检查到所述调用请求对应的消息中的当前重试次数小于预设的最大重试次数，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1，包括：
若调用失败，则检查所述调用请求对应的消息中的当前重试次数和预设的最大重试次数，
判断所述消息中的当前重试次数是否小于所述预设的最大重试次数；
若是，则将所述调用请求封装成更新后的消息，并将所述当前重试次数加1再赋值给所述更新后的消息中的当前重试次数。
3.如权利要求1或2所述的方法，其特征在于，所述将所述调用请求封装成更新后的消息，包括：
将所述调用请求中的请求参数打包并封装成所述更新后的消息。
4.如权利要求3所述的方法，其特征在于，所述将所述调用请求中的请求参数打包并封装成所述更新后的消息的同时，还包括：
将所述调用请求对应的调用上下文状态数据封装成请求上下文对象；
将所述调用请求对应的、用于接收调用返回值的回调对象和所述请求上下文对象均作为所述更新后的消息的参数。
5.如权利要求2所述的方法，其特征在于，所述判断所述消息中的当前重试次数是否小于所述预设的最大重试次数之后，还包括：
若否，则直接回调用于指示业务调用失败的第一响应信息并结束重试调用。
6.如权利要求1所述的方法，其特征在于，所述方法还包括：
若调用成功，则直接回调用于指示业务调用成功的第二响应信息并结束调用或重试调用。
7.如权利要求1所述的方法，其特征在于，所述将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求，包括：
将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至所述更新后的消息的缓存时间达到预设的消息超时时间时，将所述调用请求转发至交换机，以使所述交换机将所述更新后的消息转发至请求队列；
消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求。
8.如权利要求1所述的方法，其特征在于，所述消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求，包括：
对所述请求队列中的所述更新后的消息进行解析，得到所述更新后的消息中的接口名、方法名及请求参数；
基于所述更新后的消息中的接口名、方法名及请求参数，向所述服务端发起所述重试调用请求。
9.如权利要求1至8中任一项所述的方法，其特征在于，所述向所述服务端发起重试调用请求，包括：
确定重试间隔时间，按照所述重试间隔时间向所述服务端发起重试调用请求，
其中，所述重试间隔时间为用户预置的间隔时间，或由所述用户预置的初始重试间隔时间采用指数退避算法确定直至达到预置的最大重试间隔时间。
10.一种服务远程调用的容灾设备，其特征在于，所述设备包括：
连接建立装置，用于建立客户端与服务端之间的远程调用连接；
发起调用装置，用于向所述服务端发起调用请求；
请求封装装置，用于若调用失败，当检查到所述调用请求对应的消息中的当前重试次数小于预设的最大重试次数，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1；
重试缓存装置，用于将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求。
11.如权利要求10所述的设备，其特征在于，所述请求封装装置用于：
若调用失败，则检查所述调用请求对应的消息中的当前重试次数和预设的最大重试次数，
判断所述消息中的当前重试次数是否小于所述预设的最大重试次数；
若是，则将所述调用请求封装成更新后的消息，并将所述当前重试次数加1再赋值给所述更新后的消息中的当前重试次数。
12.如权利要求10或11所述的设备，其特征在于，所述请求封装装置用于：
将所述调用请求中的请求参数打包并封装成所述更新后的消息。
13.如权利要求12所述的设备，其特征在于，所述请求封装装置还用于：
将所述调用请求对应的调用上下文状态数据封装成请求上下文对象；
将所述调用请求对应的、用于接收调用返回值的回调对象和所述请求上下文对象均作为所述更新后的消息的参数。
14.如权利要求10所述的设备，其特征在于，所述重试缓存装置用于：
将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至所述更新后的消息的缓存时间达到预设的消息超时时间时，将所述调用请求转发至交换机，以使所述交换机将所述更新后的消息转发至请求队列；
消费所述请求队列中的消息，以向所述服务端发起所述重试调用请求。
15.如权利要求10至14中任一项所述的设备，其特征在于，所述重试缓存装置用于：
确定重试间隔时间，按照所述重试间隔时间向所述服务端发起重试调用请求，
其中，所述重试间隔时间为用户预置的间隔时间，或由所述用户预置的初始重试间隔时间采用指数退避算法确定直至达到预置的最大重试间隔时间。
技术总结本申请公开了一种服务远程调用的容灾方法及设备，本申请通过建立客户端与服务端之间的远程调用连接，当需要向服务端发起远程调用时，向所述服务端发起调用请求；若调用失败，当检查到所述调用请求对应的消息中的当前重试次数小于预设的最大重试次数，将所述调用请求封装成更新后的消息，并将所述当前重试次数加1；将所述更新后的消息发送至外部的请求延迟队列进行缓存，直至满足预设重试条件后，转至向所述服务端发起重试调用请求，实现了对调用失败对应的调用请求的缓存，不仅提高了同时出现大量请求失败时的调用请求的缓存，提高了对调用请求进行重试的能力。
技术研发人员：杨磊;姜元龙;邢益伟
受保护的技术使用者：上海钧正网络科技有限公司
技术研发日：2020.01.09
技术公布日：2020.06.09
