Комментарии 16
Интересное решение. Сейчас вы дошли до теории конечных автоматов. Следующим шагом будет - Сети Петри и kubernetes с автомасштабированием и runner'ами, аля Gitlab, либо AWS lambda с идеологией serverless. Но это уже будет другая история, история потоковых вычислений. Пока только упираетесь в возможности сервера.
Стали бы мы делать TaskManager сейчас, если нужно было решать задачу по управлению скриптами в 2025? Не факт. Скорее всего попытались бы задействовать Airflow (с рядом костылей).
Почему не Temporal?
Описанная задача на современный стек ложится идеально на Dagster. Он проще и легче чем Apache Airflow и имеет кучу интеграций всего со всем. А масштабирование настроенных DAG-ов на узлы/серверы делается буквально в одну строку через pip install ...
Интересное решение!
ЕИС через ftp было удобно таскать, теперь СОИ кратно повышает сложность забора информации.
А может расскажете, как и куда xml распарсиваете?..
Чего только люди не придумают, чтобы n8n не внедрять
Ты точно не выдрал фразу из моих уст ? Но вообще ответ в статье есть - они это делали еще, когда эйрфлоу был маленький.
Тогда n8n еще не существовало, но и сегодня я бы не стал его выбирать для этой задачи. На мой взгляд, он уступает Dagster и Airflow, когда требуется запускать сложные пайплайны и автоматически масштабировать под доступные ресурсы.
Нет, чтобы переписать обработку на нормальный язык. Условно был - баш скрипт. Стала моно программа с аргументами на голанге. За счёт компиляции, быстрой загрузки и параллельности обработки - мы получили выигрыш до 10х на тех же задачах. Там уже скорее веселуха в том, что если база медленная - она прикладывается ) но это совсем другая проблемка, правда ? И это в далеком 2017….
Внедрить другой стек ради выигрыша в миллисекунды для операции, которая длится несколько часов? Надеюсь, вы этого не предлагаете всерьез ) По поводу базы частично правы. TaskManager управляет скриптами, которые в основном работают с базой, и база всегда является узким местом.
Я сказал - в нашем случае выигрыш был 10х. Что на диапазоне в несколько часов дает десятки минут. Не то, чтобы супер, но хорошо. И явно лучше, чем поддерживать баш портянки. А за счет внедрения sentry (можно otel) - увеличилось качество обработки данных, так как ошибки стало возможно ловить и потом обрабатывать.
Касательно башни - там еще проблема, что когда у вас много скриптов, которые выполняются малое время (минуты) - потери на запуск достаточно ощутимые. Решение? Ну, я уже высказался.
Bash-скрипт на максималках: как работает менеджер задач для управления 300 скриптами