Балансировщик нагрузки с широковещательным websocket

#websocket #.net-core #signalr #load-balancing

#websocket #.net-ядро #signalr #балансировка нагрузки

Вопрос:

Хотя у нас есть много вопросов о балансировке нагрузки websockets, я не смог найти ни одного, относящегося к моему конкретному сценарию.

У меня будет следующий дизайн:

                            |=============|
        -------------------|  ActiveMQ   |--------------------
        |                  |=============|                   |
        |                                                    |
|=============|            |=============|            |=============|
|  MyApp_01   |------------|   Database  |------------|  MyApp_02   |
|=============|            |=============|            |=============|
                                                             |
                                  ---------------------------
                                  |
                           |=============|
                           |LoadBalancer |
                           |=============|
                                  |
                                  |
                           |=============|
                           |   Client    |
                           |=============|
  

У меня есть следующие компоненты:

  • Мое приложение развернуто в двух экземплярах
  • ActiveMQ Очередь, которую прослушивает мое приложение
  • База данных, в которую оба приложения записывают сообщения очереди.
  • Балансировщик нагрузки, который еще предстоит определить между Nginx или какой-либо Microsoft Service Fabric (я действительно мало знаю об этих технологиях, что делает поиск еще сложнее: S)
  • Мое клиентское приложение, которое подключается к балансировщику нагрузки

Оба экземпляра моего приложения прослушиваются в одной очереди. При получении сообщения экземпляр удаляет его из очереди, сохраняет в базе данных и транслирует через websockets любому подключенному к нему клиенту. Оба экземпляра прослушивают очередь, поэтому любой из них может быть тем, кто удалит сообщение из очереди, у меня нет никакого контроля над ним (и я не должен, я думаю). Проблема возникает, когда, например, в приведенном выше сценарии у нас есть клиент, подключенный к MyApp_02 и MyApp_01 тот, кто получает и передает сообщение. Клиент никогда не получит никакого сообщения, потому что он подключен к MyApp_02 .

Что я могу сделать в этом сценарии? Должен ли я найти способ широковещательной передачи из всех экземпляров …? Как бы я это сделал? Есть ли что-нибудь в Nginx или Microsoft Service Fabric, что могло бы мне помочь?

Если это имеет значение, я использую .Net Core 2.2 with SignalR в своем приложении.

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

Комментарии:

1. для ответа на вопрос требуется одно уточнение — контролируете ли вы, как сообщения поступают в очередь сообщений? потому что то, как вы можете справиться с ситуацией, будет в основном зависеть от того, сможете ли вы контролировать способ публикации сообщений в очереди.

2. Что вы имеете в виду? У меня нет такого контроля. Эта очередь используется для интеграции данных между моей системой и третьей. Мы договорились о формате сообщения, а другая система просто помещает сообщения в этом формате в очередь.

3. Пишу это снова (пропустил мое окно редактирования): Я думаю, Topics может помочь вам решить проблему. Оба приложения могут подписаться на MessageDeleted тему и, получив сообщение из этой темы, обычно общаются с подключенным клиентом. В этом случае .. оба будут получать удаленные сообщения.. это может быть нормально или нет для вас, зависит от требований. Одна вещь, которая не ясна: где у вас работает SignalR? Разве у вас не должно быть центрального приложения для этого, вместо того, чтобы иметь его на своем MyApp_xx Таким образом, ответственность приложения заключается только в обработке сообщений.. не работает с клиентами.

4. Привет, jpgrassi, спасибо за ответ. Мы рассмотрели решение, включающее другую службу обмена сообщениями, транслирующуюся на все экземпляры «MyApp_XX», как вы предложили. Я думаю, что это также сработало бы, но мой клиент хочет быть уверен, что у нас нет другого варианта. Включение другой службы обмена сообщениями обходится ему дорого и создаст еще одну точку отказа в приложении (что, если очередь не работает? Или сообщение не доставлено? …….?). Они хотят быть уверены, что нет решения «из коробки» для решения проблемы балансировки нагрузки в этих сценариях… есть идеи?

5. Что касается SignalR, они запущены в обоих экземплярах MyApp. На самом деле это одна из целей балансировки нагрузки. Таким образом, мы можем сбалансировать соединения в обоих приложениях и не перегружать одно из них