Akka與設備組一塊兒工做《twelve》譯

Dependency

在項目中添加如下依賴項：

介紹：

讓咱們仔細看看咱們的用例所需的主要功能，在用於監控家庭溫度的完整物聯網系統中，將設備傳感器鏈接到咱們系統的步驟可能以下所示：

1. 家中的傳感器設備經過某種協議鏈接。
2. 管理網絡鏈接的組件接受鏈接。
3. 傳感器提供其組和設備ID以向咱們系統的設備管理器組件註冊。
4. 設備管理器組件經過查找或建立負責保持傳感器狀態的actor來處理註冊。
5. Actor迴應一個確認，暴露其ActorRef。
6. 網絡組件如今使用ActorRef進行傳感器和設備actor之間的通訊，而無需經過設備管理器。

步驟1和2發生在咱們的教程的範圍以外。在本章中，咱們將開始解決步驟3-6，併爲傳感器建立一種方式來註冊咱們的系統並與Actor進行通訊。但首先，咱們還有另外一個架構決策 - 咱們應該使用多少級別的Actor來表明設備組和設備傳感器？

Akka程序員面臨的主要設計挑戰之一是爲Actor選擇最佳粒度。實際上，根據Actor之間交互的特徵，一般有幾種有效的方法來組織系統。例如，在咱們的用例中，可讓一個Actor維護全部組和設備 - 可能使用哈希映射。爲每一個組創建一個跟蹤同一家庭中全部設備狀態的參與者也是合理的。

如下指南幫助咱們選擇最合適的actor層次結構：

• 一般，更喜歡先引入大的粒度，比須要的更細粒度的Actor會致使比解決的更多的問題。
• 在系統須要時添加更精細的粒度：

1.  更高的併發性。
2.  具備許多狀態的Actor之間的複雜對話，咱們將在下一章中看到一個很好的例子。
3. 足夠的狀態，分紅較小的角色是有意義的。
4. 多個不相關的責任，使用單獨的參與者可使我的失敗並恢復，而對他人的影響很小。  

設備管理層次結構

考慮到上一節中概述的原則，咱們將設備管理器組件建模爲具備三個級別的Actor樹：   

• 頂級管理員Actor表明設備的系統組件。它也是查找和建立設備組和設備角色的入口點。
• 在下一級別，組成員每一個監督一個組ID（例如一個家庭）的設備角色。它們還提供服務，例如查詢其組中全部可用設備的溫度讀數。
• 設備Actor管理與實際設備傳感器的全部交互，例如存儲溫度讀數。

 

出於如下緣由，咱們選擇了這種三層架構：

擁有各個Actor的組：

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

有什麼討論的內容，能夠加我公衆號：