首页 > 解决方案 > Hystrix 即服务

问题描述

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

因此,另一种选择可能是将 Hystrix 作为专用服务,驻留在执行出站服务调用的应用程序和接收入站调用的应用程序之间。这样一来,所有现有应用程序将几乎保持原样,Hystrix 层将负责 URI 转换/路由以及断路逻辑。

显然,缺点是在您的生态系统中维护另一个应用程序,当您的应用程序之间引入新端点时,它应该始终保持最新。然而,这是我愿意接受的。

有没有人实施过这样的解决方案?这甚至可行吗?如果没有,将 Hystrix 用作 API 网关的一部分是否有意义?

免责声明:我搜索了类似的问题,但找不到类似的东西。

标签: routingmicroserviceshystrixapi-gateway

解决方案


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

在这种情况下,您将有误报,在实际不应该跳闸的情况下跳闸电路。同时,假设服务再次活跃起来,“Hysterix 即服务”将不得不以某种方式让上游服务知道响应可能可用。综上所述,如果它是不受物理网络影响的库或边车似乎更好。


推荐阅读