描述：对接方请求我方接口，阶段性 报 timeout  conntion  链接异常

我方：阿里云 k8s 容器化部署

排查：

第一次因为istio节点数据不够，2021-11

1、查看nginx日志，发现 upstream timeout ，问 运维 nginx 转发到了 某一个 istio 上
2、随后 在 nginx 所在服务器 telnet  istio 所在ip，发现 没有反应

3、看 istio 监控，发现流量较高，但不能确定 是 istio 的压力大造成的

4、nginx 转发 配置了 2个 istio ，但是 总共有 11个 istio，整个集群有11个node
5、增加 nginx 转发 的 istio 个数，增加到 4个，发现我方接口趋于正常，观察一夜再说

6、第二天，对方反应 仍然有 2个 timeout，整体少了许多

7、扩展 服务规格 ，由 4c16g 升到 8g32g，待观察 是否还有问题

8、准备安装 istio 一套完整的监控，可以查看istio 的整体情况，到时候知道 istio 的峰值

9、扩充完 istio-ingressgateway ，我方接口响应时间恢复正常

第二次 我方接口夜间高峰时段响应超过30s, 系统告警

1、查看pod cpu 内存 正常，查看数据量近2个月增加了30%

2、增加  istio-ingressgateway 数量，增加一倍，观察一夜再说

3、情况没有改善，证明瓶颈不在 istio

4、增加pod tomcat 线程数，之前是默认值，250吧应该是，改成500，观察一夜

5、第二天无告警，笑的就像吃了蜜蜂屎，整个集群每秒并发最高 1万 ，525个pod

6、又过了几天，告警出现，悲催，看到jvm监控运行线程15，由此想到，数据源线程默认是15吧

7、增加最大线程数   Hikari-pool  50

8、
观察监控，静待佳音，优化之路，任重而道远，永无止境

待后续继续完善该文。。。