Имеется система, аналогия которой это обработка заказов в магазине или обработка запросов в система типа jira. Некоторыми образами в систему попадает сущность, пусть будет «заказ». Объём - тысячи в день. Далее эта сущность проходит через несколько статусов. Сейчас - чуть больше 10, но число их потихоньку растёт. К примеру после того, как сущность создана, делается запрос в другую систему. Если запрос вернул данные, то данные присоединяются к сущности и переходит в следующий статус. Далее идёт запрос в другой сервис и с сущностью работают там. Там свои статусы. Какие-то переходы это просто запрос в сервис, какие-то переходы это ожидание действий пользователя (может быть до месяца). Переходы могут добавлять данные к сущности, как в примере выше. В конце концов сущность либо архивируется с успехом или по таймауту.
Всё, что выше, это абстрактное описание того, как это всё работает.
Сейчас это примерно 3 сервиса, у каждого своя база. Ну и внешние сервисы, их тоже несколько. Часть переходов между статусов это скедулеры, запускаются раз в полминуты, или в минуту, или в 5 минут. Часть переходов это непосредственно запросы от пользователя.
Некоторые переходы важно повторять. К примеру если сервис лежит, нужно повторять запросы, причём с задержкой желательно по алгоритму, чтобы не дудосить.
Что сейчас плохо:
-
У всего этого нет никакой формы. По сути система выросла исторически, из простой и понятной в некоего монстра. Алгоритмы перехода между статусами мало кто понимает.
-
Всякие повторы и тд реализуются на месте с переменным успехом. Где-то вообще не реализуются. Типа лежит сервис отправки смс, и фиг с ним, не очень-то и нужно. Где-то долбит раз в минуту, в итоге скапливается несколько десятков тысяч заказов, которые из-за чего-то не могут отправиться и система начинает тормозить, пока кто-то не придёт и не разберётся. Где-то сделано по уму, с экспоненциальной задержкой. Хочется, чтобы везде было по уму.
-
Логи. Все логи ведутся ну тупо в лог файлах. Текущее состояние можно посмотреть в базе, истории состояний нет. Проблемы решаются очень долго - надо долго грепать логи (а их очень много, гигабайты в день), копаться в базе, курить сорсы. В общем случае в логах, базах и сорсах нескольких сервисов. От системы хочется, чтобы была возможность найти сущность, посмотреть её историю, в идеале вообще посмотреть - какие запросы делались и какие ответы получались в определённые моменты времени. В общем чтобы суппорт писал «по юзеру иванов не отрабатывается заказ», ты шёл в дашборд, находил «user.name=иванов» его заказ, сразу видел, что он в таком-то статусе, сделал 3 попытки на такой-то сервис, получил такие-то ответы. В общем как-то так.
-
Скорость работы. Из-за того, что скедулеры отрабатывают не моментально и не раз в секунду, а в среднем раз в минуту, каждая смена статуса занимает до минуты, в итоге то, что может сделаться за долю секунды, занимает несколько минут.
-
В целом есть ощущение, что такие системы должны строиться по типовой архитектуре.
Если бы я это делал, я бы сделал как-то так:
- Есть сущность
- У неё есть статус
- К сущности прикрепляются произвольные данные по ключ-значение
- Частью статуса может служить выражение вида
ключ == значение и тд. Ну чтобы не делать комбинаторный взрыв из статусов. Хотя тут спорный момент, может это и не надо.
- Куча сервисов, которые обрабатывают изменения статусов.
- Сервис триггерится либо по изменению статуса, либо по внешнему вызову. С внешним вызовом надо подумать, пока чёткого понимания нет.
При вызове сервиса можно автоматом делать повторы, причём с задержкой нужной, логгирование и тд.
Но в целом я предполагаю, что это велосипед и делать описанное выше не нужно, а нужно понять, что мне нужно.
У меня давным давно был опыт работы с Java фреймворком, который работал с BPMN. Честно говоря я не смог вспомнить его название, наверное это был jbpm. Кажется, что этот фреймворк решал похожую задачу. Там в эклипсе рисовали workflow эдакой блок-схемой, в каждом узле прописывали логику работы. Честно говоря опыт был крайне отрицательный, система была максимально геморройна для работы с ней. Но допускаю, что это была проблема конкретной реализации или старой версии. Поэтому первый кандидат, который я рассматриваю, это фреймворки с BPMN подходом.
Сразу скажу, что нужды рисовать блок-схемы в этом проекте нет. Разрабатывают программисты, по своему опыту скажу, что мне от этих упрощалок одно неудобство. Любой нетривиальный workflow скорей всего превратится в графическое мессиво.
Попытавшись поискать информацию по этой теме я часто встреваю упоминание некоего apache airflow и очень похожих на него продуктов. У меня всё же ощущение, что это похожее, но не то.
Также очень интригующий проект это temporal.io. Я его пока не осилил, он кажется очень непростым и нужно найти время, чтобы понять, что это такое. Но буду благодарен, если кто-то уже его использовал и скажет - то ли это?
Видел, как для похожей задачи применяли n8n. Там работали не программисты, это nocode инструмент. Мне не понравился, но концептуально вроде это тоже решает данную задачу.
Не хочется сложных решений, т.к. команда небольшая и не супер-профессиональная. Хочется решение простое, понятное, но в то же время решающее насущные проблемы.