ASP.NET Core使用Ocelot的接口返回超时问题

一、背景

　　近期在使用ASP.NET Core、Consul、Ocelot、ID4构建微服务Demo，在完成上述组件集成和测试过程中，对接口请求返回时长基本保持在4秒以上，不管是简单的请求，还是复杂的请求都是超时的状态。通过在网上查找相关组件的设置项的原因，并没有发现问题，也修改一些参数，没有达到预期的效果。从怀疑接口业务超时、数据库请求超时、ID4的认证授权、服务注册与发现到Ocelot的问题，最近定位在Ocelot上，然后找到本机网络连接保持两个，一个是安装Docker容器开启的Hyper-V，通过关闭该网络请求时长保持在3秒以内，一个正常的状态。通过这篇文章记录一下这个问题查找过程。

二、过程

　　1、在ApiPost接口请求数据，接口返回的时长在4秒以上，然后对接口的业务进行检查，使用asp.net core 的Stopwatch监控超时业务，不管是数据库查询操作，还是数据运算都没有超时；2、各个服务之间使用了ID4的认证和授权，在不使用授权或者认证的情况下接口的请求过程还是超时；3、Consul的服务注册与发现，相关参数项配置正确，没有异样的设置，所以服务注册与发现并没有问题；4、在排除上述问题的情况下，不通过Ocelot网关进行访问，直接请求服务地址，接口返回的时长是正常状态，所以问题的根源在Ocelot的组件上，Ocelot是开源的，并且已经验证过，并没有想过的BUG，最终只能拉取源代码，验证是配置的问题，还是源代码中具体哪个环节导致超时的问题，获取源代码，编译源代码，引入项目中，注释使用nuget包，在源代码断点进行调试，找到问题点。源代码如下所示：

 　　Ocelot的整个中间件执行的过程，其过程主要使用中间件的方式，处理请求的上线文内容，返回结果。

　　通过断点调试，最终找到是app.UseOutputCacheMiddleware();中间件处理过程超时了，其过程如上述的代码，主要在HttpClient请求的超时，通过打印这个HTTPClient耗时操作，找到了超时4秒以上的原因。一般在本机是程序HTTPClient不应该请求超时。在查找可能原因中找到了网络问题等一一排查，最终发现这个网络连接有多个，影响了接口的返回结果。

三、总结

　　通过上述问题发现、问题猜测、问题的分析、问题的查找和定位，到解决问题。这个过程中不断验证、调试，阅读源码都是在技术和框架学习中不可或缺的方法。