我刚刚阅读了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隐含含义,可以看到在某些情况下命令可以成功运行,而在另一些情况下则可能失败;或
  • 某种HystrixCommand以某种方式被烘焙到DAO类中,跨越了所有DAO方法(如果一条命令失败,则执行错误,则整个DAO都“崩溃”。)?

  • 我认为前者表示更灵活的工程,但作为库的使用者,向我介绍了很多代码。有什么想法吗?有想法吗?

    最佳答案

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

  • 您的失败点是什么?如何从中恢复?你能康复吗?

  • 您已经提到:

    我想数据库也可能以某种事务或维护模式捆绑在一起,例如允许读取但不允许写入

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

    假设您处于读取有效而写入无效的情况下,则可以维护读取并中断write命令的电路,从而有可能在此过程中节省一些数据库连接。您可以通过增加粒度并为每个DAO方法使用一个命令来执行相同的操作,但是我不确定这是否能真正为您带来任何收益。
  • 您是否需要/想要微调您的应用程序?

  • Hystrix为thread poolsmetrics提供了一些相当不错的配置,可以根据每个命令进行调整。将这些配置为一个(按读写分组)是否有意义,还是您希望对每种DAO方法进行更有限的控制/报告?

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

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

    09-11 02:03
    查看更多