У нас есть существующий веб-сервис, который мы модифицируем так, что, когда в сервисе происходят определенные события, они могут быть опубликованы заинтересованным пользователям.Мы используем службу Azure Signal R в качестве нашего механизма для передачи сообщений от нашего сервиса заинтересованным пользователям.В настоящее время наша архитектура выглядит следующим образом: 
- Наш сервер приложений Signal R имеет только один концентратор , и в настоящее время мы запускаем три экземплярасервер приложений.Я пометил эти Экземпляр концентратора 01 , Экземпляр концентратора 02 и Экземпляр концентратора 03 на диаграмме выше.
- Каждый экземпляр нашего существующеговеб-служба открывает одно соединение со службой Azure Signal R.Прочитав документы по внутренним документам службы Azure SignalR , я понял, что каждое клиентское соединение со службой Azure Signal R проходит одноразовое сопоставление с сервером приложений (или в данном случае с экземпляром-концентратором).На схеме я смоделировал это, показывая цветную ссылку, исходящую либо из существующего экземпляра веб-службы, либо от пользователя, и другую ссылку того же цвета и стиля, выходящую из службы Azure Signal R в один экземпляр-концентратор.
Наша главная задача - подключение существующего экземпляра веб-службы к службе Azure Signal R ( сплошные зеленые и сплошные синие ссылки на диаграмме ) может стать насыщенным, если мыпытаясь отправить слишком много событий.Мы планировали уменьшить эту проблему, чтобы открыть несколько соединений от каждого экземпляра веб-службы к службе Azure Signal R.Затем, в нашем коде, мы будем просто проходить через все соединения во время отправки сообщений.
Мы обеспокоены этим подходом в том, что мы не знаем, как эти подключения к службе Azure Signal R будут сопоставлены с экземплярами-концентраторами.Мы можем оказаться в ситуации, подобной приведенной ниже, когда один или два инстанса-концентратора в итоге берут на себя основную часть нашего трафика.
На этой диаграмме мы видим:
- Каждый экземпляр существующей веб-службы открыл несколько подключений к службе Azure Signal R.К сожалению, Hub Instance 01 и Hub Instance 03 были назначены большинство из этих соединений.Это означает, что они возьмут на себя основную часть нашего трафика и в конечном итоге начнут перегреваться.
Это приводит меня к следующим вопросам:
- Есть что-нибудьмы можем сделать в нашей существующей веб-службе, чтобы убедиться, что соединения, которые мы устанавливаем со службой Azure Signal R, равномерно распределены по инстансам-концентраторам?
- Что мы можем сделать, если один из наших инстансов-концентраторов начнет перегреваться?Кажется, что просто добавление еще одного инстанса-концентратора не поможет, потому что этому экземпляру будут назначены только новые клиенты.Есть ли способ перебалансировать соединения службы Azure Signal R при подключении нового инстанса-концентратора?
- Как влияют клиентские соединения, если экземпляр сервера приложений выходит из строя (т. Е. Для развертывания обновлений)?Разорваны ли клиентские соединения, и затем предполагается, что клиент будет переподключен?
- Как в службе Azure Signal R балансируются соединения, если самому кластеру службы Signal R необходимо увеличить или уменьшить масштаб?