# 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). Бизнес-сущность (бизнес-процесс) - платёж/перевод/выплата