亿级流量电商详情页系统实战-50.生产环境中的hystrix分布式系统的工程运维经验总结

• 如果发现了严重的依赖调用延时，先不用急着去修改配置，如果一个command被限流了，可能本来就应该限流

• 在netflix早期的时候，经常会有人在发现短路器因为访问延时发生的时候，去热修改一些值遏制，比如线程池大小，队列大小，超时时长，等等，给更多的资源，但是这其实是不对的

• 如果我们之前对系统进行了良好的配置，然后现在在高峰期，系统在进行线程池reject，超时，短路，那么此时我们应该集中精力去看底层根本的原因，而不是调整配置

• 为什么在高峰期，一个10个线程的线程池，搞不定这些流量呢？？？代码写的太烂了，异步，更好的算法

• 千万不要急于给你的依赖调用过多的资源，比如线程池大小，队列大小，超时时长，信号量容量，等等
  举个例子，在正常情况下，可能只会用到其中200~300个线程去访问那个后端服务。但是如果再高峰期出现了访问延时，可能导致1000个线程全部被调用去访问那个后端服务。
  如果因为你的代码等问题导致访问延时，即使有20个线程可能还是会导致线程池资源被占满，此时就有2000个线程去访问后端服务，可能对后端服务就是一场灾难。
  这就是断路器的作用了，如果我们把后端服务打死了，或者产生了大量的压力，有大量的timeout和reject，那么就自动短路，一段时间后，等流量洪峰过去了，再重启访问

• 简单来说，让系统自己去限流，短路，超时，以及reject，直到系统重新变得正常了。就是不要随便乱改资源配置，不要随便乱增加线程池大小，等待队列大小，异常情况是正常的