Архитектура: использование отдельной очереди для обработки ошибок?

Question

У нас есть небольшой микросервис, единственная цель которого - получать сообщения через очередь и отправлять их во внешнюю систему.Сообщения могут поступать из любого количества других служб, и служба не знает о содержании сообщения.Внешняя система может принять или отклонить это сообщение.Я вижу несколько вариантов работы с ответами внешней системы:

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

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

Есть ли какие-либо доступные ресурсы, документирующие лучшие практики для решения подобных проблем?

(Я знаю, что выше можно переписать в службу чтения из очереди и сохранения сообщения в БД, асинхронной отправки сообщений во внешнюю систему и сохранения ответа в БД, публикации события для указаниясообщение было обработано и было разработано API для получения ответа от БД, но для этого потребовались бы дополнительные БД, больше работы и больше ресурсов, что, на мой взгляд, было бы излишним)

Answer 1

Я бы тоже выбрал третий вариант и разделил ваши опасения по нескольким причинам.

1. Если все различные типы сообщений находятся в одной и той же очереди, ваши потребители должны будут использовать фильтр / селектор, чтобы получить сообщения, которые они хотят.Это увеличит сложность потребителя.Кроме того, фильтры / селекторы на стороне потребителя, как правило, не приветствуются, поскольку они негативно влияют на производительность из-за сканирования очереди, которое брокер должен выполнить, чтобы найти сообщения, которые соответствуют фильтру потребителя.
2. Если все сообщения находятся в одной очередитогда управление будет более сложным.Например, если вы хотите узнать, сколько ошибок произошло, вам понадобится инструмент управления для сканирования очереди на наличие сообщений, соответствующих шаблону ошибок.Если бы ошибки были в отдельной очереди, вам просто нужно посмотреть на количество сообщений в очереди.
3. Многократные очереди обычно лучше для производительности, поскольку они увеличивают параллелизм и уменьшают узкие места.Большинство современных брокеров (например, ActiveMQ Artemis) отлично масштабируются с несколькими очередями и клиентами.

Стоит отметить, что брокеры сообщений не предназначены для долгосрочного хранения данных, как база данных.Если вы намереваетесь некоторое время хранить детали ответов, возможно, вы захотите в какой-то момент выгрузить их в базу данных.