故事背景
最近在一个技术交流群里遇到一个小兄弟请求问题,看着平淡无奇的问题,我建议查看mysql-server连接数是否正常,以及当前是否有活跃的慢连接在操作数据库。经过几次确认之后发现并没有什么异常。最后使用阿里开源的神器arthas。网址https://arthas.aliyun.com/doc/ 在我的指导下,小兄弟查看了占用cpu最高的http线程,并通过arthas的trace命令分析到druid的一处代码特别耗时。基本问题已经定位到了,但是怎么解决问题,不仅仅需要技巧还需要点运气,我建议他去github的druid仓库issue下去搜索有没有类似问题。在输入了关键字”loadClass”之后,果真有人遇到了类似问题,也贴出了解决方案。最终在我的指导下,小兄弟问题得到了解决。作为交换,小兄弟答应我给我写一遍完整的故障流程。于是,故事开始…..以下内容来自这位网友的投稿
项目背景
随着业务的扩展,组内的项目越来越多。经常是一个Tomcat里放好将近15个war包。随之而来的是Tomcat严重的宕机事故。痛定思痛之后决定采用Nginx代理解决问题。在部署方案上从原来的Ha代理转变为Ha代理到Nginx,再由Nginx代理到各个服务。其中将业务相关的应用全部独立部署,基础服务暂时保留在Tomcat中。决定了部署方案之后,在灰度环境做了各种测试。均没有发现问题。各种服务独立部署并确定无误之后,将Ha的代理切到Nginx上。随之而来的是部分Java应用接口响应缓慢。接口响应时间平均1.5秒。
部署方案更换的变化点
1.从原来的Tomcat单个端口转变为了多个端口
2.Ha代理从原来直接代理到6台服务器到目前代理到nginx,nginx再做路由转发。
注意:Ha代理是通过Cookie路由,通过Cookie的标志让登录的用户,在登录期间能够始终访问到一台机器。新的部署方案直接抛弃了这种方式,接口路由全部采用权重。
期待
部署方案的改变是为了让服务更稳定。系统的业务部分都是单节点部署,Nginx采用主备。相比之前Tomcat容器中的多线程,目前的多进程应该具有更好的稳定性和输出能力。
问题的发现和解决1、网络原因?
在业务系统全部切换到Nginx之后,产品经理反映系统缓慢,部分Java系统的业务无法正常进行。
分析:可能是网络问题。
原因:通过F12查看页面的接口和静态资源文件的传输记录。发现很多Js的响应达到了1秒,甚至有的Js脚本的传输花了10秒。但还是比之前慢了很多,但是每晚7点以后网络总是反应较缓慢。对产品经理解释一波之后,已经晚上9点30,大家各回各家。
复盘:真的是网络问题吗?如果是网络问题,那么同机