Конструктор сценариев в RetailCRM и при чем тут Temporal [Часть 1]
В последнем релизе RetailCRM мы запустили раздел Сценарии. Если объяснять просто, можно накидывать на холсте сложную логику процессов, в первую очередь коммуникации с клиентами через email, чаты, sms, но не только. А чтобы не составлять руками, научили AI-помощника собирать сценарии по вводным от пользователя. Но обо всём по порядку.
Модуль сложный и интересный, кажется, тянет на серию постов.
Расскажу сначала, в чем были технические сложности задачи. Вводные были таковы:
1. Создание и запуск динамических workflow
Пользователь должен сам настроить логику сценария, а мы её выполнить
2. Асинхронное выполнение сценариев
Сценарий должен запуститься по событию и пройти свой путь, не блокируя точку запуска сценария. События могут вызываться часто).
3. Распределенность выполнения сценария
Разные функции RetailCRM физически локализованы в разных сервисах. Созданное решение должно обеспечивать распределенное прохождение разных частей сценария в разных сервисах.
4. Протяженное время выполнения сценария
Должны быть блоки ожидания от нескольких минут до месяцев. Сценарии могут выполняться долго и не должны «ломаться» при деплоях новых версий.
Примеры:
• отправили письмо → ждем час → проверяем, что письмо не открыто → отправляем чат-сообщение
• заказ перешел в статус Выполнен → ждем 3 месяца → проверяем, что за 3 месяца у клиента не было заказов → отправляем каскад имейл/чат/смс с предложением повторить заказ
5. Отказоустойчивость выполнения сценариев
Должна быть заложена обработка неудачного выполнения шагов. Это может быть временная недоступность внешних сервисов (например, email-транспорт), внутренних сервисов, временные ошибки. Возможность задать логику ретраев и времени ожидания выполнения шага.
6. Версионность сценариев
Например, пользователь создал первую версию сценария и запустил её. После этого изменил флоу сценария и запустил обновленную версию. Все срабатывания первой версии, что уже на этапе выполнения, должны не сломаться и довести свою работу до конца.
7. Контекст выполнения сценария
Контекст сценария должен быть наполнен стартовыми данными (объект клиента, данные события) и обогащаться данными выполненных шагов сценария (отправленное ранее письмо и его статус, поставленная задача, созданный/измененный заказ и тд)
⚙️ Почему Temporal?
Под подобные задачи есть класс решений ( https://github.com/cadence-workflow/cadence, https://www.restate.dev/, https://github.com/dbos-inc/dbos-transact-py). Изучая их, мы пришли к https://github.com/temporalio/temporal. За него кстати также активно топят ребята из
https://t.me/php_fart.
Temporal выступает таким мастер-менеджером, который не знает, по какой логике нужно выполнить workflow, не знает, какие элементы workflow надо выполнить, но знает, куда сходить за этими знаниями, и обеспечит выполнение всего, что ему сказали выполнить, в тех местах, где ему указали выполнить.
Что дает Temporal:
• Workflow-as-code — элементы воркфлоу реализуются в коде, что позволяет нам реализовать логику предоставляемых «кубиков» Сценария
• Обширный набор SDK под разные языки. В том числе под наши: PHP и Go
• Отказоустойчивость, настраиваемая политика ретраев и таймаутов
• Масштабируемость — Temporal состоит из нескольких компонентов и каждый из них можно масштабировать
• Observability: API и GUI для просмотра, что происходит в рантайме с детализацией до отдельных шагов workflow
• История выполнений workflow
• Протокол общения gRPC, это быстро
• Self-hosted, open source (MIT) — можно использовать в своем продукте на своих серверах
Temporal — важная, но лишь одна из составляющих решения. Как выглядит архитектура в целом, расскажу в следующих постах.
Кстати, отличный рассказ про Temporal и Сценарии в RetailCRM был от Ивана Чернявцева https://vkvideo.ru/video-211984637_456239031.
🔗
