这是一个创建于 1003 天前的主题，其中的信息可能已经有所发展或是发生改变。
服务架构 nginx + spring cloud + redis + mysql
nginx (4 vCPU 8 GiB) 
网关 1 (4 vCPU 8 GiB) 
网关 2 (4 vCPU 8 GiB) 
网关 3 (8 vCPU 16 GiB) 
上述服务器除了 nginx 是 20mb 带宽其他都是 1mb 带宽走的阿里云内网
其他 cloud 服务，负载均正常，没有出现错误日志。
数据库使用的是阿里云的 rds 8 核 mysql 5.7
redis 内存占用 800mb
自己压力测试结果
1 、直接连接网关进行接口测试 3000 并发时会出现接口无法响应的情况
2 、从 nginx 进行均衡负载后在 1000 并发时就会出现 nginx 返回 502 的情况 错误日志报错 no live upstreams while connecting to upstream
下面是压力测试接口，单次请求详情，也是 nginx 出现 502 时大量用户请求的接口之一。
Load time:1052 Connect Time:932 Latency:1042 Size in bytes:38847 Sent bytes:260 Headers size in bytes:173 Body size in bytes:38674 Sample Count:1 Error Count:0 Data type ("text"|"bin"|""):text Response code:200 Response message:OK HTTPSampleResult fields: ContentType: application/json DataEncoding: null 接口数据是做了 redis 缓存的。
尝试过的配置，
修改服务器内核配置 /etc/sysctl.conf net.ipv4.tcp_max_tw_buckets = 262144 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_synack_retries = 2 net.ipv4.tcp_max_orphans = 262144 net.ipv4.tcp_max_syn_backlog = 262144 net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_syn_retries = 1 net.ipv4.tcp_slow_start_after_idle = 0 还有一些配置 nginx 的 max_fails 重试次数以及配置 keepalive_timeout 超时时间等，都没有改善这个问题。
出现 502 后，服务并没有崩溃，高峰过了后一会儿就自动恢复正常了。
请问大佬们，出现这种情况都是怎么解决的呢？
 | 1 57L49t45Jo9IJvge 2023-01-12 11:25:54 +08:00 3000 并发 gateway 几个副本啊 显然 不够用 瓶颈根本不在 ng |
 | 2 seers 2023-01-12 11:46:38 +08:00 via Android 检查 Nginx 配置，是不是限制了 upstream 连接数 |
 | 3 daye 2023-01-12 12:02:26 +08:00 瓶颈大概率不是 nginx ，而是 gateway 网关层或业务接口 |
 | 4 perfectlife 2023-01-12 12:26:10 +08:00 via Android 这不是后端响应超时嘛，单看系统监控没啥用，你还得看下 jvm ，网关 3 大概率内存爆了 |
| 5 daye 2023-01-1212:30:10 +08:00 no live upstreams 有可能是因为 nginx 负载均衡转发服务的请求连续报错或者拒绝服务，然后被 nginx 标记为不可用接着会失败重试其他节点，如果全部负载均衡节点都被标记，则直接返回 502 |
| 6 daye 2023-01-12 12:34:40 +08:00 你可以写个简单的后端接口，不做任何处理，接到请求直接返回响应，再对该接口进行压测，看同样并发会不会出现 502 |
| 7 daye 2023-01-12 12:35:18 +08:00 如果没有 502 ，则瓶颈不在 nginx |
| 8 daye 2023-01-12 12:37:24 +08:00 如果还有 502 的话，再缩减范围，在网关层就直接响应返回，再压测试试 |
 | 9 sujin190 2023-01-12 13:51:59 +08:00 3000 并发已经很高了，200-400ms 延时，每秒 qps 过万了吧，502 估计就是 #5 楼说的问题，网关无响应被标记为不可用节点了，3000 并发已经是很高的值了，每个请求都要查询数据库的话，想不超时估计需要各种优化了 |
 | 10 BenchWidth OP @perfectlife 网关 3 内存没有爆，只是阿里云没有展示出来，服务都是正常的 @daye 经过了一系列排查暂时定位在了 nacos 的服务发现上，nacos 使用的版本是 1.3 性能不高，并且 nacos 没有做集群，在查询一些列文章后，简单总结了一下大概的意思是。1.*的 nacos 并发率不高，2.*的 nacos 有 10 倍的性能提升。现在正在尝试升级 nacos 看看是否能够解决问题。 @sujin190 qps 最高有在 2w 多，由于业务原因，经常会出现短时间内并发数剧增的情况。 @seers nginx 没有限制 upstream 的连接数 |
| 11 sujin190 2023-01-13 13:57:50 +08:00 @BenchWidth #10 没懂 nacos 还能影响这？也不是每个请求都需要请求 nacos 吧，那 nacos 应该和并发无关才对 如果有经常会出现短时间内并发数剧增的情况，建议限流，服务有最佳处理延时和 qps ，限流排队要比直接打到服务上效率要高得多，可以测测看，一般一个节点给 64-256 并发应该就最佳了，而且入股是短时限流排队更有利于削峰吧 |
Select Language