Spring Cloud Zuul线程、信号量隔离性能测试
我们在使用Zuul作为网关的时候，Zuul内部集成了Hystrix实现熔断保护,然而Hystrix是提供了信号量隔离与线程隔离两种方式，那么我们Zuul网关服务，需要使用哪种隔离策略更好呢？我们在使用Zuul的时候，Zuul默认使用了信号量作为隔离方式，那为什么默认用了信号量呢，本节我们就针对这两种隔离策略来做一下性能测试！
性能测试目的
验证Zuul使用哪一种隔离策略更优，Zuul网关作为流量入口，理应具备良好的响应以及较高的吞吐量，所以为了验证线程、信号量隔离哪一种更适合Zuul网关，本次我们就针对这两种策略做针对实验。根据实验数据在结合自身应用做各自的选择！
硬件/软件配置条件
- 硬件配置为2核4线程
- Zuul网关配置的Hystrix timer线程池数量为4
- Zuul网关配置的Hystrix default线程池coreSize:2、maximumSize:5、maxQueueSize:1、queueSizeRejectionThreshold:1 ,maxQueueSize与queueSizeRejectionThreshold增大会明显降低失败率
- Zuul下游服务耗时100ms
- 性能测试软件为Jmeter-5.4.1
- Jmeter线程组配置:线程数200、Ramp-Up时间(秒) 1、循环次数60，该参数配置为基于硬件的配置，满峰值测试性能
信号量隔离性能测试
信号量隔离应用性能指标及请求信息占比汇总
左图为应用性能指标，我们关注下Apdex这个指标(满意度)，0.258的满意度，说明很低啊，说明我们的请求响应时间绝大多数都是大于500ms的，我们在看看右图，成功与失败的占比约为9:1，说明在结果方面还不错，只是时间长了一点
信号量隔离汇总报告与聚合报告的数据分析
针对数据分析这张图，我们大致解释下
- Samples=12000(总请求量=线程数200 * 循环次数60)
- FAIL失败的数量
- Average 平均响应时间
- Min、Max 最小 最大的响应时间
- 90th pct 百分之90的用户请求响应时间小于这个值
- Transaction=88.10(吞吐量=总请求数Samples/总耗时时间),这个地方我们结合下面的响应时间图大概算下是不是这么多，总耗时=14:36:09(结束时间) - 14:33:55(开始时间) = 134秒，12000/134 = 89.55，大致差不多
信号量隔离响应时间
我们结合这张随着时间点的响应时间图不难看出，我们的信号量整体的响应都比较平稳，信号量模式为共用请求线程，最终会依赖容器的线程池管理，随着请求的增多，多余的请求会被放到容器队列等待执行，所以看起来比较平稳
线程隔离性能测试
线程隔离应用性能指标及请求信息占比汇总
因为我们配置的Hystrix默认线程池为coreSize:2、maximumSize:5、maxQueueSize:1、queueSizeRejectionThreshold:1，最大的队列长度为1，拒绝执行的限制条件为1,有兴趣的同学可以把maxQueueSize及queueSizeRejectionThreshold参数都调整尽可能大一点，那么相对的实验数据失败率就会明显降低,但是在峰值环境下响应时间会更长!
我们在对比下0.042的满意度，约等于93%的失败率,可以说是馋不忍睹，相当于Zuul网关不可用
线程隔离汇总报告与聚合报告的数据分析
针对线程隔离的数据分析，失败率达到93%，响应时间、吞吐量都率高于信号量，这个也不难看出，大量的数据都失败了，那么相应的响应时间、吞吐量就要高一点
线程隔离响应时间
我们大概分析下这个分布图，刚开始请求会被放到Hystrix的线程池内部执行，此时线程够用，所以响应时间也相对要快一些，但是随着请求数越来越多，相应的Hystrix内部的线程也越来越多在处于排队，整个响应时间呈现断崖式波动，最终也会导致越来越多的请求无法执行，呈现出失败率成倍增长，导致最终Zuul网关不可用！
性能测试结论
- Zuul网关层面，信号量隔离策略为首选(依赖网络框架的超时机制)
- 应用服务层面，线程隔离策略为首选(业务方法中不依赖网络请求或者数据库请求这样的IO，信号量就没有办法控制超时)
