Конструктор сценариев в RetailCRM и при чем тут Temporal [Часть 1]

В последнем релизе RetailCRM мы запустили раздел Сценарии. Если объяснять просто, можно накидывать на холсте сложную логику процессов, в первую очередь коммуникации с клиентами через email, чаты, sms, но не только. А чтобы не составлять руками, научили AI-помощника собирать сценарии по вводным от пользователя. Но обо всём по порядку.

Модуль сложный и интересный, кажется, тянет на серию постов.

Расскажу сначала, в чем были технические сложности задачи. Вводные были таковы:

1. Создание и запуск динамических workflow

Пользователь должен сам настроить логику сценария, а мы её выполнить

2. Асинхронное выполнение сценариев

Сценарий должен запуститься по событию и пройти свой путь, не блокируя точку запуска сценария. События могут вызываться часто).

3. Распределенность выполнения сценария

Разные функции RetailCRM физически локализованы в разных сервисах. Созданное решение должно обеспечивать распределенное прохождение разных частей сценария в разных сервисах.

4. Протяженное время выполнения сценария

Должны быть блоки ожидания от нескольких минут до месяцев. Сценарии могут выполняться долго и не должны «ломаться» при деплоях новых версий.

Примеры:
• отправили письмо → ждем час → проверяем, что письмо не открыто → отправляем чат-сообщение
• заказ перешел в статус Выполнен → ждем 3 месяца → проверяем, что за 3 месяца у клиента не было заказов → отправляем каскад имейл/чат/смс с предложением повторить заказ

5. Отказоустойчивость выполнения сценариев

Должна быть заложена обработка неудачного выполнения шагов. Это может быть временная недоступность внешних сервисов (например, email-транспорт), внутренних сервисов, временные ошибки. Возможность задать логику ретраев и времени ожидания выполнения шага.

6. Версионность сценариев

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

7. Контекст выполнения сценария

Контекст сценария должен быть наполнен стартовыми данными (объект клиента, данные события) и обогащаться данными выполненных шагов сценария (отправленное ранее письмо и его статус, поставленная задача, созданный/измененный заказ и тд)

⚙️ Почему Temporal?

Под подобные задачи есть класс решений (Cadence, Restate, DBOS). Изучая их, мы пришли к Temporal. За него кстати также активно топят ребята из @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 был от Ивана Чернявцева на нашем митапе.

🔗 Инженерия и AI | Ilyas Salikhov