История изменений

Здесь автор расписывает идею описания персистентного отказоустойчивого алгоритма. Правда, я пока что не понял, как происходит координация между этими самыми персистентными алгоритмами.

Я не очень понял про алгоритмы, но как оно работает - я понял. Вкратце распишу, идея интересная и нетривиальная.

1. Есть функции workflow. Пишется на любом (из поддерживаемых) ЯП, просто кодом. Пример workflow это «обработать заказ», что складывается из «обновить БД заказов», «сделать запрос на склад», «если на складе нет товара то уведомить менеджера и подождать его ответа», «если на складе есть товар то вызвать эндпоинт чтобы этот товар отправили на выдачу» и тд. workflow концептуально может работать сколько угодно времени, хоть секунду, хоть сто лет. По сути это описание бизнес-процесса.

2. Есть функции activity. Тоже пишутся на любом ЯП. С ними в принципе вообще всё просто, функция и функция, параметры приняли, результат отдали. К примеру «сделать хттп запрос», «обновить статус в базе», «положить файл в с3». Они обычно работают относительно быстро.

Параметры и возвращаемое значение там и там должны быть сериализуемы, они их хранят в базе.

Вся суть в функциях workflow. Эти функции с «внешним миром» общаются исключительно через temporal api (у них есть библиотеки для каждого языка). Причём внешним миром является даже запрос текущей даты/времени и рандомного числа.

Каждый такой вызов уходит на сервер. Сервер записывает факт этого вызова, его параметры и возвращаемый результат. Ну и возвращает результат. Это в первый раз.

Потом, к примеру, наш workflow «останавливается» на неделю, пока менеджер не тыкнет кнопочку. Worker, который выполнял workflow, конечно не будет неделю держать запущенным тред, да и вообще он сам может давно завершиться по любой причине. Поэтому через неделю функция workflow запускается заново. Но сервер знает, на каком этапе эта функция «уснула» в прошлый раз. И когда функция спрашивает текущую дату/время или делает хттп запрос, то сервер отвечает ранее сохранённым значением. Т.е. функция быстро доходит до актуального состояния. Ну и продолжает выполнение с этого момента. Все существенные действия workflow фунция должна выполнять через вызов activity.

Иными словами, концептуально, workflow функция не останавливается, а работает один раз, от начала до конца, сколько угодно времени, вне зависимости от того, что серверы «под ней сгорают». Ну а физически это реализуется повторными запусками этой функции.

А activity функции в целом никаких ограничений не имеют. Ну разве что идемпотентность желательна. Но не обязательна, как я понял. При вызове activity настраиваются политики retry-ев. Если activity не сработало по какой-то причине (вернуло ошибку или сервер, где она была запущена, сгорел), то temporal её запустит повторно, ну или вернёт ошибку в workflow, если повторы уже невозможны, а там бизнес логика уже должна решать, что делать в такой ситуации.

Поэтому ограничения на workflow функцию есть. Ей нельзя пользоваться API с недетерминированным результатом (к примеру перебирать hashmap в неизвестном порядке), ей нельзя спрашивать внешний мир кроме как через API темпорала или через активити. А также нужно очень вдумчиво подходить к изменениям этой функции, т.к. если у нас есть запущенные workflow, то они должны быть совместимы с изменённой функцией.

Вот как-то так. А надёжность достигается, как я понимаю, по сути перекладыванием её на программиста. workflow функции должны быть детерминированы, activity функции должны быть идемпотенты. А temporal просто следует относительно простому алгоритму.

Поэтому такую систему, по большому счёту, можно на коленке за неделю сваять. Ну в виде proof of concept. Ценность именно temporal в том, что это уже третье поколение системы такого рода, в том, что там есть SDK для кучки языков, в том, что там есть красивый дэшбоард, где можно систему обозревать и смотреть, где какие ошибки, ну и там есть ещё некоторые фичи, но они уже не так критичны и концептуальны.

То бишь под temporal.io в первую очередь я понимаю класс систем, построенных на этой идее. Это Amazon SWF (первая система), Cadence (повтор этой системы в Uber), ну и Temporal, который сделали те, кто делал Cadence и решили из него свой маленький стартап организовать. А во вторую очередь я уже понимаю конкретно этот проект, т.к. в целом он выглядит более чем готовым к продакшну.

Здесь автор расписывает идею описания персистентного отказоустойчивого алгоритма. Правда, я пока что не понял, как происходит координация между этими самыми персистентными алгоритмами.

Я не очень понял про алгоритмы, но как оно работает - я понял. Вкратце распишу, идея интересная и нетривиальная.

