# 109. 生产环境中的hystrix分布式系统的工程运维经验总结

# 经验

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

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

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

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

千万不要急于给你的依赖调用过多的资源，比如线程池大小、队列大小、超时时长、信号量容量等等，因为这可能导致我们自己对自己的系统进行 DDOS 攻击（疯狂的大量的访问你的机器，最后给打垮）

举例来说，想象一下，我们现在有 100 台服务器组成的集群，每台机器有 10个线程大小的线程池去访问一个服务，那么我们对那个服务就有 1000个线程资源去访问了

在正常情况下，可能只会用到其中 200~300个线程去访问那个后端服务，但是如果在高峰期出现了访问延时，可能导致 1000 个线程全部被调用去访问那个后端服务，如果我们调整到每台服务器 20 个线程呢？

如果因为你的代码等问题导致访问延时，即使有 20个线程可能还是会导致线程池资源被占满，此时就有 2000个线程去访问后端服务，可能对后端服务就是一场灾难

这就是断路器的作用了，如果我们把后端服务打死了，或者产生了大量的压力，有大量的 timeout 和 reject，那么就自动短路，一段时间后，等流量洪峰过去了，再重启访问

简单来说，让系统自己去限流、短路、超时、以及 reject，直到系统重新变得正常了

最后总结：就是不要随便乱改资源配置，不要随便乱增加线程池大小，等待队列大小，异常情况是正常的

今天打算在 spring cloud 子系统中加上 hystrix-dashboard；通过 yml 自动配置最少参数后，能看见 ui 图了，但是我发现它默认是「一个服务名一个线程池」，意思是所有的接口访问都是一个线程池管理的，然而不加大线程没法让访问不报错。

项目是一个后台定时任务调度项目，调用接口频率高的时候，每秒平均也就 10 来个请求；所以还是不太明白在实际开发中到底要怎么来分这个线程池？