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