Question

我试图第一次绕过Akka /演员，并且对每个演员的责任细节感到有点困惑。

在我的应用中，Widget可以使用WidgetRegistrar注册/取消注册。使用Registrar和Widget注册自己会传递给registerWidget方法：

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

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

我的问题是：这个工作量如何在演员之间传播？

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

WidgetRegistrar演员首先以某种方式委派给WidgetVerifier演员（见下文），如果经过验证，则使用新注册/已验证的WidgetChecker更新Widget演员
WidgetVerifier演员验证Widget是否尝试注册
1个主WidgetChecker，用于检查每个已注册/已验证的Widget

或者不同的策略：

WidgetRegistrar演员首先以某种方式委托给WidgetVerifier演员（见下文），如果经过验证，以某种方式实例化一个新的WidgetChecker演员（见下文）
WidgetVerifier演员验证Widget是否尝试注册

WidgetChecker

1 Widget

或者不同的策略：

WidgetRegistrar演员在当场验证Widget（而非委派给单独的演员），如果经过验证，则使用新注册的人更新WidgetChecker演员/已验证Widget
1个主WidgetChecker，用于检查每个已注册/已验证的Widget

......变化列表一直在继续。

所以我问：Akka演员的粒度是多少，我怎么知道什么时候应该把功能分解成另一个演员并以某种方式连接两个演员？

Answer 1

Akka意识形态让它崩溃了，所以最好将潜在危险的功能分离到一个单独的演员中。

我将如何做到 - 样本演员层次结构：

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

假设您可能希望在注册商中拥有更多功能而不是注册/取消注册单个窗口小部件，那么在特定根目录下分隔窗口小部件会很好 - 例如，如果您的窗口小部件具有功能比如＆＃39;更新＆＃39;，你在/registrar/widget1中调用这个逻辑，如果更新失败，widget1 actor将会死亡。根据您的需要，您可能需要重新注册小部件，或者设置主管层次结构以自动重新启动小部件actor。

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

/ master向/ validator发送消息AttemptRegister(WidgetInfo)
/ validator将此消息发送给其所有子节点（例如，通过ask模式），并期待Accept(WidgetInfo)或Reject(WidgetInfo) - 如果没有拒绝 - 它将发送{{ 1}}到RegisterWidget，注册商会生成新的/registrar。

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

验证可以崩溃还是阻止？然后你需要/registrar/widget2
您需要顺序处理/管道吗？您可能希望实现此序列，例如/validator/capability/doOrDieActor1会将../authentication或Pass发送到Fail，然后将其发送到../authorization等等 - 只有最终的参与者才能将capability发送至ValidationSucceeded，然后将/validator事件发送至RegisterWidget

Akka演员的粒度

1 个答案: