Как направить вызов API к указанному c сервисному узлу fabri c

Question

Я предоставил конечную точку службы с поддержкой веб-сокетов через Azure Шлюз приложений, и служба размещена на azure службе поддержки c. Клиент инициирует соединение через веб-сокет с моей конечной точкой и может обмениваться данными. Во время определенных потоков сообщений моя служба с поддержкой веб-сокетов вызывает другие службы, размещенные на службе fabri c, используя служебную шину azure. Они обрабатываются полностью асинхронно c. Как только другие службы заканчивают обработку sh, они отправляют сообщение на служебную шину, которое моя служба WebSocket считывает обратно. Проблема, с которой я сталкиваюсь, заключается в том, чтобы направить сообщения обратно на нужный сервисный узел fabri c, чтобы его можно было отправить обратно клиенту на другом конце соединения WebSocket

. На рисунке ниже вы Можно представить каждый узел, содержащий несколько сервисов, включая сервис с поддержкой веб-сокетов. Как только служба Websocket отправляет сообщение на служебную шину, последующие службы начинают обработку и, наконец, отправляют сообщение обратно на служебную шину, которую служба Websocket считывает обратно. Здесь случайный узел получит сообщение, и у него может не быть подходящего соединения веб-сокета с pu sh обработанными данными обратно Sample Design

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

Answer 1

Я столкнулся с похожим сценарием, и мне не понравилась идея использовать новый внешний сервис (Redis / SQL Server) в качестве объединительной панели, которая просто дублировала бы каждое сообщение / событие на всех узлах.

* 1002 Решение, на котором я остановился, состояло в том, чтобы опираться на свойство прокси акторов, используя события акторов для обратного вызова специфицированного c экземпляра службы без сохранения состояния. Создание службы актера, выступающей в качестве объединительной платы паба / подсаблицы.

Решение обобщено в этом сообщении в блоге и в этом репозитории GitHub . Стоит отметить, что документация заявляет, что актерские события наилучшее усилие . На самом деле это не было проблемой, когда приложение работает как обычно, я предполагаю, что во время развертывания или аварийного переключения некоторые события могут быть потеряны, однако это может быть смягчено дополнительной работой.

Стоит также отметить что ваши правила балансировки нагрузки должны поддерживать постоянные соединения между клиентами и внутренними экземплярами. Вы можете создать отдельные правила для веб-сокетов, если хотите, чтобы это применялось только к ним, а не к обычному HTTP-трафику c.