微服务负载测试出现502 Bad Gateway超时问题求助

一、Zuul网关层面 #

• 检查连接池配置：zuul.host.max-total-connections、zuul.host.max-per-route-connections默认值大概率撑不住1000用户负载，建议调高，比如设zuul.host.max-total-connections=2000、zuul.host.max-per-route-connections=1000。
• 调整超时参数：zuul.host.connect-timeout-millis（连接超时）和zuul.host.socket-timeout-millis（读取超时），如果主服务处理请求慢，就把这两个值拉长，比如设为30000（30秒）。
• 查看Zuul日志，明确是连接池耗尽导致无法建立新连接，还是转发请求时后端无响应触发超时，日志里的错误栈能直接定位问题。

二、Eureka服务发现层面 #

• 确认Eureka Server状态：高负载下看它的CPU、内存使用率，有没有请求堆积，要是Eureka卡了，Zuul拿不到服务实例就会报错。
• 调整主微服务的Eureka续约配置：把eureka.instance.lease-renewal-interval-in-seconds（续约间隔）设为5秒，eureka.instance.lease-expiration-duration-in-seconds（过期时长）设为15秒，避免高负载下Eureka误判主服务下线。
• 缩短Zuul的服务列表刷新间隔：改ribbon.ServerListRefreshInterval=3000（3秒），确保Zuul能及时拿到主服务的最新实例状态。

三、主微服务（Eureka Client）层面 #

• 单独压测主服务：绕开Zuul直接压主服务，看1000用户负载下它能不能稳定跑，有没有线程池耗尽、数据库连接不够、CPU/内存跑满的情况。
• 调整主服务的线程池：比如Tomcat的server.tomcat.max-threads调到200以上，server.tomcat.max-connections根据服务器配置往上提，线程不够会导致请求排队超时。
• 揪出慢请求：用链路追踪或日志找耗时久的接口，看是不是有慢SQL、阻塞的远程调用、同步IO太多，针对性优化。

四、网络与服务器层面 #

• 查网关和主服务之间的网络：高负载下有没有丢包、延迟飙升，用ping、traceroute测链路状况。
• 看服务器资源：Zuul、Eureka、主服务所在机器的CPU、内存、带宽是不是到瓶颈了，CPU持续超80%、内存不足导致GC频繁，都会让服务崩。

内容的提问来源于stack exchange，提问作者user1337934