1. Есть функции workflow. Пишется на любом (из поддерживаемых) ЯП, просто кодом. Пример workflow это «обработать заказ», что складывается из «обновить БД заказов», «сделать запрос на склад», «если на складе нет товара то уведомить менеджера и подождать его ответа», «если на складе есть товар то вызвать эндпоинт чтобы этот товар отправили на выдачу» и тд. workflow концептуально может работать сколько угодно времени, хоть секунду, хоть сто лет.

2. Есть функции activity. Тоже пишутся на любом ЯП. С ними в принципе вообще всё просто, функция и функция, параметры приняли, результат отдали. К примеру «сделать хттп запрос», «обновить статус в базе», «положить файл в с3». Они обычно работают относительно быстро.

Параметры и возвращаемое значение там и там должны быть сериализуемы, они их хранят в базе.

Вся суть в функциях workflow. Эти функции с «внешним миром» общаются исключительно через temporal api (у них есть библиотеки для каждого языка). Причём внешним миром является даже запрос текущей даты/времени и рандомного числа.

Каждый такой вызов уходит на сервер. Сервер записывает факт этого вызова, его параметры и возвращаемый результат. Ну и возвращает результат. Это в первый раз.

Потом, к примеру, наш workflow «останавливается» на неделю, пока менеджер не тыкнет кнопочку. Worker, который выполнял workflow, конечно не будет неделю держать запущенным тред, да и вообще он сам может давно завершиться по любой причине. Поэтому через неделю функция workflow запускается заново. Но сервер знает, на каком этапе эта функция «уснула» в прошлый раз. И когда функция спрашивает текущую дату/время или делает хттп запрос, то сервер отвечает ранее сохранённым значением. Т.е. функция быстро доходит до актуального состояния. Ну и продолжает выполнение с этого момента. Все существенные действия workflow фунция должна выполнять через вызов activity.

Иными словами, концептуально, workflow функция не останавливается, а работает один раз, от начала до конца, сколько угодно времени, вне зависимости от того, что серверы «под ней сгорают». Ну а физически это реализуется повторными запусками этой функции.

А activity функции в целом никаких ограничений не имеют. Ну разве что идемпотентность желательна. Но не обязательна, как я понял. При вызове activity настраиваются политики retry-ев. Если activity не сработало по какой-то причине (вернуло ошибку или сервер, где она была запущена, сгорел), то temporal её запустит повторно, ну или вернёт ошибку в workflow, если повторы уже невозможны, а там бизнес логика уже должна решать, что делать в такой ситуации.

Поэтому ограничения на workflow функцию есть. Ей нельзя пользоваться API с недетерминированным результатом (к примеру перебирать hashmap в неизвестном порядке), ей нельзя спрашивать внешний мир кроме как через API темпорала или через активити. А также нужно очень вдумчиво подходить к изменениям этой функции, т.к. если у нас есть запущенные workflow, то они должны быть совместимы с изменённой функцией.

Вот как-то так. А надёжность достигается, как я понимаю, по сути перекладыванием её на программиста. workflow функции должны быть детерминированы, activity функции должны быть идемпотенты. А temporal просто следует относительно простому алгоритму.

Поэтому такую систему, по большому счёту, можно на коленке за неделю сваять. Ну в виде proof of concept. Ценность именно temporal в том, что это уже третье поколение системы такого рода, в том, что там есть SDK для кучки языков, в том, что там есть красивый дэшбоард, где можно систему обозревать и смотреть, где какие ошибки, ну и там есть ещё некоторые фичи, но они уже не так критичны и концептуальны.

То бишь под temporal.io в первую очередь я понимаю класс систем, построенных на этой идее. Это Amazon SWF (первая система), Cadence (повтор этой системы в Uber), ну и Temporal, который сделали те, кто делал Cadence и решили из него свой маленький стартап организовать. А во вторую очередь я уже понимаю конкретно этот проект, т.к. в целом он выглядит более чем готовым к продакшну.

Здесь автор расписывает идею описания персистентного отказоустойчивого алгоритма. Правда, я пока что не понял, как происходит координация между этими самыми персистентными алгоритмами.

Я не очень понял про алгоритмы, но как оно работает - я понял. Вкратце распишу, идея интересная и нетривиальная.

1. Есть функции workflow. Пишется на любом (из поддерживаемых) ЯП, просто кодом.

2. Есть функции activity. Тоже пишутся на любом ЯП. С ними в принципе вообще всё просто, функция и функция, параметры приняли, результат отдали.

Параметры и возвращаемое значение там и там должны быть сериализуемы, они их хранят в базе.

Вся суть в функциях workflow. Эти функции с «внешним миром» общаются исключительно через temporal api (у них есть библиотеки для каждого языка). Причём внешним миром является даже запрос текущей даты/времени и рандомного числа.

