Camunda 8. Почему не стоит использовать Connectors Bundle

Действительно, Camunda 8 является универсальным инструментом, и его главное преимущество заключается в возможности создания собственных сервисных задач и клиентов на любом языке программирования через GRPC. При работе с Camunda Platform нам доступен удобный инструмент Connectors Bundle, который позволяет быстро создавать клиенты внутри BPMN-схемы, будь то REST, RMQ, Kafka, AWS, Google или даже WhatsApp. Но насколько хорош этот пакет? Мы решили проверить на примере REST-клиента.

В нашей команде во время тестирования мы использовали REST-коннектор, который оказался удобен благодаря быстрой реализации всего одним блоком в BPMN-схеме. Тестирование прошло успешно, появлялось все больше тестовых схемы, но появились вопросы к производительности. Connectors Bundle был один, а схем — несколько. При масштабировании требовался перезапуск коннекторов, при этом их мощность не концентрировалась на конкретной схеме, а распределялась равномерно на все, что было неэффективно.

Поэтому решили создать собственный REST-коннектор, который можно масштабировать под каждую схему отдельно, одновременно попробуем сравнить RPS своего решения с коробочным.

Тестируем REST Connectors Bundle

Для теста будем использовать простую BPMN-схему, в которой будет всего один процесс: запрос favicon с сайта Домклик. В QA-контуре запущен Connectors Bundle с четырьмя нодами.

Тестирование будет запущено в четыре процесса параллельно, по 5 потоков в течение 60 секунд. Схема будет запускаться с ожиданием результата CreateProcessInstanceWithResult.

[0] Case start, processes(workers): 4 threads: 5 all: 20 seconds: 60 [2] Сomplete, count: 1433, avg: 0.041870, rps: 23.8833 [3] Complete, count: 1426, avg: 0.042075, rps: 23.7666 [1] Complete, count: 1434, avg: 0.041841, rps: 23.9 [0] Complete, count: 1402, avg: 0.042796, rps: 23.3666 Total RPS: 94.916666

Можно подумать, что получилось неплохо, но для эксплуатации кажется, что мало.

Тестирование своего Worker’a

Для реализации будем использовать Python 3.11 и Grpcio, а актуальный proto-файл возьмём из официального репозитория zeebe. Тестовая схема будет выглядеть так же, как и предыдущая. В качестве клиента со стороны Python будет использоваться AioHTTP.

Временные условия те же, для получения задач от worker’a будем использовать ActivateJobs.

[0] Case start, processes(workers): 4 threads: 5 all: 20 seconds: 60 [3] Complete, count: 2110, avg: 0.028436, rps: 35.1666 [1] Complete, count: 2157, avg: 0.027816, rps: 35.95 [0] Complete, count: 2143, avg: 0.027998, rps: 35.7166 [2] Complete, count: 2166, avg: 0.0277, rps: 36.1 Total RPS: 142.933333

Мы получаем прирост ~50 %, а это более чем существенно по сравнению с базовым вариантом, который предлагает сама Camunda.

Начиная с версии 8.4 в Camunda добавили поддержку Streams. Давайте попробуем получать задачи через StreamActivatedJobs.

[0] Case start, processes(workers): 4 threads: 5 all: 20 seconds: 60 [2] Complete, count: 3324, avg: 0.01805, rps: 55.4 [3] Complete, count: 3339, avg: 0.017969, rps: 55.65 [0] Complete, count: 3301, avg: 0.018176, rps: 55.0166 [1] Complete, count: 3321, avg: 0.018066, rps: 55.35 Total RPS: 221.41666

Тут мы уже видим прирост ~130 %!

Заключение

Connectors Bundle прекрасен для того, чтобы набросать тестовую схему быстро и удобно, но для production-среды мы советуем делать свою реализацию сервис-задач. По возможности используйте стримы. Благодаря такому подходу вы можете кратно увеличить RPS и проще распределять ресурсы, выделяя конкретное количество нод под определённые схемы.