Question

我刚刚阅读了Hystrix docs/wiki，但仍然遗漏了一些基本问题： HystrixCommand impl的预期粒度级别是什么？

例如，假设我有一个DAO对象来处理某个数据库实体的CRUD操作，例如Widget：

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方法都将失败。但我假设也可能在某些事务或维护模式中绑定数据库，其中允许读取，但不允许读取。在该边缘情况下，读取将成功（getX(...)方法），但所有其他方法将失败并显示SqlException。

所以我问：我应该在这里使用的粒度级别是什么？要么：

每个 DAO方法的一个HystrixCommand impl，看到在某些情况下命令可以成功运行，而在其他情况下，它们可能会失败;或
一个HystrixCommand以某种方式融入DAO类，跨越所有 DAO方法（如果一个命令失败，那么整个DAO＆＃34;下降＆＃34;。）？

我认为前者代表了更灵活的工程，但作为图书馆的消费者向我介绍了更多的代码。思考？想法？

Answer 1

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

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

你提到过：

我认为DB也可能在某些事务或维护模式下被绑定，例如，允许读取，但不允许写入

如果是这种情况，也许围绕这个设计你的Hystrix命令是有意义的。你可以试试一个更通用的＆＃34;读取小部件＆＃34;命令和＆＃34;写小部件＆＃34;命令。

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

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

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

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

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

Hystrix命令的预期粒度？

1 个答案: