一种前端调用微服务接口时的超时时间的动态配置方法

摘要

本发明公开了一种前端调用微服务接口时的超时时间的动态配置方法，该方法先获取需要动态配置的接口，进行记录并作为备选集合；再以系统监控模块或日志的数据作为输入，计算出一个接口的超时时间期望值；最后在前端将记录的接口的超时时间设置为期望值；除此之外还可以额外配置超时时间管理界面，管理者根据分析和具体需求手动调整超时时间，并将人工设置的时间设为最高优先级。本发明与现有技术相比，无需前端开发人员手动调整超时时间，在系统运行后，前端调用接口时可以自动地对超时时间进行动态配置，有效地节省人力和时间。

说明书

技术领域

本发明属于微服务应用领域，尤其是涉及一种前端调用微服务接口时的超时时间的动态配置方法。

背景技术

近年来，在web端，前后端分离的框架成为主流，前端请求数据往往只能手动设置一个统一的超时时间。设置超时时间的意义，是在极端情况下，采用主动的快速失败策略，使得资源消耗与释放资源之间达到平衡，避免调用双方因资源耗尽而宕机。超时时间设置不当则会影响用户体验，发生故障。而对于基于微服务的后端，在大型系统中，往往一个接口调用链涉及到十几个微服务，全面使用统一的超时时间显然无法应对这种复杂情况，在以往的研究中，往往着重于微服务内部的超时时间的管理，本发明基于前端提出了一种超时时间的动态配置方法。

现有的超时时间配置往往采用一个统一的默认配置，在面对微服务这种复杂架构或业务复杂繁琐的系统时，往往需要前端开发人员根据经验或者人工分析手动调整请求接口的超时时间，需要花费大量人力物力，还造成极大的耦合性隐患，不利于业务调整和系统升级。

发明内容

有鉴于此，本发明旨在提出一种前端调用微服务接口时的超时时间的动态配置方法，以解决现有的超时时间配置往往采用一个统一的默认配置，在面对微服务这种复杂架构或业务复杂繁琐的系统时，往往需要前端开发人员根据经验或者人工分析手动调整请求接口的超时时间，需要花费大量人力物力，还造成极大的耦合性隐患，不利于业务调整和系统升级的问题。

为达到上述目的，本发明的技术方案是这样实现的：

一种前端调用微服务接口时的超时时间的动态配置方法，包括以下步骤：

S1、使用链路追踪工具获得超过调用链长度阈值或超过耗时时间阈值的接口，进行记录作为需要进行动态配置的接口集合；

S2、利用调用接口的响应时间平均值、查询率、异常率、调用接口的微服务数量和前端期望阈值作为影响因子，通过超时时间期望值的计算公式计算出一个接口的超时时间期望值，按照固定周期更新计算出的超时时间期望值；

S3、在前端编写自定义的拦截器或修改已有的拦截器，通过拦截器获取步骤S2中计算的超时时间期望值，作为本次调用接口的超时时间期望值。

进一步的，步骤S1中，所用链路追踪工具为Spring Cloud Sleuth；

步骤S1中调用链长度阈值为10个节点、耗时时间阈值为3s。

进一步的，步骤S1中使用链路追踪工具获取接口后作为需要进行动态配置的接口集合的具体过程包括：Sleuth根据一个RPC或是向RPC发送的一个响应来生成一个64位的SpanID，其中，SpanID表示一个微服务，Sleuth为一次请求链路生成唯一的TraceID，一个Trace中包含多个Span，一次请求涉及到多个微服务，对每次请求进行注解，对每次请求链路中的时间参数写入到系统的日志中；

时间参数包括请求的处理时间、网络延迟时间、请求后系统的反应时间。

进一步的，步骤S2中超时时间期望值的计算公式如下：

式中，T表示超时时间期望值，AVG代表从日志或监控模块中统计得到的响应时间的平均值，QPS代表每秒查询率，N代表调用接口的微服务数量，R代表接口调用异常率，limit指前端期望阈值，k

