4

我刚刚阅读了Hystrix 文档/wiki，但仍然在基本层面上遗漏了一些东西：impl的预期粒度级别是什么？HystrixCommand

例如，假设我有一个 DAO 对象来处理某些 DB 实体的 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(...)方法），但所有其他的都会因SqlExceptions 而失败。

所以我问：我应该在这里使用的预期粒度级别是多少？任何一个：

  1. 每个DAO 方法都有一个HystrixCommandimpl ，看到在某些情况下命令可以成功运行，而在其他情况下，它们可能会失败；或者
  2. 一个HystrixCommand以某种方式融入 DAO 类，跨越所有DAO 方法（如果一个命令失败，则 DAO 作为一个整体“下降”。）？

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

4

1 回答 1

2

我的想法是粒度级别很容易解释，但我认为这一切都归结为容错/恢复和微调。我会考虑以下几点：

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

你曾提到：

我想数据库也有可能在某些事务或维护模式下被捆绑，比如允许读取，但不允许写入

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

假设您处于读取正常而写入不正常的情况，您可以维护读取并中断写入命令的电路，从而可能在此过程中为您节省一些数据库连接。您可以通过增加粒度并为每个 DAO 方法使用一个命令来做到这一点，但我不确定这是否真的能为您带来任何好处。

  1. 您需要/想要微调您的应用程序吗？

Hystrix 为线程池和指标提供了一些非常好的配置，可以根据每个命令进行调整。将它们配置为一个是否有意义，按读取和写入分组，还是您想要对每个 DAO 方法进行更有限的控制/报告？

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

当然，您的用例与我的用例有些不同，但我会研究容错/恢复并从那里开始。

于 2015-08-10T20:29:43.213 回答