java - Akka Actor 粒度

Question

我第一次尝试了解 Akka/Actors，并且对每个 Actor 职责的粒度有点困惑。

在我的应用程序中，有可以使用 WidgetRegistrar 注册/取消注册的 Widget。要向 Registrar 注册自身，并将 Widget 传递给 registerWidget 方法:

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

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

我的问题是:这个工作量应该如何在参与者之间分配？

我可以立即想到几种不同的策略:

• WidgetRegistrar actor首先以某种方式委托(delegate)给WidgetVerifier actor(见下文)，如果经过验证，则使用新注册/验证的Widget更新WidgetChecker actor
• WidgetVerifier actor 验证尝试注册自身的 Widget
• 1 个主 WidgetChecker，用于检查每个注册/验证的 Widget 的 URL

或者不同的策略:

• WidgetRegistrar actor 首先以某种方式委托(delegate)给 WidgetVerifier actor(见下文)，如果经过验证，则会以某种方式实例化一个新的 WidgetChecker actor(见下文)
• WidgetVerifier actor 验证尝试注册自身的 Widget
• 每个注册/验证的 Widget 1 个 WidgetChecker

或者不同的策略:

• WidgetRegistrar actor 现场验证 Widget(而不是委托(delegate)给单独的 actor)，如果通过验证，则使用新注册/验证的 Widget 更新 WidgetChecker actor
• 1 个主 WidgetChecker，用于检查每个注册/验证的 Widget 的 URL

...变体列表还在不断增加。

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

Answer 1

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

我将如何做到这一点 - 示例 Actor 层次结构:

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

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

使用 validator/validator 和其他逻辑 - 您可以在 validator 上构建管道(顺序处理)或分散收集(并行)，例如:

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

当然，这完全取决于具体用例 - 例如:

• 验证会崩溃或阻塞吗？那么你需要有 /validator/capability/doOrDieActor1
• 您需要顺序处理/管道吗？您可能想要实现此序列，例如 ../authentication 将发送 Pass 或 Fail 到 ../authorization，后者将其发送到 capability 等 - 并且只有最终参与者才会将 ValidationSucceeded 发送到 /validator，后者又将 RegisterWidget 事件发送到 registrar