Temporal ці Inngest: надзейнасць патрабуе кластара або залежнасці ад сэрвісу

Temporal і Inngest дазваляюць аднавіць працяглы ШІ-працэс пасля збою, але размяркоўваюць адказнасць па-рознаму. Схема вытворчага разгортвання Temporal прадугледжвае асобны сэрвіс выканання — уласны або Temporal Cloud — і worker-працэсы з кодам каманды. Гэта выбар для тых, хто гатовы падтрымліваць worker-працэсы і хоча выразна аддзяліць іх ад сэрвісу, які захоўвае ход працы.

Inngest бліжэй да каманды, якая ўжо запускае функцыі на serverless-хосцінгу: у мадэлі працяглых працэсаў Inngest платформа захоўвае вынікі крокаў, паўтарае няўдалую працу і прыпыняе вылічэнне на час чакання падзеі. Пры кіраваным разгортванні стан і каардынацыя залежаць ад Inngest. Абедзве сістэмы маюць іншыя спосабы разгортвання, таму вызначальным становіцца не назва платформы, а тое, хто падтрымлівае кожную частку працэсу.

Што менавіта аднаўляецца пасля збою

Temporal захоўвае гісторыю падзей працэсу. Калі worker спыніўся, іншы worker можа атрымаць задачу, прайграць код працэсу паводле гісторыі і аднавіць яго стан. Вынікі завершаных дзеянняў бяруцца з запісанай гісторыі; самі гэтыя дзеянні падчас прайгравання не выклікаюцца зноў. Няўдалае дзеянне можа атрымаць новую спробу паводле налад паўтораў.

У Inngest мяжа аднаўлення праходзіць праз названыя крокі. Пасля паспяховага кроку яго вынік захоўваецца; калі пазнейшая праца дае збой або працэс чакае падзеі, завершаны крок вяртае гэты вынік без паўторнага выкліку свайго кода. Пры звычайным паслядоўным выкананні крокаў апрацоўшчык не абавязкова запускаецца нанова пасля кожнага з іх, але пасля паўзы ці памылкі яго код можа прайсці з пачатку.

Для агента гэта азначае, што выклік мадэлі, зварот да інструмента і запіс выніку варта падзяляць там, дзе патрэбныя асобныя паўторы і зразумелая гісторыя. Ёсць агульная мяжа абедзвюх гарантый: знешні сэрвіс можа паспець прыняць запыт, а аркестратар — яшчэ не зафіксаваць поспех. Пры наступнай спробе запыт паўторыцца, таму запіс, адпраўка паведамлення або аплата патрабуюць ключа ідэмпатэнтнасці ці іншага спосабу распазнаць ужо выкананае дзеянне.

Чаканне пацвярджэння без адкрытага запыту

У Temporal працэс можа чакаць сігналу або таймера: сэрвіс захоўвае яго стан і стварае новую задачу для worker, калі надыходзіць адпаведная падзея. У Inngest чаканне падзеі прыпыняе функцыю, а падыходная падзея або заканчэнне зададзенага тэрміну вяртае яе да працы. Працягласць усяго працэсу таму не роўная часу аднаго актыўнага выкліку функцыі ці дзеяння.

Умоўны прыклад: агент падрыхтаваў прапанову, чакае адказу менеджара і толькі пасля пацвярджэння адпраўляе яе ў знешнюю сістэму. Адказ трэба суаднесці з канкрэтным запытам, а адпраўку зрабіць асобным аднаўляльным дзеяннем. Што рабіць пасля заканчэння тэрміну чакання — закрыць запыт, нагадаць чалавеку або перадаць рашэнне іншаму ўдзельніку — вызначае логіка каманды.

Хто падтрымлівае сэрвіс, сховішча і вылічэнні

Пры самастойным разгортванні Temporal каманда адказвае за сэрвіс выканання, яго сховішча, абнаўленні і даступнасць, а таксама за свае worker-працэсы. Temporal Cloud бярэ на сябе эксплуатацыю сэрвісу, але код працэсаў і дзеянняў усё роўна трэба разгортваць і маштабаваць. Таму для ацэнкі кошту важныя не толькі выдаткі на хостынг: патрэбныя людзі, якія будуць падтрымліваць чаргі, worker-працэсы і аднаўленне пасля аварыі.

Кіраваны Inngest пакідае вылічэнне функцый у асяроддзі каманды, а стан запуску, чаргу і паўторы вядзе платформа. Уласнае разгортванне таксама існуе: кіраўніцтва Inngest па self-host апісвае сервер, убудаванае сховішча чаргі, SQLite для захавання даных і падключэнне знешніх Redis ды PostgreSQL для большай інсталяцыі. Там жа аднасерверны рэжым пазначаны як beta. Для каманды, якая патрабуе ўласнага контуру, гэты варыянт здымае залежнасць ад кіраванай платформы, але перадае ёй эксплуатацыю чаргі, стану і рэзервовага аднаўлення.

