具有断路器的hystrix是否适用于呼叫转移和高TPS情况？

Question

我有三个服务A，B和C.A接收来自两个来源的呼叫，并将大多数呼叫转发到B服务，一些转发到C，并根据URI处理一些。在转发对B或C的呼叫之前，A做了一些微不足道的工作。服务A处理的每秒峰值请求大约为60.在60个中，55个API调用被转移到服务B.我们知道有两到三个服务B的高频API。请注意，所有呼叫都是同步的。

我正在使用Spring Boot 1.4.1和Spring Cloud Camden.RELEASE。根据我在本地Windows机器上使用JMeter的实验，我看到服务能够处理每秒的预期请求。一旦我将服务A作为断路器并用 @HystrixCommand 包装高频API调用，我看到性能变得比之前更差。许多API调用都被hystrix失败，并且调用了回退。然后，在将 execution.isolation.thread.timeoutInMilliseconds 命令属性值增加到“30000”并将 coreSize 线程池属性值增加到“50”时，所有调用都已通过。我观察到，启用hystrix东西后，服务A比以前需要大约50个线程。随着负载的增加，API执行时间变得更高，因此增加了超时属性值。

想知道

1. 如果将服务A作为断路器并将其包裹起来 用于服务A内的服务B的频率呼叫（或所有呼叫） hystrix命令是很好的决定

2. 如果是，手动更改/增加线程数是不错的 通过基于更多TPS需求的hystrix池中的配置 未来？没有hystrix，情况就像弹簧靴一样简单 自动处理服务负载的线程池

3. 因为我需要修改超时属性，现在当服务B是 停止，A或hystrix需要几秒钟才能检测到服务B. 不可达。使用hystrix停止级联的真正优势 排气或停止服务并不多。仍然是hystrix推荐的？

4. Netflix建议核心大小主要为10默认值，并且它们有 使用到25岁，没有超出。就我而言，需要是50

您的建议在这里会有所帮助，特别是要了解具有断路器的hystrix在我的情况下是否有用，或者我们如何使其有用，或者哪个更适合（任何服务的TPS都很低）。 / p>

Answer 1

基于config doc：

  

通常情况下，您应该使用信号量隔离（SEMAPHORE）的唯一情况是当调用的体积如此之高（每个实例数百个，每个实例）时，单独线程的开销过高;