进一步的，步骤S3中，编写自定义的拦截器或修改已有的拦截器从后台接口获取本次调用接口的超时时间期望值，然后在拦截器中，判断调用接口请求是否是步骤S1中记录下来的接口请求，是则配置成对应的期望时间，否则不处理，超时时间会被设置成通用配置里的默认值。

进一步的，编写自定义的拦截器或修改已有的拦截器从后台接口获取本次调用接口的超时时间期望值，采用以下两种加快方法加快获取速度：

第一种，将数据缓存在前端本地，有更新的时候进行拉取；

第二种，后端将数据缓存在Redis中，避免了后端反复向远端配置中心请求。

进一步的，还包括配置超时时间管理界面，管理者根据分析和具体需求手动调整超时时间期望值，并将人工设置的时间设置为最高优先级。

相对于现有技术，本发明所述的一种前端调用微服务接口时的超时时间的动态配置方法具有以下有益效果：

本发明所述的动态配置方法前端开发人员无需手动调整，前端调用接口时能自动地动态地配置成合理的超时时间，极大的减少了开发人员在这方面的人力时间投入。甚至对于不熟悉前端代码的业务人员或测试人员，在一些特殊情况下，无需改动代码，也能通过本方法中提到的UI页面手动调整，增加了系统的灵活性。

附图说明

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

图1为本发明实施例所述的SpringCloudSletuth的一次链路调用轨迹框图；

图2为本发明实施例所述的动态配置方法流程图。

具体实施方式

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”等的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以通过具体情况理解上述术语在本发明中的具体含义。

下面将参考附图并结合实施例来详细说明本发明。

一种前端调用微服务接口时的超时时间的动态配置方法，包括以下步骤：

S1、使用链路追踪工具获得超过调用链长度阈值或超过耗时时间阈值的接口，进行记录作为需要进行动态配置的接口集合；

S2、利用调用接口的响应时间平均值、查询率、异常率、调用接口的微服务数量和前端期望阈值作为影响因子，通过超时时间期望值的计算公式计算出一个接口的超时时间期望值，按照固定周期更新计算出的超时时间期望值；

S3、在前端编写自定义的拦截器或修改已有的拦截器，通过拦截器获取步骤S2中计算的超时时间期望值，作为本次调用接口的超时时间期望值。

步骤S1中，所用链路追踪工具为Spring Cloud Sleuth；

步骤S1中调用链长度阈值为10个节点、耗时时间阈值为3s。

步骤S1中使用链路追踪工具获取接口后作为需要进行动态配置的接口集合的具体过程包括：Sleuth根据一个RPC或是向RPC发送的一个响应来生成一个64位的SpanID，其中，SpanID表示一个微服务，Sleuth为一次请求链路生成唯一的TraceID，一个Trace中包含多个Span，一次请求涉及到多个微服务，对每次请求进行注解，对每次请求链路中的处理参数(请求的处理时间，网络延迟时间，反应时间)写入到系统的日志中；在项目运行若干时间后通过日志分析出即调用服务数量较多的接口（即span数量较多的trace），网络延迟和反应时间较长的接口，然后通过后台写入远端配置中心，以上备选接口获取方法适用于规模较大，微服务数量较多的系统，对于规模较小的系统，开发人员直接通过分析在远端配置中心中手动配置。

步骤S2中超时时间期望值的计算公式如下：

式中，T表示超时时间期望值，AVG代表从日志或监控模块中统计得到的响应时间的平均值，QPS代表每秒查询率，N代表调用接口的微服务数量，R代表接口调用异常率，limit指前端期望阈值，k

步骤S3中，编写自定义的拦截器或修改已有的拦截器从后台接口获取本次调用接口的超时时间期望值，然后在拦截器中，判断调用接口请求是否是步骤S1中记录下来的接口请求，是则配置成对应的期望时间，否则不处理，超时时间会被设置成通用配置里的默认值；

本发明使用类似axios的http库，其自带的拦截器会统一处理所有的http请求。

为了加快前端获取超时时间期望值数据的速度使其不影响系统本身；

编写自定义的拦截器或修改已有的拦截器从后台接口获取本次调用接口的超时时间期望值，采用以下两种加快方法加快获取速度：

第一种，将这些数据缓存在前端本地，有更新的时候再进行拉取；