Абмежаванні хостынгу датычацца актыўнага кроку, нават калі ўвесь працэс працягваецца днямі. Кароткі выклік мадэлі можа змясціцца ў serverless-функцыю; доўгае вылічэнне давядзецца разбіць або запусціць у іншым асяроддзі. Serverless Workers у Temporal цяпер даюць спосаб запускаць worker на AWS Lambda і GCP Cloud Run у статусе Public Preview. Гэта пашырае выбар для serverless-каманды, але захоўвае мадэль задач Temporal і патрабуе ўлічваць абмежаванні абранага пастаўшчыка вылічэнняў.

Як змена кода ўплывае на незавершаны працэс

Пры прайграванні Temporal код працэсу павінен прыходзіць да рашэнняў, сумяшчальных з захаванай гісторыяй. Зварот да мадэлі, базы даных або знешняга API належыць выносіць у дзеянні, вынікі якіх запісваюцца ў гісторыю. Калі новая версія кода інакш выбірае парадак дзеянняў, незавершаны працэс можа не прайсці прайграванне. Таму разгортванне новай логікі патрабуе плана для ўжо запушчаных працэсаў.

Inngest не прайграе ўвесь працэс паводле такіх жа правілаў, але яго крокі таксама маюць стабільную структуру. Код па-за захаваным крокам можа выканацца зноў пасля аднаўлення; пабочны эфект у гэтым месцы лёгка паўтарыць выпадкова. Назвы крокаў служаць для супастаўлення з захаванымі вынікамі, таму іх перайменаванне падчас незавершаных запускаў можа змяніць паводзіны. У абедзвюх мадэлях версія кода — частка плана аднаўлення, а не толькі пытанне зручнасці разгортвання.

Што бачна падчас інцыдэнту

Гісторыя Temporal паказвае падзеі працэсу, задачы і спробы дзеянняў. Траса запуску Inngest паказвае крокі, чаканні, паўторы і памылкі. Гэтыя звесткі дапамагаюць адрозніць працэс, які чакае чалавека, ад працэсу, што стаіць у чарзе або паўтарае няўдалы выклік.

Аркестратар, аднак, бачыць толькі свой бок мяжы са знешняй сістэмай. Для разбору дубляванай адпраўкі або спрэчнага запісу карысна звязваць ідэнтыфікатар бізнес-аперацыі з запускам і з адказам знешняга API. Тады можна высветліць, ці неадназначнасць узнікла да выканання дзеяння, падчас яго або перад захаваннем выніку.

Дрэва рашэнняў для каманды

• Функцыі ўжо працуюць на serverless-хосцінгу. Inngest адпавядае гэтай схеме, калі актыўныя крокі ўкладаюцца ў ліміты хостынгу і каманда прымае залежнасць ад сэрвісу каардынацыі. Temporal таксама варта ацаніць, калі патрэбна яго мадэль гісторыі; для serverless workers трэба асобна ўлічыць статус Public Preview і ўмовы вылічальнай платформы.
• Патрэбны рэгуляваны ўласны контур. Самастойны Temporal мае сэнс пры гатоўнасці падтрымліваць сэрвіс і worker-працэсы. Самастойны Inngest дазваляе захаваць мадэль функцый і крокаў, але патрабуе праверыць прыдатнасць канкрэтнай версіі сервера, устойлівасць сховішча і працэдуру аднаўлення.
• Агент працуе некалькі дзён і чакае чалавека. Абедзве платформы могуць спыніць актыўнае вылічэнне да наступнай падзеі. Рашэнне больш залежыць ад межаў паўтору, абнаўлення кода незавершаных запускаў і таго, ці можна бяспечна паўтарыць дзеянне ў знешнім сэрвісе.

Пры пераносе працэсу паміж платформамі зручнай мяжой служыць завершаная бізнес-аперацыя. Варта зафіксаваць, якія знешнія эфекты ўжо адбыліся, і запускаць астатнюю працу з ранейшымі ключамі ідэмпатэнтнасці. Унутраныя гісторыі Temporal і захаваныя крокі Inngest адрозніваюцца; план міграцыі павінен абапірацца на стан бізнес-запыту, а не на меркаванне, што адзін механізм прачытае запіс другога.

Што дадае апытанне, а чаго яно не вырашае

У апытанні Inngest за 2026 год удзельнічалі 130 інжынераў, 56% рэспандэнтаў выкарыстоўвалі больш за адзін інструмент аркестрацыі, а група карыстальнікаў толькі Temporal складалася з трох чалавек. Аўтары не палічылі апошнюю групу дастатковай для асобнага надзейнага параўнання.

Гэта апытанне пастаўшчыка апісвае інструменты і досвед рэспандэнтаў, але не вымярае для аднолькавай нагрузкі кошт эксплуатацыі, час аднаўлення або надзейнасць дзвюх платформаў. Яго карысны сігнал для выбару — у рэальных каманд часта суіснуюць некалькі механізмаў. Таму адзін доўгі працэс варта ацэньваць па ўласных межах адказнасці і збояў, а не выводзіць пераможцу з долі выкарыстання.

Чытайце таксама:

• RAGAS ці DeepEval: больш метрык не гарантуе надзейнай ацэнкі RAG
• Docker Compose ці Kubernetes: 0,7 секунды супраць аркестрацыі кластара
• Агент прайшоў адзін тэст — гэта яшчэ не надзейнасць: запускайце серыі