Zuul的并发性能优化
服务：zuul网关服务，erreka-client服务（10个实例）
一. 笔记本压测和linux服务器压测的性能差距
刚开始用zuul代理erreka-client的接口/test/java-user，此接口是裸接口，用ab压测，tps才是300多，来回压，各种压都上不去，怀疑是我部署的有问题，各种百度优化了许多参数，均无效果，看网上介绍zuul的tps都能上万，难道我部署了假zuul，开始怀疑我的笔记本配置差，于是验证了一把，在linux上装了ab压测工具，结果tps能到3万，真实出乎意料啊！
二．压测并发
于是压测并发，将裸接口睡眠1s钟，结果tps不到200，这个性能我接受不了啊！
尝试一：直接压测裸接口
直接压测裸接口，也是不到200的tps，难道是什么参数的限制吗，关键是这个200，于是把zuul上暴露的参数，修改了个遍，只要与connection和thread有关的参数都调了一遍，测了几十把，仍无效果。
尝试二：把内置web容器tomcat换成undertow
压测zuul网关，结果没什么效果啊
尝试三：将eureka-client的实例数从10变成1，2，4，8测试性能
Eureka-client为1时，tps时40多，这性能损失严重啊，裸接口都有190多，zuul真心垃圾啊。
Eureka-client为2时，tps时80多，部署多个实例还是有效果的
Eureka-client为4时，tps时180多。
Eureka-client为8时，tps时180多，咋又是200的限制。
三．通过jvisiuml和jconsole监控线程排查问题
下面这张图显示http-nio-*线程会创建200个，这个是tomcat执行线程。
但是，这个是每个eureka-client实例tps不能突破200的原因
于是，将zuul这个线程数调整到1000,看下图，说明配置成功，但是zuul的tps依旧不能突破200，肯定是其他影响的
于是通过jvisualvm查看这1000个执行线程状态，发现并没有满负荷运行，阻塞时间较长
于是通过jstack查看这1000个线程执行的代码栈，1000个线程9000多阻塞，估计是被锁住了，于是查看这部分代码，发现是有个http的连接池，池中没有可用连接就会阻塞，直到池中有连接。那池中的连接数是多少呢，怎么设置的呢，光看代码是没有用的，需要跟踪代码运行情况，但是服务跑在linux上，怎么debug呢，在这里不得不说eclipse的强大之处，远程debug。
于是远程debug代码，看这部分的逻辑。但是spring-cloud的代码进不去，于是将源码拔下来，debug发现了问题，下面两个参数在启动的时候会被初始化，这个我设置成1000和10000，也是设置成功的，为啥还是不行，于是继续debug，发现运行的时候，池中的连接数又是50，尼玛，这哪来的?
- zuul.host.max-per-route-connections=20
- zuul.host.max-total-connections=200
于是又多次debug，发现这个池会被初始化两次，第一次是在启动的时候，用的上面两个参数，第二次是在请求的时候，用的下面两个参数
- ribbon.MaxConnectionsPerHost=50
- ribbon.MaxTotalConnections=200
这个… 不就和我测试的结果一致吗，单个实例通过代理只能跑40多，多个实例最多不到200，欣喜若狂，问题解决。