描述
本文分享的是19年的时候，遇到的一个实际问题，这个接口是请求一个耗时的微服务，需要的后端多库表联查和反查，所以比一般的接口请求时间要长，可能会超过两分钟，而后端在自测这部分时用的postman自测，能成功只是时间长，而前端则会因为超时直接断开，最终双方争执不下，我把这部分进行了深一步的研究，得出一些结论给大家共享下。
不同请求方式的差异
目前前端请求以spa为例，如果使用的为webpack的构建工具，则开发服务器是webpack-dev-server提供的，dev-server内部用的是express，express内部用的是 require('http')。如果用了http-proxy-middleware 内部使用了一个叫node-http-proxy的库，本质上还是require('http')。 如果用代理的话解决方法是设置proxyTimeout或者timeout，参考github.com/chimurai/ht…
在前端发出请求之后，这一请求还是要通过浏览器内核才能真正发出，因为请求的本质还是xhr请求，chrome浏览器的内核中写的请求时间是5分钟。
那么后端自测又是怎么自测通过的呢？一般后端有两种自测，一种是本地代码执行单测，这种肯定没有超时限制，除非jdbc或者代码本身gg了，还有一种就是使用swagger和postman，而swagger和postman是可以没有任何超时控制的，所以这两个模拟请求不能完全重现前端请求超时的错误。
实际情况
实际情况，我发现问题不仅仅在这里，还在于后端接了网关，但是网关却由于技术限制不能区分的设置各个接口的差别时长，即使前端放开了请求时长，放开到5分钟，也会因为后端网关统一设置的请求时长导致返回接口超时的问题。
最终的方案： 1 后端在接口性能上做支持，缩短请求时长 2 后端提供多个网关，当涉及到长时长接口，使用差别的网关进行请求 3 前端针对长时长的接口，不用网关，改为ip+端口的请求方式，就可以避开因为网关设置超时时间导致的超时问题
延伸思考：多向外一步
当问题发生了，希望每个职能可以跳出自己的边界，去思考问题为什么会发生，而不是停留在为什么我这是对的，这对于解决问题没有任何帮助。当问题发生了，我们更要思考的问题或者方向是：
1 是不是别人的方式和自己有什么不同 2 是不是自己有什么盲区，导致了这次的问题 3 如何能够复现别人所出现的问题，尤其是在自己的机器或者环境下 4 当问题发生时，先安抚对方的情绪，然后查看能否以自己的方式或者其他补救方式，让对方解决此时的窘境 5 当能排查到原因，方案之后，将全程复盘并扩展到部门或者公司的规范，价值最大化
原文地址：www.yuque.com/robinson/wo…
常见问题FAQ
- 免费下载或者VIP会员专享资源能否直接商用？
- 本站所有资源版权均属于原作者所有，这里所提供资源均只能用于参考学习用，请勿直接商用。若由于商用引起版权纠纷，一切责任均由使用者承担。更多说明请参考 VIP介绍。
- 提示下载完但解压或打开不了？
- 找不到素材资源介绍文章里的示例图片？
- 模板不会安装或需要功能定制以及二次开发？
发表评论
还没有评论，快来抢沙发吧！