Каждый такой вызов уходит на сервер. Сервер записывает факт этого вызова, его параметры и возвращаемый результат. Ну и возвращает результат. Это в первый раз.

Потом, к примеру, наш workflow «останавливается» на неделю, пока менеджер не тыкнет кнопочку. Worker, который выполнял workflow, конечно не будет неделю держать запущенным тред, да и вообще он сам может давно завершиться по любой причине. Поэтому через неделю функция workflow запускается заново. Но сервер знает, на каком этапе эта функция «уснула» в прошлый раз. И когда функция спрашивает текущую дату/время или делает хттп запрос, то сервер отвечает ранее сохранённым значением. Т.е. функция быстро доходит до актуального состояния. Ну и продолжает выполнение с этого момента. Все существенные действия workflow фунция должна выполнять через вызов activity.

Иными словами, концептуально, workflow функция не останавливается, а работает один раз, от начала до конца, сколько угодно времени, вне зависимости от того, что серверы «под ней сгорают». Ну а физически это реализуется повторными запусками этой функции.

А activity функции в целом никаких ограничений не имеют. Ну разве что идемпотентность желательна. Но не обязательна, как я понял. При вызове activity настраиваются политики retry-ев. Если activity не сработало по какой-то причине (вернуло ошибку или сервер, где она была запущена, сгорел), то temporal её запустит повторно, ну или вернёт ошибку в workflow, если повторы уже невозможны, а там бизнес логика уже должна решать, что делать в такой ситуации.

Поэтому ограничения на workflow функцию есть. Ей нельзя пользоваться API с недетерминированным результатом (к примеру перебирать hashmap в неизвестном порядке), ей нельзя спрашивать внешний мир кроме как через API темпорала или через активити. А также нужно очень вдумчиво подходить к изменениям этой функции, т.к. если у нас есть запущенные workflow, то они должны быть совместимы с изменённой функцией.

Вот как-то так. А надёжность достигается, как я понимаю, по сути перекладыванием её на программиста. workflow функции должны быть детерминированы, activity функции должны быть идемпотенты. А temporal просто следует относительно простому алгоритму.

Поэтому такую систему, по большому счёту, можно на коленке за неделю сваять. Ну в виде proof of concept. Ценность именно temporal в том, что это уже третье поколение системы такого рода, в том, что там есть SDK для кучки языков, в том, что там есть красивый дэшбоард, где можно систему обозревать и смотреть, где какие ошибки, ну и там есть ещё некоторые фичи, но они уже не так критичны и концептуальны.

То бишь под temporal.io в первую очередь я понимаю класс систем, построенных на этой идее. Это Amazon SWF (первая система), Cadence (повтор этой системы в Uber), ну и Temporal, который сделали те, кто делал Cadence и решили из него свой маленький стартап организовать. А во вторую очередь я уже понимаю конкретно этот проект, т.к. в целом он выглядит более чем готовым к продакшну.

Здесь автор расписывает идею описания персистентного отказоустойчивого алгоритма. Правда, я пока что не понял, как происходит координация между этими самыми персистентными алгоритмами.

Я не очень понял про алгоритмы, но как оно работает - я понял. Вкратце распишу, идея интересная и нетривиальная.

1. Есть функции workflow. Пишется на любом (из поддерживаемых) ЯП, просто кодом.

2. Есть функции activity. Тоже пишутся на любом ЯП. С ними в принципе вообще всё просто, функция и функция, параметры приняли, результат отдали.

Параметры и возвращаемое значение там и там должны быть сериализуемы, они их хранят в базе.

Вся суть в функциях workflow. Эти функции с «внешним миром» общаются исключительно через temporal api (у них есть библиотеки для каждого языка). Причём внешним миром является даже запрос текущей даты/времени и рандомного числа.

Каждый такой вызов уходит на сервер. Сервер записывает факт этого вызова, его параметры и возвращаемый результат. Ну и возвращает результат. Это в первый раз.

Потом, к примеру, наш workflow «останавливается» на неделю, пока менеджер не тыкнет кнопочку. Worker, который выполнял workflow, конечно не будет неделю держать запущенным тред, да и вообще он сам может давно завершиться по любой причине. Поэтому через неделю функция workflow запускается заново. Но сервер знает, на каком этапе эта функция «уснула» в прошлый раз. И когда функция спрашивает текущую дату/время или делает хттп запрос, то сервер отвечает ранее сохранённым значением. Т.е. функция быстро доходит до актуального состояния. Ну и продолжает выполнение с этого момента. Все существенные действия workflow фунция должна выполнять через вызов activity.

Иными словами, концептуально, workflow функция не останавливается, а работает один раз, от начала до конца, сколько угодно времени, вне зависимости от того, что серверы «под ней сгорают». Ну а физически это реализуется повторными запусками этой функции.

