Akka与设备组一块儿工做《twelve》译

Dependency

在项目中添加如下依赖项:html

介绍:java

让咱们仔细看看咱们的用例所需的主要功能,在用于监控家庭温度的完整物联网系统中,将设备传感器链接到咱们系统的步骤可能以下所示:git

  1. 家中的传感器设备经过某种协议链接。
  2. 管理网络链接的组件接受链接。
  3. 传感器提供其组和设备ID以向咱们系统的设备管理器组件注册。
  4. 设备管理器组件经过查找或建立负责保持传感器状态的actor来处理注册。
  5. Actor回应一个确认,暴露其ActorRef。
  6. 网络组件如今使用ActorRef进行传感器和设备actor之间的通讯,而无需经过设备管理器。

步骤1和2发生在咱们的教程的范围以外。在本章中,咱们将开始解决步骤3-6,并为传感器建立一种方式来注册咱们的系统并与Actor进行通讯。但首先,咱们还有另外一个架构决策 - 咱们应该使用多少级别的Actor来表明设备组和设备传感器?程序员

Akka程序员面临的主要设计挑战之一是为Actor选择最佳粒度。实际上,根据Actor之间交互的特征,一般有几种有效的方法来组织系统。例如,在咱们的用例中,可让一个Actor维护全部组和设备 - 可能使用哈希映射。为每一个组创建一个跟踪同一家庭中全部设备状态的参与者也是合理的。github

如下指南帮助咱们选择最合适的actor层次结构:安全

  • 一般,更喜欢先引入大的粒度,比须要的更细粒度的Actor会致使比解决的更多的问题。
  • 在系统须要时添加更精细的粒度:
  1.  更高的并发性。
  2.  具备许多状态的Actor之间的复杂对话,咱们将在下一章中看到一个很好的例子。
  3. 足够的状态,分红较小的角色是有意义的。
  4. 多个不相关的责任,使用单独的参与者可使我的失败并恢复,而对他人的影响很小。  

设备管理层次结构网络

考虑到上一节中概述的原则,咱们将设备管理器组件建模为具备三个级别的Actor树:   架构

  • 顶级管理员Actor表明设备的系统组件。它也是查找和建立设备组和设备角色的入口点。
  • 在下一级别,组成员每一个监督一个组ID(例如一个家庭)的设备角色。它们还提供服务,例如查询其组中全部可用设备的温度读数。
  • 设备Actor管理与实际设备传感器的全部交互,例如存储温度读数。

 

出于如下缘由,咱们选择了这种三层架构:并发

拥有各个Actor的组:ide

  1. 隔离组中发生的故障。若是单个actor管理全部设备组,则致使从新启动的一个组中的错误将消除不然无端障的组的状态。
  2. 简化查询属于组的全部设备的问题。每一个组actor仅包含与其组相关的状态。
  3. 增长系统的并行性。因为每一个组都有一个专用的actor,它们能够同时运行,咱们能够同时查询多个组。

将传感器建模为单个设备角色:

  1. 将一个设备actor的故障与组中的其他设备隔离。
  2. 增长收集温度读数的并行度。来自不一样传感器的网络链接直接与其各个设备Actor通讯,从而减小了争用点。

经过定义架构,咱们能够开始使用协议来注册传感器。

注册协议

做为第一步,咱们须要设计协议以注册设备和建立将负责它的组和设备Actor。此协议将由DeviceManager组件自己提供,由于它是惟一已知且可预先使用的Actor:按需建立设备组和设备Actor。

更详细地查看注册,咱们能够概述必要的功能:

  • 当DeviceManager收到包含组和设备ID的请求时:
  1. 若是经理已经拥有设备组的参与者,它会将请求转发给它。
  2. 不然,它会建立一个新的设备组Actor,而后转发该请求。
  • DeviceGroup Actor接收注册给定设备的actor的请求:
  1. 若是组已经有设备的actor,则组actor将请求转发给设备actor。
  2. 不然,DeviceGroup Actor首先建立一个设备Actor,而后转发该请求。
  • 设备参与者接收请求并向原始发送者发送确认。因为设备actor确认收到(而不是组actor),传感器如今将使用ActorRef将消息直接发送给其actor。

咱们将用于传达注册请求及其确认的消息有一个简单的定义:

在这种状况下,咱们没有在消息中包含请求ID字段。因为注册发生一次,当组件将系统链接到某个网络协议时,ID并不重要。可是,一般最佳作法是包含请求ID。

如今,咱们将从下往上开始实施协议。在实践中,自上而下和自下而上的方法均可以工做,但在咱们的状况下,咱们从自下而上的方法中受益,由于它容许咱们当即编写新功能的测试,而不会模拟咱们须要的部分后来建造。

向设备角色添加注册支持

咱们层次结构的底部是Device actors。他们在注册过程当中的工做很简单:回复注册请求并向发件人发送确认。谨慎地对针对不匹配的组或设备ID的请求添加安全措施。

咱们假设注册消息的发送者的ID保留在上层。咱们将在下一部分向您展现如何实现这一目标。

设备actor注册码以下所示:

Full source at GitHub

咱们如今能够编写两个新的测试用例,一个执行成功注册,另外一个测试ID不匹配的状况:

Full source at GitHub

咱们使用了TestKit中的expectNoMsg()辅助方法。此断言将一直等到定义的时间限制,若是在此期间收到任何消息,则会失败。若是在等待期间没有收到消息,则断言经过。保持这些超时较低(但不能过低)一般是一个好主意,由于它们会增长大量的测试执行时间。

下节再续!

原文:https://doc.akka.io/docs/akka/2.5/guide/tutorial_4.html

有什么讨论的内容,能够加我公众号:

相关文章
相关标签/搜索