我有三个服务 A、B 和 C。A 接收来自两个源的调用，并将大多数调用转发到 B 服务，一些到 C，并根据 URI 处理一些。在将呼叫转接到 B 或 C 之前，A 做了一些琐碎的工作。服务 A 每秒处理的峰值请求数约为 60。在 60 个 API 调用中，有 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 执行时间变得更长，因此增加了 timeout 属性值。
想知道
如果将服务 A 设为断路器并使用 hystrix 命令将对服务 B 的高频调用（或所有调用）包装在服务 A 中是好的决定
如果是的话，根据未来更多的 TPS 需求，通过 hystrix 池中的配置手动更改/增加线程数是否不错？如果没有 hystrix，情况很简单，因为 spring boot 会自动处理线程池以提供负载
由于我需要修改 timeout 属性，现在当服务 B 停止时，A 或 hystrix 需要几秒钟才能检测到服务 B 无法访问。使用 hystrix 停止级联排气或停止服务的真正优势并不大。还是推荐hystrix？
Netflix 建议核心大小默认为 10，并且他们一直使用到 25，而不是超过。在我的情况下，需要是 50
您的建议在这里会有所帮助，特别是要知道带断路器的 hystrix 是否对我有用，或者我们如何使它有用，或者它在哪里更合适（任何服务的 TPS 都很低）。