Как мы «строили» систему диспетчеризации в карьере.
Сегодня поделюсь текущим кейсом, который можно было избежать, но, как говорится «опыт - сын ошибок трудных…». Работаем над системой диспетчеризации для горного транспорта в карьере. В какой-то момент начали замечать: 📉 сообщения от водителей долго доходят до диспетчера 📉 команды диспетчера тоже не всегда вовремя прилетают обратно
А теперь внимание — у нас была такая схема:
• Телеметрия (где техника, как работает) летит с машины по MQTT → Kafka → сервер — всё ок, быстро. • А вот сообщения от водителя с планшета и команды диспетчера — через HTTP. И вот тут начались задержки, особенно когда связь в карьере не очень.
Решили упростить: убрали HTTP и перевели всё на единую “шину” MQTT + Kafka.
Что ожидаем:
1. Машина публикует в топики MQTT и телеметрию, и сообщения от водителя. 2. Kafka их забирает и передаёт на сервер. 3. Сервер обрабатывает и публикует обратно — через Kafka → MQTT → машина.
Что получаем: ✅ скорость выше ✅ схема проще — один канал вместо двух ✅ можно развивать дальше: техника сможет “общаться” между собой напрямую (P2P), например, предупреждать о пробке на отвале
В итоге делаем топики по каждому типу сообщений, настроили QoS (важные команды гарантированно доходят) и готовимся обкатывать всё это на тестовом участке.
👉 Если работаете с техникой, диспетчерскими системами или просто страдаете от раздутой архитектуры — подумайте, можно ли упростить.
Иногда решение — просто убрать лишнее.
А можно сразу сделать хорошо.🤓