WEB应用

分享一个APISIX网关返回502的典型案例

Jager · 2月25日 · 2022年 · · 1132次已读

最近将自己开发的一个消息推送 API 接入我们新上线的定时拨测系统试了下,发现一天内居然发生了几十次 502!

感觉不太可能,因为对自己写的服务还是比较有信心的,于是通过检索网关流水日志和后端服务日志,发现网关确实记录到了 502 的请求记录,但是后端应用并没有收到请求。

于是检索了一下 APISIX 的错误日志,发现对应请求有如下报错:

xxx upstream prematurely closed connection while reading response header from upstream, client: x.x.x.x

报错的意思还是比较直白的:网关在读取上游响应头部时,上游服务主动关闭了连接。

快速搜了下关键词,发现主要有两种说法:

  • 上游服务对请求头部大小或请求频率存在限制;
  • 网关启用了 keepalived 会话保持导致的问题。

上游服务就是我自己写的,因此直接排除第一个问题,简单想了下就大概清楚了来龙去脉:

APISIX 为了提高性能,默认会打开keepalived特性,预设会话保持时长为 60s,我们在部署网关的时候也保留了这个优化特性,恰好我的上游服务基于 Gunicorn+FastAPI 开发框架,也开启了 keepalived,会话保持默认设置为 5s。

这样就有问题了:网关和上游服务建立连接后 60s 内,新请求会继续复用这个连接,但是上游却在 5s 后主动关闭了连接,因为网关将新请求转发给上游时,才发现连接已经被关闭了,因此就出现了上述报错。

这个问题在 Nginx 等反向代理场景下同样存在,算是一个很典型的 Case,这里解决问题的办法有两个,要么从网关关闭 keepalived 特性,要么后端的 keepalived 时长设置超过 60s,当然我毫无疑问选择了后者。

改完之后就再也没有出现过类似报错了。

恰好接入网关也是我在运维,本打算将 APISIX 这个全局默认 keepalived 缺省给禁用,但考虑到性能问题,还是继续保持了现状。不过这个问题倒是成为了一个值得注意的典型问题,需要同步给业务运维,如果上游服务开启了 keepalived 特性,需要将 keepalived 超时设置在 60s 以上即可。

这个问题能这么快得到解决,多亏了网上很多前辈大牛分享的定位经验,不然可能还得各种抓包分析,比如这篇文章就写到很清楚:Nginx" upstream prematurely closed connection while reading response header from upstream"问题排查 - Hello-YOYO - 博客园 (cnblogs.com)

最后,在定位问题的时候我也和 APISIX 社区反馈了下,为什么在这个 case 中 APISIX 并没有进行重试?社区反馈 APISIX 并不会无脑重试,有条件限制,感兴趣的同学可以拓展阅读一下:

0 条回应
  1. 激光对中仪 2022-4-1 · 9:50

    很受用

  2. 王炜sky 2022-4-15 · 21:13

    你好,如果后端没有设置60s的话,该怎么处理呀

    • avatar
      Jager 2022-5-5 · 18:50

      apisix在upstream里面关闭keepalived试试。