1.启动cloud-provider-hystrix-payment8001

1.1.正常测试

启动Eureka注册中心：cloud-eureka-server7001，cloud-eureka-server7002
启动服务提供者：cloud-provider-hystrix-payment8001
浏览器输入：http://localhost:8001/payment/hystrix/ok/31
返回如下内容：

  1. 线程池：http-nio-8001-exec-9 paymentInfo_OK,id： 31 哈哈哈

浏览器输入：http://localhost:8001/payment/hystrix/timeout/31
返回如下内容，次接口会耗时3秒钟

线程池：http-nio-8001-exec-3 paymentInfo_TimeOut,id： 31 呜呜呜 耗时(秒)3

1.2.JMeter高并发测试

JMeter压测测试
开启Jmeter，来20000个并发压死8001，20000个请求都去访问paymentInfo_TimeOut服务
image.png
image.png
浏览器输入：http://localhost:8001/payment/hystrix/ok/31
浏览器输入：http://localhost:8001/payment/hystrix/timeout/31
发现两个接口没有立刻返回数据而是等待几秒才返回，没有进行Jmeter压测的时候http://localhost:8001/payment/hystrix/ok/31接口会立刻返回数据，为什么会出现这种情况呢？
因为Tomcat的默认的工作线程数被打满了，没有多余的线程来分解压力和处理。

Jmeter压测结论：
上面还是服务提供者8001自己测试，假如此时外部的消费者80也来访问，那消费者只能干等，最终导致消费端80不满意，服务端8001直接被拖死

2.启动cloud-consumer-feign-hystrix-order80

6.1.正常测试

浏览器输入：http://localhost/consumer/payment/hystrix/ok/31
会很快返回结果：

线程池：http-nio-8001-exec-3 paymentInfo_OK,id： 31 哈哈哈

6.2.高并发测试

启动JMeter进行压测，具体参考【JMeter高并发测试】
浏览器输入：http://localhost/consumer/payment/hystrix/ok/31
发现会等待几秒钟才会返回结果，浏览器一直转圈圈
image.png
要么消费端报超时错误
image.png

3.故障现象和导致原因

8001同一层次的其他接口服务被困死，因为tomcat线程里面的工作线程已经被挤占完毕
80此时调用8001，客户端访问响应缓慢，转圈圈
结论：
正因为有上述故障或不佳表现，才有我们的降级/容错/限流等技术诞生