Akka持久性用于管理Actor状态，以便它可以在应用程序（https://www.reactivemanifesto.org/）出现故障时恢复。可能不适合用于业务案例。我了解到您的要求是能够浏览系统中的Actor。我看到了几个选项：
选项1：Akka支持名为命名参与者的功能（https://doc.akka.io/docs/akka/current/general/addressing.html）。在您的情况下，您有设备到执行元作为一对一Map。因此，您可以利用此功能，使用名称执行元功能。在执行元系统中创建执行元期间，您应用了这个模式，这样系统中所有参与者都用设备id命名现在您可以浏览所有设备id（因为这是您的用例细节，您可以使用您提到的Solar/Elastic Search来搜索模块）。无论何时浏览设备都意味着您正在浏览系统中的Actor。您可以使用此命名的Actor路径从系统中检索Actor，并执行一些操作。
选项2：您可以使用监视工具来跟踪/浏览应用程序中的参与者。除了您的需要，它还提供了其他几个有用的度量。https://www.lightbend.com/blog/akka-monitoring-telemetryhttps://kamon.io/solutions/monitoring-for-akka/

Akka Persistence非常倾向于Command-Query Responsibility Separation（命令.查询责任分离）风格的系统实现。（更改通过命令建模的数据的意图）。在某些情况下，此责任会延续到单独部署的服务，但这并不是必须的（就部署/操作或开发而言，分离程度越高，它们的耦合程度就越低，因此您需要在成本/收益之间进行权衡，以确定您希望处于哪个隔离级别）。
通常，系统中处理命令并决定给定命令如何（甚至是否）更新状态的部分通常称为“写入端”。在应用程序中，对设备状态进行建模并持久化更改的FSM参与者将是写入端，您似乎对该部分了如指掌。
相应地，处理查询的部分通常被称为“读取端”，并且一个关键的好处是它可以使用与写入端不同的数据模型，直到并且包括使用不同的数据存储（例如Solr/Elasticsearch）。
由于您使用了Akka Persistence和事件源（从提到的日志表判断），Akka Projections提供了一个很好的 Package 器，用于将事件从写端发布到Kafka，以便另一个服务更新Solr/Elasticsearch的读端。您可以通过组合persistenceIds和eventsByPersistenceId查询流来完成类似的工作，从而将事件从写入端提供给Kafka，而不必进行标记。
请注意，当沿着CQRS路径前进时，您通常会在写入端和读取端之间实现某种程度的最终一致性。