step1: 前端 debug 时查看到了504的相应-----（创造问题）
问题剖析nginx访问涌现504 Gateway Time-out，一样平常是由于程序实行韶光过长导致相应超时，例如程序须要实行60秒，而nginx最大相应等待韶光为30秒，这样就会涌现超时。
step2：查看nginx log==> access.log <==10.7.0.13 - - [15/May/2020:16:42:19 +0800] 10.7.00.13:9301 60.001 60.001 ars-beta.test_webcn-la.com POST /api/gc/membership/tier/getMembershipTierByTestHTTP/1.1 "504" 705 "-" "-" "Apache-HttpClient/4.5.3 (Java/1.8.0_144)"可以看到nginx也是504的状态，于是可以查看后端对应的做事是10.7.00.13:9301可以利用curl 来验证一下做事是否正常：curl -I http://localhost:9301/test.html
step3：查看9301端口状态：
wc -l 查看后大概有117个旁边的连接，平时只有以下这样的情形
step4：结合业务查看membership.controller 的access.log(本日志记录了所有与本做事交互的要求处理), 查看调用要求的全体过程。
有两个惊人创造：第一个是红框里面的ip, 第二个是红框里面确当前要求线程名称
step5: 第一个红框的ip 居然是我自己的ip, 这下子问题定位了，由于我本地有在要求membership 做事，并且是python开拓的监控做事是否正常的运用所发出的要求。
step6: 结论为：由于我本机在每五分钟（从上面的要求日志间隔可以窥伺到）要求一次membership 做事的接口，用于保障beta环境的可用性验证，终极由于要求的membership 做事连接一贯不能开释导致了membership 做事僵去世掉。查看9301端口状态时，存在这两个状态，解释如下：
step7: 办理方案
重新重启了做事就规复了，不过还创造了mq 地址变更但代码配置里面未变更的问题并让开发修复，算是意外的收成。
