记一次接口调用异常的bug

在某项目中需要调用某商业软件的api接口，在项目过程中，接口调试正常，能正常调用，通过apipost发送接口测试正常运行，在代码调试运行模式下可以正常下发任务，并获取执行状态。

将软件打包运行时报服务器接口超时，输入参数不变，进入debug逐行条代码或者逐行逐函数调用都可正常运行不报异常。经过简要分析后，下发任务有超时设置，看超时设置的值为100ms，通过apipost接口调试得到接口调用返回的时长为150ms~250ms之间，将超时函数的时间调长，改为1s，再打包运行，下发任务，获取数据等钧正常通过。

总结，在调用服务端的服务时，需考虑网络环境和网络时延的问题，客户端向服务端请求的超时时间不宜设置过短。

合理设置超时时间，参考http://t.csdnimg.cn/2vH8n

超时时间设置过短，实际⽣产中容易因⽹络抖动⽽告警频繁，造成服务不稳定等⽤户体验问题。如内容服务调⽤资源服务超时时间设置 200ms，资源服务调⽤ID 发号器服务超时时间设置为 300ms，⼀旦⽹络抖动后，资源服务 200ms 即超时返回，资源服务对下游的调⽤ 300ms 超时也⽆实际意义。

合理设置超时时间，对系统的稳定来⾔，非常重要，我们可以从以下⻆度来考虑设置值：

• ⽤户⻆度。微服务最终为服务对象是⽤户，从⽤户交互数据来讲，服务响应时间在 300ms 内最佳， 2000ms 内仍可接受。通常情况下，建议超时的上限值为 2000ms，超过 2000ms 的非重要请求，则有必要被降级处理。

• 技术⻆度。同时考虑到 TCP 算法中 Delayed ACK + Nagle 算法开启的场景，最小 delay 值 40 ms，建议下限值设定为 50ms； 在 RTT 较⼩的正常网络环境中，TCP 数据包丢包，超时重传的最⼩值，200 ms，因此我们建议 300ms 可以视为超时设置的最佳选择，为重传保留⼀定的余量。

• 资源消耗⻆度。依据资源消耗的分析，超时时间⻓短应当和 QPS 成反⽐例。我们设定基础值超时设定为 300ms、100QPS，并根据实际 QPS 做调整。