Zeebe — это движок BPMN, который проводит каждый экземпляр процесса через сеть из партиций и брокеров, как диспетчер разводит поезда по путям: без общей базы данных, без единой точки отказа, с масштабированием по горизонтали.
Zeebe — это открытый движок оркестрации процессов, написанный на Java и работающий по протоколу gRPC. Он исполняет диаграммы BPMN 2.0 и является ядром Camunda 8 — как в облачной версии SaaS, так и в self-managed развёртывании на Kubernetes.
В отличие от Camunda 7, где движок встроен в JVM-приложение и опирается на реляционную БД, Zeebe хранит состояние в собственном журнале событий на базе RocksDB и реплицирует его между узлами по протоколу Raft — это и даёт горизontальное масштабирование без единой точки отказа.
Каждый экземпляр процесса — это токен, идущий по графу BPMN: от стартового события через задачи и шлюзы до завершения. Zeebe продвигает токен, публикуя события в журнал, а не блокируя строки в таблице.
Zeebe не хранит процессы в общей таблице. Пространство состояний делится на партиции, каждая — со своим журналом. Партиция реплицируется на несколько брокеров: один ведёт запись (лидер), остальные держат копию наготове (последователи).
Каждый экземпляр процесса живёт на одной партиции. Больше партиций — выше суммарная пропускная способность кластера.
Если брокер с лидером партиции падает, один из последователей избирается новым лидером за секунды.
Состояние партиции — это её собственный append-only журнал в RocksDB, а не строки в общей реляционной схеме.
Для сценариев, где процесс живёт часами, днями или неделями, и где важно видеть, на каком шаге он застрял.
Ожидание таймера, сообщения от внешней системы или ручного согласования не занимает поток — процесс просто ждёт в журнале, пока не придёт нужное событие.
Бизнес-логика выполняется вне движка, в собственных сервисах на любом языке — они подключаются как job-воркеры по gRPC и забирают задачи нужного типа.
Диаграмма процесса — не картинка для документации, а исполняемый артефакт. Разработчик, аналитик и аудитор смотрят на одну и ту же схему.
Пропускная способность растёт добавлением партиций и брокеров, без остановки кластера и без миграции схемы.
Воркер подписывается на тип задачи и обрабатывает её, когда движок продвигает до него токен процесса.
const { ZBClient } = require('zeebe-node');
const zbc = new ZBClient();
zbc.createWorker({
taskType: 'provision-account',
taskHandler: async (job) => {
// бизнес-логика воркера
const accountId = await openAccount(job.variables);
return job.complete({ accountId });
},
});# развернуть диаграмму процесса в кластер
zbctl deploy resource onboarding.bpmn
# запустить новый экземпляр процесса
zbctl create instance onboarding \
--variables '{"applicantId":"a-1042"}'
# посмотреть топологию кластера
zbctl status