hystrix带断路器适用于呼叫转移和高TPS情况吗？
我有三个服务A、B和C。A接收来自两个源的调用，并将大多数调用转发给B服务，一些转发给C，并基于URI处理少数调用。在将呼叫转发给B或C之前，A做了一点琐碎的工作。服务A每秒处理的峰值请求约为60个。在60个API调用中，55个被转移到服务B。我们知道服务B的两到三个高频API。请注意，所有调用本质上都是同步的。
我使用的是Spring Boot1.4.1和Spring Cloud Camden.release。根据我在本地Windows机器上使用JMeter的实验，我看到服务能够每秒处理预期的请求。一旦我将服务A作为断路器，并用@HystrixCommand包装高频API调用，我就会发现性能变得比以前更差。hystrix的许多API调用都失败了，并调用了回退。然后，将Execution.Isolation.thread.TimeOutInMilliseconds命令属性值增加到“30000”，并将coreSize线程池属性值增加到“50”，所有调用都通过了。我观察到启用hystrix stuff后，服务A比以前多需要50个线程。随着负载的增加，API执行时间变得更长，从而增加了超时属性值。
疑惑
>
如果将服务A作为断路器，并用hystrix命令将对服务B的高频调用（或所有调用）包装在服务A中，则是好的决定
如果是，根据将来更多的TPS需求，通过hystrix池中的配置手动更改/增加线程数是否不错？如果没有hystrix，情况很简单，因为spring boot会自动处理用于负载的线程池
由于我需要修改timeout属性，现在当服务B停止时，A或hystrix需要几秒钟才能检测到服务B无法访问。使用hystrix停止级联排气或停止服务的真正优势并不多。还推荐hystrix吗？
Netflix建议核心大小默认为10大部分，他们已经使用到25岁，而不是超过25岁。在我的情况下，需要50
共有1个答案
基于配置文档：
通常，您应该使用信号量隔离(semaphore)的唯一时间是当调用量太大（每个实例每秒数百个），以至于单独线程的开销太高；
-
我正在尝试春云和春靴。它使用了Netflix的OSS应用程序，其中有Ribbon和Hystrix。 Ribbon是一个负载均衡器，带有一些功能，其中一个是断路器。
-
提前感谢B·贾根
-
应用程序可以使用Spring Cloud Netflix项目提供的Hystrix断路器将这个启动器包含在项目pom.xml：spring-cloud-starter-hystrix中。Hystrix不依赖于Netflix Discovery Client。@EnableHystrix注释应放置在配置类（通常是主类）上。那么方法可以用@HystrixCommand注释来被断路器保护。有关详细信息，请
-
我在我的spring boot应用程序中使用Hystrix实现断路器，我的代码如下所示： 我看到每次失败时都会调用fallback（）。但3次故障后电路不开。在3次失败之后，我原以为它会直接调用并跳过。但这并没有发生。有人能告诉我我在这里做错了什么吗？ 谢谢,B Jagan 下面是实际代码。我用这个玩得更远了。当我在RegistrationHystrix.RegisterSeller（）方法中直接
-
Hystrix的主要优点之一是它收集关于每个HystrixCommand的一套指标。Hystrix仪表板以有效的方式显示每个断路器的运行状况。 图3. Hystrix仪表板
-
Netflix的创造了一个调用的库Hystrix实现了断路器图案。在微服务架构中，通常有多层服务调用。 图1.微服务图 较低级别的服务中的服务故障可能导致用户级联故障。当对特定服务的呼叫达到一定阈值时（Hystrix中的默认值为5秒内的20次故障），电路打开，不进行通话。在错误和开路的情况下，开发人员可以提供后备。 图2. Hystrix回退防止级联故障 开放式电路会停止级联故障，并允许不必要的或