Возможно я не прав, я еще не сильно спец по камунде. Но вижу ситуацию так: наверняка у вас будет ОДИН процесс, который будет выбирать ExternalTask и раскладывать по очередям/топикам, при запросе он будет указывать ОДИН workerID и ОДИН lock duration. Тут сразу вы теряете гибкость настройки локов (разные таски могут выполняться разное время) и worker id (если что-то пошло не так, понять кто конкретно выполняет таск будет то еще расследование. Т.е. по хорошему еще какой-нибудь ELK и сквозное логирование), Если процессов будет несколько, то с добавлением новых тасков, вам придется править код или усложнять логику. + сопровождение кластера брокера, мониторинг, репликации, персист и прочие радости.
Пока штатный REST выполняет свою задачу и с ним нет проблем, зачем усложнять? Использование любого инструмента должно решать определенную проблему, какую проблему будет решать промежуточный брокер?
Если несколько микросервисов постоянно долбят камунду с просьбой отдать таски - это тоже не очень хорошо. Когда листенер раскладывает по очередям такой проблемы нет. workerId и lockDuration спокойно выносятся на уровень модели через InputMapping или FieldInjection. У нас раббит и так есть в стеке (как и ELK), поэтому вопросы его администрирования все равно придется решать.
Т.о. в нашем случае вариант с пушем в очередь видится предпочтительным. Хотя решение не окончательное, но минусов пока не видится.
