Akka 演员粒度

Question

我第一次尝试围绕 Akka/actors 进行研究，但对每个 Actor 职责的粒度有点困惑。

在我的应用程序中有Widgets 可以使用WidgetRegistrar 注册/取消注册。要将自己注册到 Registrar 和 Widget 被传递给 registerWidget 方法：

interface WidgetRegistrar {
    public void register(Widget w);
}

当Widget 尝试注册时，会发生验证过程。如果此过程通过，则Widget 会显示一个 URL，必须不断（每秒一次）轮询和检查（使用 HTTP GET）以确保该 URL 仍然健康。

我的问题是：这些工作量应该如何在演员之间分配？

我可以马上想到几种不同的策略：

• WidgetRegistrar 演员首先以某种方式委托给 WidgetVerifier 演员（见下文），如果经过验证，则使用新注册/验证的 Widget 更新 WidgetChecker 演员
• WidgetVerifier 验证 Widget 尝试注册自己的参与者
• 1 个主 WidgetChecker 检查每个已注册/已验证 Widget 的 URL

或者不同的策略：

• WidgetRegistrar 演员首先以某种方式委托给 WidgetVerifier 演员（见下文），如果经过验证，以某种方式实例化一个新的 WidgetChecker 演员（见下文）
• WidgetVerifier 验证 Widget 尝试注册自己的参与者
• 1 WidgetChecker 用于每个注册/验证的Widget

或者不同的策略：

• WidgetRegistrar 演员在现场验证 Widgets（而不是委托给单独的演员），如果通过验证，则使用新注册/验证的 Widget 更新 WidgetChecker 演员
• 1 个主 WidgetChecker 检查每个已注册/已验证 Widget 的 URL

...变化的列表不胜枚举。

所以我问：Akka Actor 的粒度是多少，我如何知道何时应该将功能分解为另一个 Actor 并以某种方式连接这两个 Actor？

Answer 1

Akka 的理念是“让它崩溃”，因此最好将潜在危险的功能隔离到一个单独的参与者中。

我将如何做到这一点 - 示例演员层次结构：

/master
    /validator
        /authentication
        /capability
    /registrar
        /widget1
        /widget2
        /widget3

假设您可能希望在注册器中拥有更多功能，而不是为单个小部件注册/取消注册，最好将小部件分隔到特定根目录下 - 例如，如果您的小部件具有“更新”等功能，您在/registrar/widget1 中调用此逻辑，如果更新失败，widget1 演员将死亡。根据您的需要，您可能需要重新注册小部件，或设置主管层次结构以自动重新启动小部件参与者。

使用验证器/验证器和其他逻辑 - 您可以在验证器上构建管道（顺序处理）或分散收集（并行），例如：

• /master 向/validator 发送消息AttemptRegister(WidgetInfo)
• /validator 将此消息发送给它的所有孩子（例如通过ask 模式），并期待Accept(WidgetInfo) 或Reject(WidgetInfo) - 如果没有拒绝 - 它将发送RegisterWidget 到/registrar 和注册商将生成一个新的/registrar/widget2。

当然，这一切都取决于具体的用例——例如：

• 验证会崩溃或阻塞吗？然后你需要有/validator/capability/doOrDieActor1
• 您需要顺序处理/管道吗？你可能想要实现这个序列，比如../authentication 将发送Pass 或Fail 到../authorization，然后将它发送到capability 等等——并且只有最终的actor 会将ValidationSucceeded 发送到/validator，这将依次将RegisterWidget 事件发送到registrar