Какая правильная архитектура с message bus для клиент-серверной IoT-системы?

Question

[dropsonic]

Есть система, она состоит из сервера и набора IoT-девайсов.
Каждый IoT-девайс хостит набор микросервисов (Docker).
Каждый микросервис должен отправлять / получать интеграционные сообщения другим микросервисам на том же устройстве, плюс отправлять / получать сообщения на сервер.
Сервер должен уметь отправлять сообщения всем IoT девайсам (запрос статуса), группе IoT девайсов (группировка может быть по разным признакам, например, номер комнаты, где стоят девайсы, город и т.п.), конкретному IoT девайсу (например, команда на перезапуск / переконфигурацию).

Вопрос: как это правильнее всего организовать с точки зрения message bus? Делать два инстанса message bus — локальный RabbitMQ в Docker на каждом IoT-девайсе, и глобальный для обмена "сервер-клиенты"? Иметь один общий message bus и каким-то образом роутить сообщения? (тогда будет оверхед на микросервисное взаимодействие через облако, хотя сами сообщения небольшие по размеру).

В качестве message bus framework планируется использовать MassTransit, если это важно (сервер может хоститься как в Azure, так и локально с RabbitMQ).

Заранее спасибо.

Answer 1

[Сергей]

Я не работал с IoT-устройствами, но мне кажется, что отдельная локальная шина звучит логично, так как позволит иметь наименьшие задержки и работать офлайн, а также, возможно, сэкономить батарею. Но зависит от задачи и ресурсов, может оказаться поначалу выгодней работать через серверв. RabbitMQ использовать на IoT-устройстве так себе идея, имхо, для простой отправки в маленьком масштабе он будет невыгоден по ресурсопотреблению.