java – Hystrix命令的预期粒度？

2023年3月10日 211次阅读

我只是阅读了
Hystrix docs/wiki并且仍然缺少基本层面的东西：HystrixCommand impl的预期粒度级别是多少？

例如,假设我有一个DAO对象来处理某些数据库实体的CRUD操作,例如,一个小部件：

class Widget {
    Long id
    Long typeId
    Long version
    String name
    Boolean isAlive
}

interface WidgetDao {
    Widget insertWidget(Long typeId, String name, Boolean isAlive)

    List<Widget> getAllWidgets()

    Widget getWidgetById(Long id)

    void updateWidget(Widget widget)

    void deleteWidget(Widget widget)
}

现在,如果此DAO连接的数据库发生故障,则所有DAO方法都将失败.但我认为DB也可能在某些事务或维护模式中被绑定,其中允许读取,但不允许写入.在该边缘情况下,读取将成功(getX(…)方法),但所有其他方法将失败并使用SqlExceptions.

所以我问：我应该在这里使用的粒度级别是多少？或者：

>每个DAO方法都有一个HystrixCommand impl,看到在某些情况下命令可以成功运行,而在其他情况下,它们可能会失败;要么
>一个HystrixCommand以某种方式融入了DAO类,涵盖了所有DAO方法(如果一个命令失败,那么整个DAO“会降低”.)？

我认为前者代表了更灵活的工程,但作为图书馆的消费者,我引入了更多的代码.思考？想法？

最佳答案 我的想法是粒度水平对解释非常开放,但我认为这一切都归结为容错/恢复和微调.我会考虑以下几点：

>你的失败点是什么？你如何从中恢复？你能恢复吗？

你提到过：

I suppose it is also possible for the DB to be tied up in some transaction or maintenance mode, where say, reads are permitted, but not writes

如果是这种情况,也许围绕这个设计你的Hystrix命令是有意义的.您可以尝试更通用的“读取窗口小部件”命令和“写入窗口小部件”命令.

假设您处于读取正常工作且写入不正常的情况下,您可以维护读取并断开写入命令的电路,从而可能在此过程中为您节省一些数据库连接.你可以通过增加粒度和每个DAO方法有一个命令来做同样的事情,但我不确定这真的会给你带来什么.

>您是否需要/想要精细调整您的应用程序？

Hystrix为thread pools和metrics提供了一些非常好的配置,可以根据每个命令进行调整.将这些配置为一个,按读取和写入分组,或者您是否希望通过每个DAO方法进行更多有限控制/报告是否有意义？

总的来说,我认为这取决于具体情况,我不认为Hystrix是在考虑任何特定级别的粒度的情况下创建的.根据我的经验(通过Hystrix命令使用REST API),我倾向于采用第一种方法,并倾向于粒度.当然,我们以这种方式生成更多代码,但这些库的消费者(在我们的例子中)很少需要处理它,因为他们只使用最终调用这些Hystrix命令的接口,我们可以利用该线程汇集/后备选项.这可以非常方便,因为使用REST API,只有一个端点启动失败并不罕见,因此我们可以快速失败.

当然,你的用例与我的有点不同,但我会考虑容错/恢复并从那里开始.

点赞