显示所有现有 Actor 的模式是什么

Question

我编写了一个实现设备管理的 Akka 应用程序。每个设备都是一个 Akka Actor，我实现了 Akka 有限状态机来控制设备的生命周期，例如 FUNCTIONAL、BROKEN、IN_REPAIRS、RETIRED 等……我使用 Akka Persistence 将设备持久化到 Cassandra。

一切都像做梦一样，但我有两难选择，我想问问处理 Akka 的模式是什么。

我将拥有近 1 000 000 个设备，Akka 是管理这些单个实例的理想选择，但如果用户一个查看所有设备系统并选择一个，我如何实现它，更改它是状态...

我无法从 Akka Journal 表中显示它，我无法显示除 persistenceId 之外的任何内容。

那么你将如何处理这个困境。

我目前的计划，当所有事件都从 Kafka 进入我的系统时，也会使用来自 Topic 的这些消息并将这些消息重定向到 Solr/Elasticsearch，因此我可以使用 persistenceId 为它的一些元数据编制索引，因此用户可以选择一个设备来处理阿卡演员。

你有更好的想法或如何解决这个想法？

将这些信息 Cassandra 保存到另一个 Keyspace 的另一种选择，但由于某种原因我不喜欢它.....

谢谢解答...

Answer 1

Akka Persistence 主要面向实现系统的命令-查询职责分离风格。如果您想要更深入地描述这种模式，有很多很好的大纲来描述，但大体上的想法是，您将更改数据的责任（通过命令建模的更改数据的意图）与查询数据的责任分开。在某些情况下，这种责任会延续到单独部署的服务，但它不是必须的（在部署/运营或开发方面越分离，它们的耦合越少，因此在您想要的地方需要权衡成本/收益处于分离水平谱上）。

通常，系统中处理命令并决定给定命令如何（或什至是否）更新状态的部分通常称为“写入端”。在您的应用程序中，建模设备状态和持久更改的 FSM 参与者将是写入端，而您似乎已经掌握了这部分。

相应地，处理查询的部分通常被称为“读取端”，一个关键的好处是它可以使用与写入端不同的数据模型，甚至包括使用不同的数据存储（例如 Solr/Elasticsearch）。

由于您使用 Akka 持久性和事件源（从提及日志表判断），Akka Projections 提供了一个很好的自以为是的包装器，用于将事件从写入端发布到 Kafka，以便另一个服务更新 Solr/Elasticsearch 读取侧与。它确实需要（至少在此时）您的写入端标签事件；通过结合persistenceIds 和eventsByPersistenceId 查询流，您可以通过一些努力做类似的事情，将事件从写入端馈送到Kafka，而无需标记。

请注意，当沿着 CQRS 路径前进时，您通常会在写入端和读取端之间实现某种程度的最终一致性。

Answer 2

Akka 持久性用于管理 Actor 状态，以便在应用程序失败时具有弹性 (https://www.reactivemanifesto.org/)。可能不是将其用于业务案例的最佳选择。我了解您的要求是能够浏览系统中的演员。我看到了几个选项：

选项1： Akka 支持名为命名演员 (https://doc.akka.io/docs/akka/current/general/addressing.html) 的功能。在您的情况下，您将 设备到 Actor 作为一对一映射。因此，您可以使用名称演员功能来利用这一点。在 Actor 系统中创建 Actor 期间，您应用此模式，以便系统中的所有 Actor 都使用设备 ID 命名。现在您可以浏览所有设备 ID（因为这是您的用例详细信息，您可以使用 Solar/您提到的弹性搜索）。每当浏览设备意味着您正在浏览系统中的 Actors 时。您可以使用这个命名的演员路径从系统中检索演员并执行一些操作。

选项2： 您可以对应用程序中的跟踪/浏览参与者使用监控工具。除了您的需要之外，它还提供了其他几个有用的指标。 https://www.lightbend.com/blog/akka-monitoring-telemetry https://kamon.io/solutions/monitoring-for-akka/