用于IoT场景的Akka角色的粒度

Question

我对在IoT设备场景中使用AKKA很感兴趣，但我担心单个演员的复杂性。在大多数行业中，设备并不像你在大多数教程中看到的“温度传感器”那么简单。一个设备代表的是一些更复杂的东西，可以具有以下特征：

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

所以，我的主要问题是，有没有人对演员的复杂程度有很好的建议？

谢谢史蒂夫

Answer 1

在确定演员应该承担的复杂程度时，以下几个要点可能需要记住：

• Akka角色是轻量级和松散耦合的设计，因此在分布式环境中很好地扩展。另一方面，每个参与者都可以使用Akka的功能丰富的API来处理相当复杂的业务逻辑。这使得在确定一个参与者应该承担多少工作量时具有很大的灵活性。
• 一般而言，quantity of IoT devices和operational complexity in each device是设备执行器设计中的两个关键因素。如果总设备数量很大，那么应该考虑让一些组设备参与者来处理一组设备，例如，使用一个私钥值集合。另一方面，如果每个IoT设备涉及相当复杂的计算或状态突变逻辑，则最好让每个参与者表示单个设备。值得注意的是，这两种策略并不相互排斥。
• 对于历史数据，我建议定期将参与者输入数据库(例如，Cassandra，PostgreSQL)进行OLAP查询。应该让参与者只回答简单的问题。
• Akka演员有一个定义良好的生命周期，包括preStart()、postRestart()、postStop()等用于编程逻辑控制的钩子.可以创建监督策略，以便根据特定的业务规则(发送警报、重新启动参与者等)管理参与者。
• 在定制特定于设备类型的属性(例如度量单位)时，可以将设备类型及其相关的传感器属性(例如，作为case class )建模，并使其成为设备参与者的参数。
• 通过非阻塞消息传递处理不同消息类型的能力是Akka演员最大的优势之一。参与者中的receive部分函数通过模式匹配有效地处理各种消息类型。当表示具有复杂状态突变逻辑的设备时，可以通过context.become安全地交换其工作状态。

这个关于将博客帖子设备模拟为单个参与者的IoT可能会引起人们的兴趣。