Hystrix即服务

Question

根据在线上的示例，Hystrix Circuit Breaker应该用作出站服务调用之上的包装库。 从本质上讲，这意味着需要调整代码并为所有现有项目注入依赖项。这可能证明是非常昂贵和冒险的。

因此，另一种选择可能是将Hystrix作为一项专用服务，该服务将驻留在执行出站服务呼叫的应用程序和接收入站呼叫的应用程序之间。 这样，所有现有的应用程序都将保持完好无损，并且Hystrix层将负责URI转换/路由以及断路逻辑。

显然，不利之处在于维护您的生态系统中的另一个应用程序，当在您的应用程序之间引入新的端点时，应该始终保持最新状态。但是，这是我愿意忍受的。

有人实施过这样的解决方案吗？那可行吗？ 如果没有，那么将Hystrix用作API网关的一部分有意义吗？

免责声明：我搜索了类似的问题，但找不到相似的地方。

Answer 1

我不知道解决方案，但是我倾向于这是一个坏主意。服务级别的抽象层意味着Hystrix本身将是服务依赖项，因此您不能保证Hystrix失败时实际上是下游服务失败。

在那种情况下，您将有假阴性，实际上不应该使电路跳闸。同时，假设该服务将再次启用，“ Hysterix即服务”将必须以某种方式让上游服务知道响应可用。综上所述，如果它是不受物理网络影响的图书馆或杂物房，那似乎更好。