Мутации в микросервисах: применяем Temporal06.11.2023 13:15

Далее создаём класс, который имплементирует этот интерфейс — в нём и реализуется основная логика нашей надёжной транзакции:

validator = Workflow::newActivityStub(
      OrderApplyValidatorInterface::class,
      ActivityOptions::new()->withStartToCloseTimeout(
        \DateInterval::createFromDateString('3 seconds')
      )
    );

    $this->creator = Workflow::newActivityStub(
      OrderApplyCreator::class,
      //...
    );

    // Пример того, как можно создать activity-стаб для activity,
    // которая реализована в другом сервисе или на другом стеке
    $this->biller = Workflow::newUntypedActivityStub(
      ActivityOptions::new()->withStartToCloseTimeout(
        \DateInterval::createFromDateString('5 seconds')
      )
    );

    $this->chat = Workflow::newActivityStub(
      OrderApplyChatCreatorInterface::class,
      //...
    );
  }

  public function applyForOrder(
    int $orderId,
    string $specId,
    OrderApplyParams $params
  )
  {
    $couldBeApplied = yield $this->validator->couldBeApplied(
      $orderId, $specId, $params
    );
    if (!$couldBeApplied) {
      return new ApplyForOrderResult(null, 1);
    }

    $createResult = yield $this->creator->createApply(
      $orderId, $specId, $params
    );
    if ($createResult->errorCode != 0) {
      return new ApplyForOrderResult(null, $createResult->error_code);
    }

    // Пример того, как можно вызвать activity из другой кодовой базы — по имени.
    $billingResult = yield $this->biller->execute(
      'billApply', 
      [$createResult->apply], 
      BillApplyResult::class // Мапим результат на внутренний класс
    );
    if ($billingResult->errorCode != 0) {
      // 
      // @todo сюда можно добавить логику отката заявки т.к. биллинг не прошёл
      //
      return new ApplyForOrderResult(null, $billingResult->error_code); 
    }

    yield $this->chat->createChat($createResult->apply);

    return new ApplyForOrderResult($createResult->apply);
  }
}

На что здесь стоит обратить внимание:

• При создании activity-стабов можно указать различные настройки — таймауты, рейт-лимиты и т.п.

• Activity могут находиться в разных микросервисах и могут быть написаны на разных языках.

• Конструкцию $foo = yield bar() можно воспринимать как аналогию await в TypeScript или Python. Если интересно, то можно почитать про механику этой непривычной для PHP конструкции.

Создаём и запускаем воркер

Temporal работает через RoadRunner — высокопроизводительный инструмент, позволяющий эффективно запускать PHP-приложения в долгоживущем режиме.

Настраиваем RoadRunner

temporal:
  address: ${хост_порт_temporal_кластера}
  activities:
    num_workers: 8
  
rpc:
  enable: true
  listen: tcp://127.0.0.1:6001

server:
  command: "php worker.php"

Пишем скрипт воркера

newWorker();

// Регистрируем какие workflow будет выполнять воркер
$worker->registerWorkflowTypes(
    ApplyForOrderWorkflow::class    
);

// Аналогично регистрируем activity

$worker->registerActivity(
    OrderApplyValidator::class,
    fn(ReflectionClass $class) => $container->get($class->getName())
);

... 

$worker->registerActivity(
    OrderApplyChatCreator::class,
    fn(ReflectionClass $class) => $container->get($class->getName())
);

$factory->run();

Запускам воркер через RoadRunner и слушаем очередь

Наблюдаем за воркерами

Запускаем workflow

Осталось последнее — добавить запуск workflow в бизнес логику и протестить, что всё работает. Workflow можно запускать синхронно и асинхронно. В нашем случае мы пойдём по синхронному пути т.к. фронтенд пока не готов к асинхронному созданию заявки, а для прототипа достаточно будет и синхронного варианта. Однако, 99% workflow, конечно же, должны работать асинхронно т.к. повторы, задержки и вот это вот всё.

Код синхронного запуска workflow выглядит так:

