Comments 16
Спасибо за статью. Однако, это больше на PHP нацелено.
Лично мне был бы больше интересен пример с Python, а особенно бы интересовало сравнение с, например, Airflow. Если выбирать для Python-стека - то вы бы выбрали Temporal, Airflow или просто на базе Celery построили свой фреймворк?
Основная разница в подходе управления потоком workflow. В Airtable как и большистве похожих решений идет распаковка DAG, т.е. если ваша логика ложится на него - все супер. В темпорал все управление императивное - простой код, т.е. можно и DAG (да, многие переносят свой DSL на Temporal), а можно и без него.
Если упрощенно - Airflow управляет стейтом сам, Temporal дает вам дергать за ниточки.
Разница становится очень заметной когда ваши бизнес процессы не ложаться на простую цепочку вызовов - циклы, условия, динамическое кол-во действий. Ну и плюс - все работает на множестве языков из коробки.
У нас весь ML стек гоняется через Temporal, нарадоваться не можем. Часть логики на Python, все управление на PHP.
Из интересных паттернов что могу отметить при работе, очень удобно упаковывать определение стабов активити в трейты.
class MyWorkflow {
use SomeActivity;
public function run() {
yield $this->someActivity()->doSomething();
}
}
Сильно упрощяет управление теми активити где политики запуска, task queue и ретраи не меняются в зависимости от родительского воркфлоу.
Спасибо за идею )
А где у вас лежат эти трейты? Все вместе в одном неймспейсе или раскиданы по кодовой базе? Как разработчики ищут activity, чтобы случайно не написать уже существующий?
А ещё можно пойти по пути упрощения фабрик Activity/Workflow. Код выглядит так:
StubFactory::activity(FooActivity::class, retryAttempts: 1)->foo($foo, $bar)TaskQueue и прочие настройки, если постоянные, берутся из атрибутов. Те, что определяются по месту - передаются аргументами.
Хоть номинально все RPC вызовы и проходят через один Temporal кластер, но гибких возможностей выстраивать политику кто и что может, вроде как, нельзя. Поэтому сервисы практически бесконтрольно могут дёргать друг-друга.
Этот недостаток можно попробовать решить интерцепторами. Тут сложность возникнет с тем, чтобы описать их на всех языках, на которых написаны Workflow. Но если у вас только PHP, то аля deptrac|nocolor на интерцепторах - интересный вызов :) Интерцепторы уже можно щупать, установив SDK версии 2.7.0@dev.
Примеры некоторых доступны в семплах https://github.com/temporalio/samples-php/pull/40/files
О, это интересно, спасибо!
Но если у вас только PHP
У нас TypeScript, PHP и ещё немного Python. П
интересный вызов
Основная сложность в том, что у нас уже есть компонент, через который проходит весь трафик — единое API, на нём мы и отслеживаем выполнение разных политик. Добавляя Temporal, мы получаем второй компонент, хотя, наверное, можно придумать как пропускать Temporal трафик через единое API.
Хоть номинально все RPC вызовы и проходят через один Temporal кластер, но гибких возможностей выстраивать политику кто и что может, вроде как, нельзя. Поэтому сервисы практически бесконтрольно могут дёргать друг-друга.
Странный тезис.
Что мешает передавать в аргументах любую авторизационную информацию и проверять ее в провайдерах? В случае ошибки - бросать Non retryable exception.
Сигнатуры методов workflow и activity в идеале не должны меняться.
Аналогично.
Любые сигнатуры - это API. Что внешний API (например REST), что внутренний API (например IoC) налагают требования по контролю целостности API со стороны консьюмера и провайдера. Темпорал в этом плане ничего нового не привносит.
Оверхед на код — придётся писать больше кода, но во времена copilot-а это не такая уж и серьезная проблема.
Оверхед по сравнению с совсем простым кодом - без перевызова, без таймаутов, без альтернативных сценариев, без ролбеков.
А если сравнивать код со всем этим, в двух реализациях - с темпорал и без, то код с темпорал существенно меньше.
В целом, Temporal - must have инструмент, в микросервисной архитектуре.
Что мешает передавать в аргументах любую авторизационную информацию и проверять ее в провайдерах? В случае ошибки - бросать Non retryable exception.
В провайдерах проверять — можно. Я имел ввиду, что нет общего компонента, который бы авторизовывал вызовы между сервисами на основе заголовков/директив и т.п.
Темпорал в этом плане ничего нового не привносит.
По сравнению с REST и GQL, которым мы пользуемся сейчас, Temporal работает без схемы (OpenAPI, GQL и т.п.) поэтому следить за контрактами будет сложнее. Наверное так можно переформулировать "минус" про сигнатуры.
Мутации в микросервисах: применяем Temporal