Дорожная карта
Что мы собираемся сделать в go-bpm. План составлен в порядке важности и сложности задач: сначала то, что нужнее всего и делается быстрее, дальше — более трудоёмкое. Задачи разбиты на этапы, цвет карточки показывает сложность. Сделанное остаётся на своём месте зачёркнутым, со ссылкой на документацию.
Это план, а не обещание сроков. Что уже работает сегодня — в документации; что не поддерживается — в Моделировании BPMN. Предложения и приоритеты обсуждаем в issues на GitHub.
Этап 1. Документация#
Ответы на вопросы, которые архитектор задаёт первыми. Код движка не меняется.
Семантика исполнения
Доставка «как минимум один раз», аренда задач, что повторяется при сбое, почему методы и обработчики должны быть идемпотентными, что выносить в service task.
Ожидание внешних событий
Когда ждать сообщение, когда — задачу пользователя, которую закрывает система через API, а когда опрашивать из service task: примеры и подводные камни.
Безопасность
Как закрыть API и консоль своим middleware, откуда брать пользователя задач, что не класть в переменные процесса.
Изменение процессов
Что можно менять при живых экземплярах, как удалять элементы, как запустить несовместимую версию рядом со старой на KindPrefix.
Референсная архитектура
Сервис с go-bpm в Kubernetes: с отдельной базой движка и с общей базой сервиса, плюсы и минусы обоих вариантов.
Переход с Camunda 7
Что переносится (схемы, таблицы DMN), что переписывается (Java-делегаты, выражения), как жить с экземплярами в пути.
Этап 2. Эксплуатация и безопасность#
Небольшие доработки движка, после которых go-bpm можно выводить в продакшен без самописной обвязки.
Метрики Prometheus
Пакет metrics на client_golang: задачи очереди по статусам, возраст самой старой задачи, экземпляры по статусам, открытые задачи пользователей, время попыток.
Авторизация API и консоли
Функция, которая по запросу возвращает пользователя и его группы; API задач берёт исполнителя из неё, а не из тела запроса.
Журнал операций
Кто и когда повторил упавшую задачу, исправил переменные, отменил экземпляр — в таблице и в истории экземпляра.
Очистка истории
engine.Retention удаляет завершённые и отменённые экземпляры старше срока хранения вместе с историей, правилами DMN и задачами пользователей.
Хуки движка
engine.Hooks: событие элемента, обёртка вокруг кода сервиса — точка подключения OpenTelemetry, — и падение экземпляра для алертов.
Безопасность поставки
govulncheck в CI, SBOM и provenance образа, подпись образа cosign без ключей.
Этап 3. Недостающий BPMN#
Новые элементы поверх механизмов, которые в движке уже есть: точек ожидания, задач очереди и гонки задачи с граничным таймером.
Сообщения с корреляцией по бизнес-ключу
Receive task и промежуточное событие ждут сообщение из POST /api/v1/messages или из Go. Ключ — бизнес-ключ или переменная, ранний ответ ждёт подписку ttl.
Граничный таймер у задачи пользователя
Эскалация по сроку: задачу не завершили за день — она отменяется, процесс уходит другой веткой.
В документацииГраничные события у call activity и подпроцесса
Таймер и ошибка на вызове процесса или подпроцессе: срок и обработка ошибки на всю вложенную часть.
Непрерывающий граничный таймер
Напоминание или уведомление по сроку без прерывания задачи.
Таймер timeDate
«До 9:00 1 декабря»: дата RFC 3339 или переменная процесса — у промежуточного и граничного таймера.
В документацииТаймер timeCycle
«Каждый час»: повторяющийся таймер для напоминаний и старта по расписанию.
Секционирование истории
bpm_history по времени: очистка удалением секций и предсказуемый рост таблиц.
Нагрузочный тест на сервере
Несколько экземпляров сервиса на одной базе, задержки p99, переключение PostgreSQL на реплику.
Этап 4. Сложный BPMN#
Здесь меняется модель исполнения: движок начинает считать токены и откатывать уже выполненные шаги.
Последовательный multi-instance
Задача, подпроцесс или call activity выполняется несколько раз подряд: число выполнений и условие завершения — «согласовать до трёх кругов».
В документацииПараллельный multi-instance
Выполнения одновременно и по элементам коллекции: «согласовать у всех из списка», «запросить все банки и дождаться ответов».
Компенсации
Откат саги средствами BPMN: компенсирующие задачи вместо ручных веток отката.
Inclusive и event-based gateway
Несколько веток по условиям; ожидание первого из событий — сообщения или таймера.
Старт и прерывание по сообщению
Процесс стартует по входящему событию; граничное событие сообщения прерывает задачу.
Атрибуты Camunda 7 в генераторе
Перенос схем Camunda 7 (camunda:*) без перерисовки в моделере Camunda 8.
Чего не будет#
Это не пробелы, а решения, на которых построен go-bpm.
- Деплоя BPMN без релиза сервиса. Процесс — исходник: он проверяется компилятором, тестами и ревью и выкатывается вместе с кодом, который его исполняет.
- Других СУБД. Очередь, транзакции шагов и блокировки построены на PostgreSQL.
- Других языков. go-bpm — библиотека для Go-сервисов; процессы других сервисов вызываются из service task.