У нас есть базовая система, которая взаимодействует со своими клиентами и другими внутренними системами асинхронно через MSMQ. Это хорошо подходит, поскольку клиенты отправляют смс на мобильные телефоны, а в других системах есть адаптеры MQ. Также эти коммуникационные процессы являются асинхронными по умолчанию.
Теперь у нас есть требование поддерживать другие системы, для которых по умолчанию используется стиль синхронной связи. Типичным примером этого может служить портативное устройство, которое поддерживает передачу запросов / ответов в стиле rpc по HTTP.
Было предложено решение для поддержки этого путем добавления «прокси-сервера» / конечной точки HTTP, который помещает сообщения, полученные от этих клиентов, во входящую очередь с помощью correlationId, а затем просматривает в исходящей очереди сообщение с таким же значением correlationId. Надеемся, что обработка сообщения завершена, и сообщение с ожидаемым корреляционным идентификатором будет присутствовать в исходящей очереди. Это может произойти в том же потоке, в котором сообщение было отправлено в основную систему для имитации ответа на запрос.
Однако мы видим, что получение сообщений с помощью correlationId (MessageQueue.ReceiveByCorrelationId) является фактором снижения производительности. Не требуется много клиентских потоков, чтобы реально замедлить работу системы.
Я полагаю, что проблема заключается в том, что предлагаемый проект с имитацией синхронизации запрос-ответ с использованием метода приема с помощью корреляционного подхода является проблемой здесь. В текущей архитектуре исходящая очередь находится на удаленном хосте, изучая этот вопрос, чтобы узнать, является ли это проблемой или нет.
У кого-нибудь есть другие подходы для решения этой проблемы? Я предполагаю, что логичным было бы заполнить сообщения из исходящей очереди в базу данных или что-то из одного получающего процесса, а затем выполнить поиск сообщений, имеющих соответствующий корреляционный идентификатор
.