Блог

Давайте представим, что у меня есть REST API с конечной точкой /api/status . При обращении к этой конечной точке API отправляет сообщение в очередь сообщений, запрашивая статус какой-либо другой службы.

Затем в ответ служба отправляет сообщение со своим статусом в очередь, которую прослушивает REST API. Итак, для запроса статуса требуется одно сообщение и одно ответное сообщение.

Мой вопрос таков: Существует ли шаблон проектирования для преобразования асинхронного характера этого подхода в синхронный в API? Другими словами: существует ли шаблон, который GetStatus(...) метод в псевдокоде ниже может реализовать для синхронизации получения статуса с обменом данными через несколько очередей сообщений или даже pub / подсистем.

 var statusRequestMsg = "get_status";
var statusResponseMsg = GetStatus(statusRequestMsg);
  

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

Я много гуглил в поисках этого, но единственное, что я нашел, было очень техническое объяснение подхода к этому в этой статье: Модель связи для интеграции парадигм запроса-ответа и публикации-подписки в повсеместные системы

Пожалуйста, обратите внимание, что я понимаю, что это не идеальный дизайн API и что существуют лучшие способы реализации примера. Я создал приведенный выше пример, чтобы помочь мне проиллюстрировать свой вопрос. Также я понимаю, что некоторые AMQP подразумевают. (например, RabbitMQ) предоставляет способ синхронизации обмена MQ со стилем запроса / ответа.

Заранее спасибо.

Microsoft называет это шаблоном асинхронного запроса-ответа и использует решение, которое опрашивает по HTTP:https://learn.microsoft.com/en-us/azure/architecture/patterns/async-request-reply

Я полагаю, что должно быть возможно избежать опроса, подписавшись на обновления для ключа. Например, в Redis можно подписаться на обновления для одного ключа с помощью уведомлений в пространстве ключей (На странице упоминаются два предостережения: что «все события, доставленные во время отключения клиента, теряются» и «уведомления о событиях не передаются на все узлы».)

Рассматривали ли вы что-то подобное:

1. Запрос поступает
2. Создайте идентификатор корреляции
3. Отправьте идентификатор корреляции другой службе как часть сообщения, отправленного через очередь
4. Начните опрос для этого идентификатора в каком-либо хранилище данных (скажем, Redis)

Время истекает…

5. Отправьте идентификатор корреляции обратно исходной службе вместе с результатом запроса в сообщении, отправленном через очередь
6. Рабочая очередь чтения устанавливает значение идентификатора корреляции в хранилище данных в качестве результата асинхронного запроса
7. Опрос обнаруживает результат и возвращает в качестве ответа на запрос

Сработает ли это?