摘要：
今天产品测试同事在测试平台上测出了一个bug。就是在学习项目中添加一场考试的时候，添加不成功。产品的技术栈是springcloud，在网管gateway中有各个子服务的路由转发，这里是前端跟后端建立的连接，如果gatewaay超时，则会响应给前端504。在微服务中远程调用都是基于ribbon进行http请求调用的，所以在服务消费方添加了如下配置，设置超时时间：ribbon:ReadTimeout:60000ConnectTimeout:60000再次调用就Ok了。当然，服务提供方首先要保证自己提供的接口业务处理时长不能过长。
今天产品测试同事在测试平台上测出了一个bug。就是在学习项目中添加一场考试的时候，添加不成功。
于是我先去查看考试微服务的报错信息，并在本地环境复现，确实存在这样的bug，如下：
因为该接口是提供给另外一个服务调用的，所以初步判断是接口业务逻辑处理时间长导致的超时。
产品的技术栈是springcloud，在网管gateway中有各个子服务的路由转发，这里是前端跟后端建立的连接，如果gatewaay超时，则会响应给前端504。但这里前端响应的是后端提供的错误码。
所以应该是服务消费方出了问题，查看服务消费方的日志，如下：
确实显示的也是请求超时问题。
在微服务中远程调用都是基于ribbon进行http请求调用的，所以在服务消费方添加了如下配置，设置超时时间：
ribbon: ReadTimeout: 60000 ConnectTimeout: 60000
再次调用就Ok了。
当然，服务提供方首先要保证自己提供的接口业务处理时长不能过长。
减少处理时长可以有如下常用方法：
- 如果有多个sql需要执行，想办法整成一个sql，减少跟数据库的交互；
- 对应的sql也需要加上需要的索引，减少sql执行时长；
- 比较耗时的业务逻辑，又不需要响应给服务消费方，可以采用异步io非阻塞的办法，即开始新线程进行处理。