workflow-engine-doc

Описание проблематики

В текущей реализации процессинга центральное место занимает Machinegun (MG). При его создании заявлялись следующие цели (см. Readme https://github.com/valitydev/machinegun):

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

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

• глубокая интеграция именно с риаком осложняет поддержку альтернативных хранилищ
• реализация распределённого функционирования на основе кластера с координацией работы на уровне приложения обеспечивает высокую доступность, но ограничивает возможности горизонтального масштабирования (проблема не в координации вообще, а в конкретной реализации)
• контроль собственных ресурсов значительно усложняет код, но фактически не применяется, а при включении его эффективность неочевидна (возможно не хватило статистических данных)
• общая проблема - чрезмерная переусложнённость кода не соответствующая сложности решаемой задачи, что приводит к невозможности его быстрой модификации/адаптации/развития
• "удобство" автоматной логики оказалось переоценённым, так как ни бизнес-саппорт, ни команда разработки не рассуждают о бизнес-сущностях в терминах состояний и переходов, а собственно автоматной логики нет ни в MG, ни сервисах-процессорах (см. ниже о распределении логики)

Каждый из этих недостатков в отдельности не является критичным, но совокупность эффектов делает невозможной эффективную поддержку MG.

Каждая бизнес-сущность в процессинге, представляет собой совокупность операций, которые нужно выполнить для достижения конечного результата. Удобство автоматов в данном контексте заключается в возможности определить перечень состояний и "разрешенные" и "неразрешённые" шаги автомата (переходы) в определённом состоянии. Но, как указывалось выше, собственно автоматной логики в MG нет, он не знает про состояние машины (за это отвечает сервис-процессор). То есть в текущей реализации автоматная логика распределена следующим образом: сервис-процессор реализует и бизнес-логику самих шагов, и логику переходов между ними (выбора следующего шага), а MG только обеспечивает персистентность и регулярный вызов процессора. При этом само состояние автомата - это некий виртуальный параметр, который вычисляется как результат свёртки всей истории событий машины при каждом вызове процессора. То есть, если объединить эти факты, то мы имеем следующее:

• в логике MG автомата нет, есть только операции сохранения истории машины и планирования вызова процессора
• в логике сервиса-процессора автомата нет, есть история событий, которую он анализирует на каждом шаге для того, чтобы выбрать следующий шаг

То есть бизнес-сущности удобнее представляются в виде заданной последовательности шагов (с ветвлениями и циклами), где выбор каждого следующего шага зависит от результата предыдущего. Для такой обработки лучше подходят термины пайплайн, флоу, процесс и т.п.

Примечание: для решения такого типа задач в индустрии часто применяются продукты класса workflow engine. Основное отличие любого workflow engine от MG в том, что они реализуют всю совокупность шагов, то есть содержат полную информацию обо всех шагах и переходах между ними, но не реализуют логику самих шагов (то есть MG - это вырожденный случай workflow engine, который реализует только один и тот же шаг в цикле). В рамках решаемой задачи не требуется менять статус-кво и перераспределять функциональность между сервисами-процессорами и MG, но иметь возможность развиваться в данном направлении можно учитывать. Такой подход позволил бы обеспечить точку коммуникации между аналитиками, саппортом и разработкой за счет единого подхода к описанию бизнес-сущностей.

В рамках устоявшейся практики MG решает следующие задачи:

• создание машин
• получение/удаление машин
• планирование вызова и вызов процессора (вызов по расписанию)
• сохранение результатов каждого шага процессора (результатов вызова)
• вызов процессора по требованию/отправка сигнала процессору
• высокая доступность посредством распределённого кластера
• нотификация о прогрессе машин посредством публикации сообщений в Kafka

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

Обработка нестандартных ситуаций в этом списке "спрятана" под планированием вызова, так как при получении ошибок MG планирует повторный вызов процессора в соответствии с настройками.

Постановка задачи

• Сформулировать и зафиксировать бизнес и функциональные требования к MG (это требования постфактум, но сейчас они нигде на зафиксированы)
• Описать уже существующие и фактически используемые сценарии применения MG
• При необходимости актуализировать сценарии под новые внешние требования (возможные точки роста: более гибкая работа с retry policy, возможность выбора разных процессоров на разных шагах (задел для реализации классического workflow engine))
• Оптимизировать код MG, сделать слой его функциональности более "тонким" (оптимизация дизайна, правильное разделение на составляющие компоненты, упрощение самих компонентов), что позволит снизить порог входа и улучшит поддерживаемость кода

Термины и определения

Машина как объект - append only история событий + некоторый мутабельный статус, а с точки зрения клиента машина - это конкретный экземпляр бизнес-сущности (в дальнейшем предполагается переход на более интуитивно понятный термин), т.е. машина-объект - это данные конкретного экземпляра бизнес сущности.

Машина как процесс - control plane для бизнес-сущности, он обеспечивает персистентность машины-объекта, а также обеспечивает прогресс бизнес-сущности путем регулярного (планируемого) вызова процессора.

Процессор - сервис, реализующий бизнес логику шагов и переходов между ними для конкретной бизнес-сущности.

Автомат - совокупность машины-объекта (data), машины-процесса (control plane) и процессора (business logic plane).

Бизнес-сущность (бизнес-процесс) - платёж/перевод/выплата