akka - 物联网场景中 Akka Actor 的粒度

Question

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

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

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

谢谢史蒂夫

标签： akkaiot

Answer 1

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

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

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

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

• Akka Actor 有一个定义良好的生命周期，其中包含用于编程逻辑控制 的钩子，如, preStart()。可以创建主管策略来根据特定的业务规则管理参与者（发送警报、重启参与者等）。postRestart()postStop()

• 在定制特定于设备类型的属性（例如测量单位）时，可以将设备类型连同其相关联的传感器属性建模为 acase class并使其成为设备参与者的参数。

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

这篇关于将物联网设备模拟为单个参与者的博客文章可能会引起人们的兴趣。