启动涉及到的相关服务：

测试的端点接口为：http:/login/oauth/token服务之间的调用顺序为：gateway->auth-Service->user-Service。网关收到客户端的请求转发请求到鉴权服务，鉴权服务对用户身份的核验是通过调用用户服用户服务给鉴权服务返回身份校验的结果，鉴权服务将身份授权信息返回给gatewaygateway将最终的结果response返回给客户端。
三个服务启动后通过zipkin监控調用链路信息，可以看到第一次和第二次调用情况如下图所示：

通过上面两次的链路监控信息截图可以看到第一次的耗时是第二次的10多倍。遇到某些情况很可能会出现第一次请求的超时。去官网看了下主要原因是zuul网关和各个调用服务之间的Ribbon进行客户端负载均衡的Client懒加載，导致第一次的请求调用包括了创建Ribbon Client的时间通过启动日志信息就可以发现：

下面分两部分解决这个问题，一是服务之间调用Ribbon的饥饿加載对应上面的测试为auth-Service调用user-Service；二是zuul网关的饥饿加载。

经过调查发现造成第一次auth-Service调用user-Service耗时长的原因主要是，Ribbon进行客户端负载均衡的服务实唎并不是在服务启动的时候就初始化好的而是在调用的时候才会去创建相应的服务实例。所以第一次调用user-Service耗时不仅仅包含发送HTTP请求的时間还包含了创建Ribbon Client的时间，这样一来如果创建时间速度较慢同时设置的请求超时又比较短的话，很容易就会出现耗时很长甚至超时的情況
在官网可以看到如下的配置说明：

意为Spring Cloud为每个Ribbon客户端维护了一个相对的子应用环境的上下文，应用的上下文在第一次请求到指定客户端的时候懒加载不过可以通过如下配置进行修改：

按照如上的配置之后，发现鉴权服务启动时就将user服务的Ribbon客户端进行了加载

上面小节解决了auth-Service调用user-Service的Ribbon客户端启动时饥饿加载。网关作为对外请求的入口zuul内部使用Ribbon调用其他服务，Spring Cloud默认在第一次调用时懒加载Ribbon客户端zuul同样需要維护一个相对的子应用环境的上下文，所以也需要启动时饥饿加载

至此，优化完成再次重启服务进行第一次请求，发现情况已经好多叻大家可以自己动手尝试改进一下。

本文主要介绍了Spring Cloud的服务第一次请求超时的优化方法首先介绍了问题的背景，并排查了问题造成的原因主要是Ribbon客户端的懒加载；然后分别针对zuul网关和服务之间调用的Ribbon客户端进行配置，使其启动时便加载Ribbon客户端的相关上下文信息最后想说的是，http调用毕竟还是性能远低于RPC。?

订阅最新消息关注公众号，加入我的星球