Как реализовать горизонтальное масштабирование SignalR без использования существующих вариантов объединительной платы

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

1. Связь между экземплярами: это означает, что любое сообщение в одном экземпляре доступно во всех других экземплярах. Классическая реализация — любой тип очереди, SignalR поддерживает Redis, вы можете использовать SQL Server, но очевидны ограничения любого решения SQL. Azure использует Redis Cache как PaaS

2. Хранилище в памяти: обычно вы используете это на одном сервере, но это обязательно для реализации общей памяти. Опять же, у Redis есть решение с общей памятью на случай, если у вас есть доступный сервер. Нет никакой возможности реализовать это без такого решения, как Redis. Опять же, менее производительным решением будет реализация MemStorage на SQL.

3. Аутентификация: стандартная реализация безопасности использует файл cookie для хранения зашифрованного ключа. Но когда у вас есть несколько серверов, каждый сервер имеет свой уникальный ключ. Чтобы решить проблему, вы должны реализовать свой собственный DataProtector, если вы используете этот метод.

Примеры выходят за рамки этого объяснения, большая часть кода (даже шаблоны без реальных реализованных методов) заняла бы несколько страниц. Я предлагаю вам взглянуть на 3 элемента, которые являются обязательными для масштабирования вашего приложения.