Гранулярность актера Akka для сценария IoT - PullRequest
Новая
       8

Гранулярность актера Akka для сценария IoT

0 голосов
/ 08 мая 2018

Меня интересует использование AKKA для сценария устройства IoT, но я беспокоюсь о том, чтобы усложнить отдельного актера. В большинстве отраслей устройство не так просто, как «датчик температуры», которое вы видите в большинстве учебных пособий. Устройство представляет собой нечто более сложное, которое может принимать следующие характеристики:

  • Можно представить множество датчиков (температуры, электрические / жидкостные потоки, выходная мощность, значения вкл / выкл .....
  • Каждое из вышеприведенных значений может быть запрошено для текущего значения и более вероятных исторических значений (тренды, гистограммы ....)
  • Правила оповещения могут быть установлены для любого из значений датчика
  • Каждое устройство имеет довольно сложную конфигурацию, которой необходимо управлять (какие датчики, какая единица измерения)
  • Может быть отправлено много разных типов сообщений (запрос считывания датчика, предупреждения, обновления конфигурации ....)

Итак, мой общий вопрос: есть ли у кого-нибудь хороший совет о том, какой уровень сложности должен принять актер?

Спасибо Стив

1 Ответ

0 голосов
/ 12 мая 2018

Ниже приведены несколько пунктов, которые следует учитывать при определении уровня сложности, с которым должен столкнуться актер:

  • Актеры Akka легки и слабо связаны друг с другом, поэтому они хорошо масштабируются в распределенной среде. С другой стороны, каждому действующему лицу может быть поручено обрабатывать довольно сложную бизнес-логику с помощью многофункционального API Akka. Это дает большую гибкость в определении того, какую нагрузку должен нести актер.

  • В общем, quantity of IoT devices и operational complexity in each device являются двумя ключевыми факторами в дизайне актера устройства. Если общее количество устройств велико, следует рассмотреть возможность использования некоторых действующих лиц групповых устройств, каждый из которых обрабатывает набор устройств, используя, например, коллекцию значений закрытых ключей. С другой стороны, если каждое устройство IoT включает в себя довольно сложную логику вычисления или изменения состояния, может быть лучше, чтобы каждый участник представлял отдельное устройство. Стоит отметить, что эти две стратегии не являются взаимоисключающими.

  • Для исторических данных я бы рекомендовал периодически подавать акторов в базу данных (например, Cassandra, PostgreSQL) для запросов OLAP. Актеры должны быть оставлены, чтобы отвечать только на простые запросы.

  • Актеры Akka имеют четко определенный жизненный цикл с крючками типа preStart(), postRestart(), postStop() для программного логического управления. Стратегии супервизора можно создавать для управления субъектами в соответствии с определенными бизнес-правилами (отправлять оповещения, перезапускать участников и т. Д.).

  • При настройке атрибутов (например, единиц измерения), специфичных для типа устройств, можно смоделировать тип устройства вместе со связанными с ним атрибутами датчика, скажем, как case class и сделать его параметром устройства. актер.

  • Возможность обработки сообщений различных типов посредством неблокирующей передачи сообщений является одной из самых сильных сторон актеров Akka. Частичная функция receive в субъекте эффективно обрабатывает различные типы сообщений посредством сопоставления с образцом. При представлении устройства со сложной логикой мутации состояния его рабочее состояние может быть безопасно заменено с помощью context.become .

Это сообщение в блоге о моделировании устройств IoT как отдельных участников может представлять интерес.

...