2021-11-25 04:01:08
Давно не писал, чем занимаюсь, опишу проблему, над которой сейчас работаю
Все современные подходы к автоматизации - заложники pub-sub паттерна. Pub-sub де-факто стал стандартом в этой области и позволяет идеально синхронизировать данные телеметрии с несколькими источниками, обрабатывающими логику, предоставляющими интерфейсы и собирающими статистику, что важно - при отсутствии прямой видимости
Всё это прекрасно работает, когда все участники системы находятся постоянно на связи. Что же происходит, если конечный узел отваливается от сети? Он продолжает собирать телеметрию, но отправить ее некуда. Через некоторое время связь возобновляется и это уже проблема узла - сообщить всем, что происходило, пока он был оффлайн. Или не сообщить, тут уже как хотите. Правда, уже на этом этапе никакой гарантии, что объемы архивной телеметрии не забьют канал.
Кроме канала, проблем в целом нет, если мы отправляем данные в большое облако, все сервисы которого всегда онлайн. Проблема начинается, если мы используем локальный брокер или подключаем к облаку собственные сервисы. Нет никакой гарантии. что когда вернувшийся узел отправит телеметрию, ее кто-то будет слушать на другом конце. Кто-то предоставляет retain-топики, кто-то (чаще) нет. Но архив в retain всё равно не запишешь, разве что будешь плодить "телеметрия/ябылоффлайнвчера", "телеметрия/ябылоффлайнпозавчера" и прочее, заставляя подписчиков скачивать всё это каждый раз, даже если эти данные у них уже имеются, и забивать в свою очередь уже свои каналы.
Это всё выше - в целом лирика и обычно pubsub работает на практике очень просто и жестко. Не подписался - проебал.
Для интерфейсов и сервисов логики, которые работают с телеметрией в реальном времени в целом это проблемы не составляет. Беда начинается с системами сбора статистики и анализа этих данных. Именно этому посвящен наш следующий проект, с задачами
а) хранить телеметрию максимально компактно и долго, идеально - почти вечно (полезно для гарантийных случаев, гарантия на промышленную железяку, например, может составлять 15-20 лет, из которых она ни одной секунды не будет онлайн)
б) позволить сервисам статистики синхронизировать телеметрию максимально точно, причем только через одно "окошко" - pubsub-сервер, ведь прямая видимость узлов не гарантируется
в) восстанавливать данные, в идеале - полностью автоматически, даже если узел был оффлайн несколько дней. а при невозможности - иметь удобные ручные инструменты, не перекачивая всю базу целиком, а только недостающие фрагменты. при ручной обработке, в свою очередь, дать возможность использовать любой возможный канал - от scp до переноса блоков на флешке
891 viewsedited 01:01
S
