Comments 18
Как насчет вложенных процессов, поддерживаются? Или все задачи должны быть расписаны в одном плоском процессе?
Здесь может возникнуть вопрос: а как же детерминизм бизнес‑логики сочетается с её обновлением? В Temporal есть встроенный механизм версионирования, который позволяет держать в коде старый и новый варианты одновременно, пока ни одного старого работающего workflow не останется.
Если я правильно прочитал, то запущенный workflow измениться не может. Так?
А что делать, если его надо изменить?
Перезапуск сервера Temporal приводит к остановке процессов, или они восстанавливаются в той же точке с тем же контекстом?
Как насчет вложенных процессов, поддерживаются? Или все задачи должны быть расписаны в одном плоском процессе?
Да, есть Child Workflow
Запущенный workflow измениться не может
Тут довольно тонкий момент. Некоторые изменения — например, изменение продолжительности таймера, или изменение аргументов вызова Activity — не приводят к недетерминизму (вот здесь подробнее). Кроме того, мы вольны менять код activity вообще в любой момент, на них требования детерминизма не распространяются
А что делать, если его надо изменить?
Тут возможны разные варианты действий в зависимости от конкретной ситуации. Если воркфлоу паникует и не может пройти какой-то шаг, то здесь просто поможет релиз исправленного кода воркфлоу. Если workflow завис в бесконечном ожидании, то после выкатки новой версии кода можно его reset-нуть, и бизнес-логика будет выполняться заново (вместе со всеми activity) с того места, на который reset-нули. В принципе в большинстве случаев reset должен помочь — даже есть воркфлоу пошёл неправильно и уже закончился, мы всё равно сможем его reset-нуть.
По сути своей reset — это terminate исходного воркфлоу и копирование какой-то части истории в новый, который и продолжит выполняться
Перезапуск сервера Temporal приводит к остановке процессов, или они восстанавливаются в той же точке с тем же контекстом?
Всё восстановится в той же самой точке, потому что в истории событий в БД хранится вся необходимая информация, все остальные компоненты, в общем, stateless. Так, например, можно спокойно остановить сервер, обновить его, и запустить заново, единственным эффектом будет задержка выполнения действий на время этой операции
Можете поделиться примерными метриками кластера, пожалуйста? Для примера, задержками AddActivityTask, StartWorkflowExecution? Контекст вопроса - недавно запускали в тестовом режиме кластер Temporal, и задержки оказались достаточно нестабильными, особенно на малых нагрузках, и отличаются в 2-3 раза от примерных целевых параметров для Temporal Cloud из документации.
Делали ли какие-то дополнительные настройки кластера для увеличения производительности? Вообще, было бы интересно почитать техническую сторону вопроса именно по запуску и обслуживанию кластера - документация(во всяком случае раньше) была не очень подробной для OSS-решения.
Там все сильно зависит от бд которую вы использовали и history shard count которые нужно подбирать для конкретно вашего паттерна нагрузки.
По бд, темпоралу нужна Кассандра для самой высокой производительности, есть поддержка postgresql, но даже они сами рекомендуют его использовать только для младших сред
У нас есть отдельная команда, которая занимается внутренними инсталляциями Temporal и его тюнингом. Подробностей я не знаю, но, в частности, в хранилище используется YDB (сам слой персистентности доступен в open source: https://github.com/yandex/temporal-over-ydb)
благодаря удобству управления из workflow можно проще и безопасней выполнять больше работы параллельно — так что общие тайминги у нас уменьшились
ИИ писал статью, да?
Да, формулировка получилась не очень. Я имел в виду следующее: например, при создании заказа нужно выполнить довольно много действий. При этом результат некоторых действий требуется для некоторых других, а кроме того, падение одних действий можно игнорировать, падение других требует фоллбеков, а падение третьих приводит к невозможности дальнейшей обработки.
В старой парадигме (на очередях и стейт-машине) большая часть этих действий выполнялась последовательно, чтобы не усложнять дополнительно код, и так усложнённый асинхронными вызовами и фоллбеками. Temporal позволяет гораздо лучше сфокусироваться на бизнес-логике, и правильно расписать зависимости между действиями, не запутывая код настолько, что его невозможно будет поддерживать.
Поэтому даже с дополнительными задержками на взятие задач в работу весь этап завершается заметно быстрее
А я правильно понял, что temporal это аналог prefect (https://www.prefect.io/) но с поддержкой большего числа языков программирования?
с Perfect я никогда не имел дело, но судя по сайту, у них нет такого акцента на надёжность и воспроизводимость бизнес-логики, как у темпорала, и он не построен на event sourcing, а просто поддерживает кеширование промежуточных результатов пайплайна. Поэтому у меня пока сложилось впечатление, что Perfect гораздо ближе по замыслу к Airflow
Тоже используем темпорал, очень довольны, но
Главный вопрос, как вы все это хостите для обеспечения отказоустойчивости? Ведь в self-hosted версии нет поддержки high availability namespaces и и фича для работы в режиме нескольких кластеров ещё не production ready.
Выглядит интересно, но что с латенси?
Как быстро новые задачи уходят в обработку? Нам единицы миллисекунд важны.
если единицы миллисекунд, то тогда это не про темпорал. Он слишком много сетевых взаимодействий делает
Но можно написать свою библиотеку на тех же принципах, тогда миллисекунды будут вполне нормальной latency.
Никакой особой магии нет, реализация библиотеки - 4-6 человекмесяцев сеньора.
Да, у нас одна команда так и сделала. Надеюсь, выложат в опенсорс в следующем году. Наверняка есть решения и от других крупных компаний, т.к. довольно часто требуется некий быстрый и надежный оркестратор для какой-то сложной логики
Мы и написали, но она сильно проще по функционалу. Полноценные воркфлоу вроде тех что в Temporal или Floxy тоже оценили в полгода... И всё на этом)
Как Temporal без боли решает привычную проблему распределённой бизнес-логики