А activity функции в целом никаких ограничений не имеют. Ну разве что идемпотентность желательна. Но не обязательна, как я понял. При вызове activity настраиваются политики retry-ев. Если activity не сработало по какой-то причине (вернуло ошибку или сервер, где она была запущена, сгорел), то temporal её запустит повторно, ну или вернёт ошибку в workflow, если повторы уже невозможны, а там бизнес логика уже должна решать, что делать в такой ситуации.

Поэтому ограничения на workflow функцию есть. Ей нельзя пользоваться API с недетерминированным результатом (к примеру перебирать hashmap в неизвестном порядке), ей нельзя спрашивать внешний мир кроме как через API темпорала или через активити. А также нужно очень вдумчиво подходить к изменениям этой функции, т.к. если у нас есть запущенные workflow, то они должны быть совместимы с изменённой функцией.

Вот как-то так. А надёжность достигается, как я понимаю, по сути перекладыванием её на программиста. workflow функции должны быть детерминированы, activity функции должны быть идемпотенты. А temporal просто следует относительно простому алгоритму.

Поэтому такую систему, по большому счёту, можно на коленке за неделю сваять. Ну в виде proof of concept. Ценность именно temporal в том, что это уже третье поколение системы такого рода, в том, что там есть SDK для кучки языков, в том, что там есть красивый дэшбоард, где можно систему обозревать и смотреть, где какие ошибки, ну и там есть ещё некоторые фичи, но они уже не так критичны и концептуальны.

Здесь автор расписывает идею описания персистентного отказоустойчивого алгоритма. Правда, я пока что не понял, как происходит координация между этими самыми персистентными алгоритмами.

Я не очень понял про алгоритмы, но как оно работает - я понял. Вкратце распишу, идея интересная и нетривиальная.

1. Есть функции workflow. Пишется на любом (из поддерживаемых) ЯП, просто кодом.

2. Есть функции activity. Тоже пишутся на любом ЯП. С ними в принципе вообще всё просто, функция и функция, параметры приняли, результат отдали.

Параметры и возвращаемое значение там и там должны быть сериализуемы, они их хранят в базе.

Вся суть в функциях workflow. Эти функции с «внешним миром» общаются исключительно через temporal api (у них есть библиотеки для каждого языка). Причём внешним миром является даже запрос текущей даты/времени и рандомного числа.

Каждый такой вызов уходит на сервер. Сервер записывает факт этого вызова, его параметры и возвращаемый результат. Ну и возвращает результат. Это в первый раз.

Потом, к примеру, наш workflow «останавливается» на неделю, пока менеджер не тыкнет кнопочку. Worker, который выполнял workflow, конечно не будет неделю держать запущенным тред, да и вообще он сам может давно завершиться по любой причине. Поэтому через неделю функция workflow запускается заново. Но сервер знает, на каком этапе эта функция «уснула» в прошлый раз. И когда функция спрашивает текущую дату/время или делает хттп запрос, то сервер отвечает ранее сохранённым значением. Т.е. функция быстро доходит до актуального состояния. Ну и продолжает выполнение с этого момента. Все существенные действия workflow фунция должна выполнять через вызов activity.

А activity функции в целом никаких ограничений не имеют. Ну разве что идемпотентность желательна. Но не обязательна, как я понял. При вызове activity настраиваются политики retry-ев. Если activity не сработало по какой-то причине (вернуло ошибку или сервер, где она была запущена, сгорел), то temporal её запустит повторно, ну или вернёт ошибку в workflow, если повторы уже невозможны, а там бизнес логика уже должна решать, что делать в такой ситуации.

Поэтому ограничения на workflow функцию есть. Ей нельзя пользоваться API с недетерминированным результатом (к примеру перебирать hashmap в неизвестном порядке), ей нельзя спрашивать внешний мир кроме как через API темпорала или через активити. А также нужно очень вдумчиво подходить к изменениям этой функции, т.к. если у нас есть запущенные workflow, то они должны быть совместимы с изменённой функцией.

Вот как-то так. А надёжность достигается, как я понимаю, по сути перекладыванием её на программиста. workflow функции должны быть детерминированы, activity функции должны быть идемпотенты. А temporal просто следует относительно простому алгоритму.

Поэтому такую систему, по большому счёту, можно на коленке за неделю сваять. Ну в виде proof of concept. Ценность именно temporal в том, что это уже третье поколение системы такого рода, в том, что там есть SDK для кучки языков, в том, что там есть красивый дэшбоард, где можно систему обозревать и смотреть, где какие ошибки, ну и там есть ещё некоторые фичи, но они уже не так критичны и концептуальны.