本文根据近期大家联调过程中出现的一些问题，做了一些梳理。其内容涉及人力云、协同云、财务云、云平台等多个领域。大家在奋战的过程中相互帮助，在掉坑与爬坑中不断进步。经过不断磨合，研发调试上线过程慢慢顺畅起来。本期梳理出趟坑36计中的8计，后续会不断梳理输出其他部分给大家，一起进步，防止遇到类似问题掉坑翻车。
1、应用访问时出现504错误
发现问题
应用不能正常访问，在浏览器中提示504错误，查看容器内部僵死。
根因分析
应用通过域名不能正确访问，显示504错误，或者是长时间卡住不动。
通过控制台进入到容器里面，通过
curl localhost:8080
命令也不能访问，证明应用自身已死掉。
应用日志没明显异常信息，通过jstack打出堆栈信息，发现大量的logback写日志线程等待。
网上也有同学遇到多线程死锁问题，供参阅：
https://blog.csdn.net/shipengyy/article/details/50184709
解决办法
将应用代码中，logback配置文件里，向console打日志的部分注释掉。
2、应用联调测试环境时好时坏
发现问题
应用联调测试过程中，调用时好时坏，环境一天可用时间难以保证。
根因分析
测试某个功能，一会好用，一会不好用了。此时，某些同学修改了代码，进行了服务的重启。导致重启的过程中，服务调用失败。
由于服务调用链路比较多而且繁杂，只要其中一个环节不可用，就会导致整个功能测试中断，让大家保持步调一致，以提升环境稳定性。
解决办法
约定大家的测试环境更新时间，更新（代码、修改配置、数据库）的时间为12:00-13:00、17:30-18:30。
3、应用已僵死，但状态仍显示健康
发现问题
应用的健康状态显示正常，但应用实际已僵死，不能准确感知应用状态
根因分析
由于默认是基于端口进行健康检查，所以显示的状态是端口存活状态，不能真实的反馈出来应用的健康度。
如果配置了http方式的检查url，可以根据检查mysql、redis、核心服务等方式，确定服务的健康状况。
解决办法
增加http的健康检查url，如：/healthcheck，并编写详细的检查逻辑。
4、微服务调用不通
发现问题
微服务调用时，发现调用接口不通。
根因分析
线上的测试环境，服务调用失败，报网络错误。
一般是本地的服务注册到线上了，或者是停掉的服务，没能及时的从服务注册中心注销掉，导致服务消费方，调用到了坏的服务提供方。
解决办法
将本地IDE中启动的微服务，环境改对，防止线上服务调用到本地笔记本上的情况（或拔掉网线）。
其他情况，也可以联系运维同学，帮大家从后台杀掉野服务或状态不同步的服务。
5、应用重启升级时，异常实例还存在
发现问题
将应用重启或升级时，健康状态为异常容器实例仍然存在。
根因分析
应用升级的过程中，由于线程死锁或等待状态，导致发送了kill信号后，容器不能及时被杀掉。
用户只能等在那，点击销毁实例按钮，也不生效，待优雅退出后，才能完成升级。
导致这个问题的原因主要有两种：
- 大量请求访问，存在大量积压的线程
- 应用本身线程死锁，状态异常
解决办法
平台优化调度器，对于不能优雅退出的应用，增加强杀策略。
6、应用管理详情中的日志不显示或有延迟
发现问题
在应用管理详情页面中，点击日志，发现日志不显示，或者显示有延迟现象
根因分析
在应用详情页面中，通过日志页签查看到的日志不是最新的。
由于目前容器服务巨多，日志输出量巨大，日志收集服务器不能及时处理如此多的海量数据，导致收集的日志写入ES时，有延时。
解决办法
通过“应用日志”和“错误日志”按钮查看实时的日志信息，也可以进入到控制台，通过tail命令查看相应的日志文件。
7、应用发布失败，提示无可用资源
发现问题
应用在构建后进行发布操作，结果失败，显示问题为可用资源为0。
根因分析
应用通过流水线构建成功，最终部署的时候，提示失败。查看资源池剩余资源，发现剩余资源确实不足。
解决办法
向资源池中添加新机器，增加可用的计算资源。
8、服务调用超时，一些环节提前关闭
发现问题
服务调用提示超时，链路上某些环节提前关闭了连接。
根因分析
有些服务，导集团数据时大约需要5分钟，由于某些负载均衡的超时时间是30s，导致某个请求结束后，不能正常返回处理结果。
但是，强烈建议将这些长时间处理的任务，改为异步方式，防止同步调用造成的超时等待。
微服务和Docker容器是一个完美的结合，这种模式可以将封装好的服务，不断的运输到运行环境中。结合DevOps的理念，可以通过流水线，多套环境隔离管理等方式，提升研发的效率。
解决办法
将各负载均衡的超时时间调大，SLB、Nginx、HaProxy、MLB等，目前调整为 Nginx：600s；MLB：180s。
