物联网场景中 Akka Actor 的粒度

Question

我有兴趣将 AKKA 用于 IoT 设备方案，但我担心会使单个参与者复杂化。在大多数行业中，设备并不像您在大多数教程中看到的“温度传感器”那么简单。设备代表更复杂的东西，可以具有以下特征：

• 可以表示许多传感器（温度、电流/流体流量、功率输出、开/关值.....
• 可以查询以上每个值的当前值，以及更可能的历史值（趋势、直方图......）
• 可以为任一传感器值设置警报规则
• 每个设备都有一个相当复杂的配置，必须进行管理（什么传感器，什么测量单位）
• 可以发送许多不同的消息类型（传感器读取请求、警报、配置更新......）

所以我的一般问题是，是否有人对演员应该承担的复杂程度有什么好的建议？

谢谢 史蒂夫

Answer 1

以下是在确定演员应承担何种复杂程度时可能需要牢记的几个要点：

• Akka Actor 是轻量级的，并且在设计上是松散耦合的，因此可以在分布式环境中很好地扩展。另一方面，每个参与者都可以使用 Akka 功能丰富的 API 处理相当复杂的业务逻辑。这使得在确定参与者应承担多少工作量方面具有极大的灵活性。

• 一般来说，quantity of IoT devices和operational complexity in each device是设备actor设计中的两个关键因素。如果总设备数量很大，应该考虑让一些设备组参与者，每个参与者使用例如私有键值集合来处理一组设备。另一方面，如果每个物联网设备都涉及相当复杂的计算或状态突变逻辑，那么让每个参与者代表一个单独的设备可能会更好。值得注意的是，这两种策略并不相互排斥。

• 对于历史数据，我建议定期将参与者提供给数据库（例如 Cassandra、PostgreSQL）以进行 OLAP 查询。演员应该只回答简单的问题。

• Akka actor 有一个定义明确的 lifecycle，带有像 preStart()、postRestart()、postStop() 这样的钩子，用于程序逻辑控制。可以创建Supervisor strategies 来根据特定的业务规则管理actor（发送警报、重启actor 等）。

• 在自定义特定于设备类型的属性（例如测量单位）时，可以将设备类型及其关联的传感器属性建模为case class，并将其作为设备的参数演员。

• 通过非阻塞消息传递处理不同消息类型的能力是 Akka Actor 的最大优势之一。 Actor 中的 receive 部分函数通过模式匹配有效地处理各种消息类型。当表示具有复杂状态突变逻辑的设备时，可以通过context.become 安全地热交换其运行状态。

blog post 关于将 IoT 设备模拟为单个参与者可能会引起人们的兴趣。