由于此次系统研发全流程都很严格，需要多个正规第三方的测试证书，安全方面的，性能方面的，等等，疲于应对。
java 开发的，系统设计是3000QPS, 系统研发完成后，准备了压测环境，自己压测轻松应对，QPS达到3500，距离第三方约定压测时间前一天，突然压测环境 QPS降到1500，集中全体之力解决。
我组织了java工程师，将应用包部署到其他服务器，使用 jmeter 单独调用，直接测试，QPS可以达到3500多，证明问题不是代码的。
通知运维部署工程师，可能是链路出了问题。
单独购买一台32C64G的服务器，作为 jmeter 服务器。 请求经过 SLB 到达 nginx 服务器 ，转发到 K8s 到 ingress - istio - pod 链路确实很长，每个节点都有可能。
先排查 SLB 发现 百兆 带宽 并没有占满， 把请求方 jmeter 带宽 也调高，调到了 800兆，再看被请求方的 SLB ,没问题的。说明不是 SLB 已经带宽的问题。
在排查 nginx ,发现nginx 日志 ，显示 k8s 有时候无响应。
排查 pod 为什么无响应，下掉了 k8s 的边车，还是排查不到。
增加 nginx的数量，开始是一台，增加到3台，发现QPS达到了2000多，稍微增加了点儿。
至此就迷茫了，很多时间排查各种疑难杂症就是这样的，发现两边都有问题，到底是哪个问题呢，其实这就是离真相越来越近啦。
于是又请了其他云计算工程师来排查，刚才提到 nginx 增加到3台，他在排查 nginx 配置的时候，顺便问了 k8s 在哪台，部署运维工程师说也在这台，一下子恍然大悟，说：是不是流量双倍导致的。
请求先到达 nginx , 然后 转发到 k8s , 刚好在同一台服务器，所以这台服务器 接收到了双倍的流量请求，后来经过调整，确实是这个问题。
生产奇奇怪怪的问题，真正解决的时候，往往都是不起眼的问题。 真理就是：按照规矩来，就能省很多事儿，有时候系统设计技术方案等，最普通的就是性价比最高的。不要怕麻烦，现在省事儿，将来填坑。
