Hystrix 命令的预期粒度？答案

【问题标题】：Intended granularity of Hystrix commands?Hystrix 命令的预期粒度？
【发布时间】：2015-03-16 20:01:08
【问题描述】：

我刚刚阅读了Hystrix docs/wiki，但在基本层面上仍然缺少一些东西：HystrixCommand impl 的预期粒度级别是多少？

例如，假设我有一个 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。

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

一个HystrixCommand impl 用于每个 DAO 方法，看到在某些情况下命令可以成功运行，而在其他情况下，它们可能会失败；或
一个HystrixCommand 不知何故融入了DAO 类，跨越了所有 DAO 方法（如果一个命令失败，整个DAO 就会“崩溃”。）？

我认为前者代表了更灵活的工程设计，但作为库的使用者，向我介绍了更多代码。想法？想法？

【问题讨论】：

我建议您尝试将命令细化为单个 View（可能是单个逻辑事务）。
谢谢@ElliottFrisch (+1) - 所以听起来你在提倡一种细粒度的方法，每个 JDBC 调用都在自己的命令中？再次感谢！
请@ElliottFrisch - 不要在这里受潮！

标签： java dao fault-tolerance hystrix resiliency

【解决方案1】：

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

您的故障点是什么？您如何从中恢复？你能康复吗？

你提到过：

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

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

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

您是否需要/想要微调您的应用程序？

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

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

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

【讨论】：