问题现象：
一个客户的生产环境中，由于灾备切换，将原有环境切换到灾备环境后出现了问题，在通过走nginx转发链路触发保存pdf的交易过程，会存在2分钟以上的等待时间，但是直接访问后端服务器地址，不会有耗时的问题，但是目前由于网络限制，业务无法直接访问服务机器，只有运维可以在内网直接操作验证，影响业务交易；
问题分析：
- 首先通过问题的现象分析，通过直接访问后端服务的情况可以正常执行，但是通过nginx跳转到服务的情况无法成功，所以问题一定是与访问链路因素有关，但具体影响在什么地方，需要我们通过细节进行分析；
异常链路表示2.目前对于问题链路中，需要分析的点有两个，一个是nginx是否存在转发过程中的异常，另一个是服务本身自己存在异常，在生产环境中，无法根据日志或者debug进行定位的前提下，我们这里提供一个工具，在linux系统层面可以使用strace来跟踪系统调用，在java应用层可以用jstack或者arthas监控缓慢点；
3.首先通过strace对nginx进行系统调用的跟踪，由于nginx是多进程服务，需要找出每个进程ID 命令如： ps -ef | grep nginx 找到nginx worker进程 ，然后每个进程都进行strace ，命令如： strace -v -tt -T -p 每个nginx进程ID > 进程ID.log 2>&1 ，在进行交易操作，根据获得的跟踪系统系统调用分析如下：
ng收到浏览器请求
ng转发请求到业务
ng转发的业务socket信息处理进程在收到浏览器请求调用recvfrom（读与浏览器套接字的请求信息）到转发给服务调用writev（写与服务套接字的转发请求信息）的过程在nginx中几乎没有时间的损耗；所以nginx的怀疑点解除；
4.开始分析应用服务的阻塞点，对于一个交易存在2分钟的耗时，一定是在某个慢调用上有等待操作，所以对于通过tomcat部署的java程序，自然会想到使用jstack去抓下线程的方法栈调用链，来分析阻塞的方法是什么，但是由于客户现场环境问题和用户问题，运维没能正确使用jstack来抓到快照，反馈说无法执行，这就浪费了一个很大的工具优势，只能想其他办法；
5.在分析应用是否慢之前，还考虑对nginx到应用的网络节点中是否有慢的地方进行了分析，需要证明请求到达应用机器后，返回这段时间的损耗都是消耗在业务应用机器中，使用了tcpdump进行抓包分析，工具命令： tcpdump -i 网卡名称 port 8080 -w 8080.pcap ；
访问正常机器的抓包
访问异常机器的抓包经过对两个不同网络链路分析，正常直接访问服务的44机器，耗时在1秒多正常返回，经过nginx转发到45的访问，耗时确实2分钟左右，所以证明就是在业务机器中存在的时间损耗；
6.由于客户运维不能正常使用jstack抓取快照，只能还使用strace进行跟踪，因为对于此类异常，如果在慢调用中存在时间损耗，通常多是和系统调用资源访问条件不满足时等待有关，所以通过strace应该可以发现一些线索，所以工具命令执行 strace -v -tt -T -F -p tomcat进程ID > 进程ID.log 2>& ；
tomcat进行strace跟踪比对经过抓取tomcat中线程的系统调用，将44和45两台机器的访问链路进行比对，发现一个奇怪的问题，直接访问44的业务应用有反向请求45自己服务的情况，应该是业务层有自身发起交易联动的，但是45机器的业务却是去访问了128（是ngin机器地址），所以问题的差别就是，45存在联动访问请求nginx现象，可能这过程有时间损耗，但是具体不明确为什么会请求128nginx而不去请求45，所以在测试环境进行验证进行抓包如下：
测试环境验证业务方向请求ng的抓包发现在测试环境也存在这个现象，通过nginx转发的链路，确实会有从业务服务反向请求到nginx再回到业务的路由链路，但是这个过程在生产就从来没有抓到过这个反向请求出来，所以断定，可能是生产环境中，45机器到nginx的网络策略存在问题，只有ng->45的，没有45->ng的；
7.目前问题就比较清楚了，怎么验证45->ng的网络策略存在问题呢？这就比较简答了，通过curl命令，去执行那个访问ng的get请求，看结果是不是也存在阻塞就可以了，客户通过验证后，确实存在不通的现象，所以问题基本明确，就是生产环境的网络策略导致交易链路中的一个环节不通，所以阻塞到一个网络超时就中断了；
8.以上问题分析，我们使用到了linux的strace跟踪工具(早期的aix或unix是truss)，以及网络抓包工具tcpdump，具体这些工具的使用和抓取信息的详细说明，后续我还可以针对这些数据的如何查看进行分享；
