[发明专利]远程接口代理调用方法、装置以及计算机设备、存储介质

说明书

本申请公开一种远程接口代理调用方法、装置以及计算机设备、存储介质，该方法包括：响应远程接口调用事件；将该远程接口的参数信息及其执行状态存储至任务数据库，所述执行状态初始化为待执行状态；根据所述参数信息代理调用执行所述远程接口，若该远程接口成功执行，修改该远程接口的执行状态为已执行状态，返回输出该远程接口的执行结果；响应定时任务触发事件而获取所述任务数据库中处于待执行状态的远程接口的参数信息，为该些远程接口重新执行根据所述参数信息代理调用执行所述远程接口的步骤。本申请对远程接口调用事件进行队列化任务调度，对远程接口调用进行缓冲和均衡，能够提高分布式服务集群内跨服务器超远程接口调用的数据通信效率。

技术领域

本申请实施例涉及计算机网络通信领域，尤其涉及一种远程接口代理调用方法、装置以及计算机设备、存储介质。

背景技术

在互联网行业，微服务架构大行其道，哪怕只是一个小的业务模块或者产品线，其底层都是由很多个系统组合而成，系统和系统之间通过远程调用来进行交互，由于系统很多，交互也多，所以它们之间的交互就如同一个网状，其交互关系的复杂度可想而知。如此同时，由于导致网络延迟、网络波动、丢包、服务器异常等问题频发，使得服务和服务之间的交互调用变得不可靠，容易失败。此时，重试是一种比较常见的解决手段，通过不断的重试，最终执行成功。但是，鉴于网状结构的事实，海量的重试对服务器来说，有时候会构成灾难。

为了解决这一问题，个别企业采用了极其复杂的安全控制机制来实现，更为普遍的现有技术是采用Spring Retry、Guava Retry等工具来辅助，他们的共同点都是只能在内存里面重试，一旦系统重启或者宕机就无法继续重试，这些工具的不足主要表现在如下几个方面：

(1)这些工具都是进行同步的、实时的重试。这种重试方式很容易给对方服务器造成双倍甚至多倍的压力。本来只需要调用一次的，但由于出现网络延迟或丢包，调用方由于不知道对方是否已经成功执行了任务，而又不得不重试，就造成了给对方瞬时更多的负载，容易导致对方服务崩溃。

(2)同步的重试一般会设置一个重试次数，比如说是3。而很多时候，发生网络问题后，短时间是没法恢复的，需要很长时间。而此时一次性重试3次根本无济于事，由于重试了3次都失败了，最终只能当失败处理。

(3)他们都是在内存里面重试的，重试的次数以及是否要重试都是在内存里面计算的，一旦系统重启或者宕机，之前的重试信息就丢失，导致无法继续重试。而基于敏捷开发模式的系统，三天两头需要上线重启系统，甚至一天一上线都是很常见的，在这种情况下，基于内存的重试就无法满足系统的要求。

发明内容

本申请的目的在于克服现有技术中至少部分不足而提供一种远程接口代理调用方法及其相应的装置、计算机设备及存储介质。

为解决上述技术问题，本申请实现的一个技术方案是：

本申请的一种远程接口代理调用方法，其包括如下步骤：

响应远程接口调用事件，提取出所述远程接口携带的参数信息；

将该远程接口的参数信息及其执行状态存储至任务数据库，所述执行状态初始化为待执行状态；

根据所述参数信息代理调用执行所述远程接口，若该远程接口成功执行，修改该远程接口的执行状态为已执行状态，返回输出该远程接口的执行结果，若该远程接口执行失败，维持所述执行状态为原状态；

响应定时任务触发事件而获取所述任务数据库中处于待执行状态的远程接口的参数信息，为处于待执行状态的远程接口重新执行根据所述参数信息代理调用执行所述远程接口的步骤。

较佳的实施例中，本申请的远程接口代理调方法包括如下前置步骤：

启动代理调用服务；

获取被标注为属于待代理调用类型的远程接口的列表数据；