第二种，后端将数据缓存在Redis中，避免了后端反复向远端配置中心请求。

一种前端调用微服务接口时的超时时间的动态配置方法，还包括配置超时间管理界面，管理者根据分析和具体需求手动调整超时时间期望值，并将人工设置的时间设置为最高优先级。

实施例如下：

如图1所示，在微服务系统中，服务之间的依赖关系会变得十分复杂，很难人工收集链路服务之间的依赖关系、调用顺序和相关数据，所以本发明提取数据的手段主要依赖于链路追踪工具对于接口调用链进行追踪，并且通过工具标记请求发起，接受响应等时间点，从而得到较为准确的接口调用时间。并能通过进一步分析日志得到查询率，异常率等相关参数。

接下来以链路追踪工具SpringCloudSletuth为例结合图1进行说明。SpringCloudSleuth根据一个RPC或是向RPC发送的一个响应来生成一个64位的SpanID，其中，SpanID标识一个微服务，一个Span表示一次微服务调用，多个Span形成一个树形结构代表一次完整的调用链路。SpringCloudSleuth也为一次请求调用链路生成唯一的TraceID，一个Trace中包含多个Span，每个Span还会用ParentId字段记录该Span的上级Span，代表该服务的上游服务，入口服务没有上游服务，因此其ParentId也为空。

具体实施过程中，通过代码注解的方式将整个链路调用过程中的信息记录下来，比如使用sr(Server Received)注解可以得到服务端获得请求并准备开始处理时的时间点，使用ss(Server Sent)注解可以得到请求处理完成时的时间点，如果两个时间点相减便可得到该项服务的处理响应时间。通过以上方式将整个链路调用信息记录到日志中，通过进一步处理分析得到每个接口的响应时间平均值AVG, 查询率QPS，异常率R，整个链路调用微服务数量N等等数据。

如图2所示，本发明按以下流程实施：在系统运行一段时间后，按照上一步骤所述通过链路追踪工具得到并记录下足够多的数据到日志中，然后通过日志分析出调用服务数量较多的接口（即Span数量较多的Trace，比如指定Span数量大于10的接口需要进行动态配置，具体阈值由使用者进行配置），网络延迟和反应时间较长的接口，这些接口记录下来并且通过后台写入远端配置中心，以上备选接口获取方法适用于规模较大，微服务数量较多的系统，对于规模较小的系统，开发人员可以直接通过分析在远端配置中心中手动配置。

接着以系统监控模块或日志的数据作为输入，得到响应时间平均值AVG, 查询率QPS，异常率R，调用微服务数量N和前端期望阈值等参数，其中QPS由接口总调用次数除以系统运行时间可得，AVG由每个请求的处理时间取平均值可得，异常率R由出现异常的次数除以总调用次数可得，N即上文所述span的数量。这些参数按如下指定公式计算出一个接口的超时时间期望值，这个期望值会更新到远端配置中心；

在后台系统中设置定时任务，按固定周期更新此期望值，即每隔一定周期就重新从日志中获取数据，进行分析计算，再更新到远端配置中心。

然后在前端编写自定义的拦截器，拦截器从远端获取已记录接口的超时时间期望值，为了加快获取数据的速度，不影响系统本身，一种方法是将获取到的超时时间数据缓存在前端本地中；另一种方法是后台将数据缓存在Redis中，避免了重复读取远端配置中心，最后前端调用接口时将已记录接口的超时时间设定为期望值，其它接口则使用默认值；

作为拓展，可以额外配置超时时间管理界面，管理者根据分析和具体需求手动调整超时时间期望值，并将人工设置的时间设为最高优先级。

本发明中提到的远端配置中心是当前微服务系统较流行的一种模式，即配置文件不写在代码中，而是放置在远程，代码启动运行时再读取远程的配置文件数据，这样能降低耦合性，更有效地管理配置，nacos是比较流行的配置中心工具，其它类似工具也可以作为替代，本发明方法不作限制；本发明提到的拦截器是前端常见的方法手段，使用本发明方法时可以自定义拦截器，也可以来使用类似axios库这种自带的拦截器，本发明方法不作限制。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。