apply_workflow->applyForOrder(
  $orderId,
  $specId,
  $params
);
...

Тестируем создание заявки

Находим активного специалиста с балансом, заходим под ним в тестовый бекофис и отправляем заявку:

Заявка успешно отправлена, деньги списаны, чат создан:

Идём в GUI Temporal и смотрим на логи нашего workflow:

Обработка падений

Во время работы над прототипом я случайно и намеренно создавал ситуации, при которых workflow не отрабатывал:

• Исключения и ошибки в коде activity.

• Выключенные воркеры.

• Недетерминированный код workflow.

• Ошибка MySQL has gone away т.к. код не был приспособлен к долгоиграющим скриптам.

• и т.п.

Все эти кейсы Temporal успешно отработал, даже сценарии с недетерминированным кодом, а вот так выглядит ошибки в GUI:

Вроде бы всё рассказал, пора подводить итоги.

Плюсы Temporal

Универсальность

• Поддерживает весь наш стек — PHP, TypeScript и Python.

• Позволяет решать широкий класс задач: надёжные мутации, транзакции, отложенные задания, рассылки, кроны, флоу бизнес-моделей и т.п. — всё это можно реализовать через Temporal. Например, особенно взрывает мозг workflow подписок, который работает на протяжении всего жизненного цикла пользователя.

• Текущую бизнес логику довольно легко засунуть в activity и написать императивный алгоритм в workflow. Правда у кода самого workflow есть ограничения, но в activity можно творить всё что угодно.

• Более простой путь по интеграции ML-алгоритмов в наши бизнес-процессы.

• В будущем можно запилить инструмент для продактов, которые смогут в GUI собирать бизнес-сценарии из activity и играть между ними в А/Б тесты.

Надёжность

• Temporal изначально был разработан в Uber, также его используют такие бигтехи как Snap и Netflix — это внушает доверие.

• Если workflow стартовал, то Temporal выполнит его до конца c учётом retry policy. Даже если упали воркеры, отвалились сервисы, что-то пошло не так — workflow будет выполнен.

• Для activity можно определять rate limits и retry policy.

• Ошибки можно обработать в коде workflow и тут же запустить откат-сценарии.

Разные плюшки

Минусы Temporal

Риск развития микросервисного монолита

• Хоть номинально все RPC вызовы и проходят через один Temporal кластер, но гибких возможностей выстраивать политику кто и что может, вроде как, нельзя. Поэтому сервисы практически бесконтрольно могут дёргать друг-друга.

Высокий порог входа

• Разработчикам обязательно нужен онбординг и обучение — едва ли можно сходу разобраться в том, как эффективно «программировать» на Temporal.

• Поскольку Temporal становится одним из основных компонентов инфраструктуры, то devops-ы должны знать все детали и особенности его работы в production, а также уметь быстро чинить проблемы.

Разные неприятности

• Нужно следить за зоопарком воркеров — за статусом, за актуальностью кода и т.п. Это важно как для прода, так и для окружения разработки.

• Код workflow должен быть детерминирован, однако встроенная поддержка версионирования для workflow и воркеров позволяет реализовать обратную совместимость.

• Сигнатуры методов workflow и activity в идеале не должны меняться.

• 99% workflow будут запускаться асинхронно — нужно допиливать клиентов, чтобы статус процесса отображался корректно.

• Оверхед на код — придётся писать больше кода, но во времена copilot-а это не такая уж и серьезная проблема.

Выводы

На уровне прототипа Temporal впечатляет универсальностью и надёжностью. Однако, без осознанного потребления может превратить нормальную распределённую систему в микросервисный монолит со всеми вытекающими.

Очень хочется попробовать — начать с каких-то простых задач и постепенно переходить к чему-то более серьёзному. Если в мы итоге заюзаем этот фреймворк, то я обязательно напишу о реальном опыте в проде.

Спасибо что дочитали!
Пока :)

P.S. Если среди вас есть те, кто уже применяет Temporal, то буду благодарен за кейсы в комментариях.

© Habrahabr.ru