Как Azure Signal R обрабатывает масштабирование сервера приложений?

Question

У нас есть существующий веб-сервис, который мы модифицируем таким образом, чтобы при возникновении определенных событий в сервисе они могли быть опубликованы заинтересованным пользователям. Мы используем службу Azure Signal R в качестве нашего механизма для передачи сообщений от нашего сервиса заинтересованным пользователям. В настоящее время наша архитектура выглядит так:

• Наш сервер приложений Signal R имеет толькоодин концентратор, и в настоящее время мы используем три экземпляра сервера приложений. Я пометил этиинстансы Hub 01,Hub Instance 02 иHub Instance 03 на диаграмме выше.
• Каждый экземпляр нашей существующей веб-службы открывает одно соединение со службой Azure Signal R. После прочтения внутренних документов службы Azure SignalR я понял, что каждое клиентское подключение к службе Azure Signal R проходит одноразовое сопоставление с сервером приложений (или в данном случае с экземпляром-концентратором). На схеме я смоделировал это, показывая цветную ссылку, исходящую либо из существующего экземпляра веб-службы, либо от пользователя, и другую ссылку того же цвета и стиля, выходящую из службы Azure Signal R в один экземпляр-концентратор.

Наша главная задача состоит в том, чтобы соединение существующего экземпляра веб-службы со службой Azure Signal R (сплошные зеленые и сплошные синие ссылки на диаграмме) могло стать насыщенным, если мы пытаемся отправить слишком много событий. Мы планировали уменьшить эту проблему, чтобы открыть несколько соединений от каждого экземпляра веб-службы к службе Azure Signal R. Затем, в нашем коде, мы будем просто проходить через все соединения во время отправки сообщений.

Мы обеспокоены этим подходом, так как не знаем, как эти подключения к службе Azure Signal R будут сопоставлены с экземплярами-концентраторами. Мы можем оказаться в ситуации, подобной приведенной ниже, когда один или два инстанса-концентратора в итоге берут на себя основную часть нашего трафика.

На этой диаграмме мы можем видеть:

• Каждый экземпляр существующей веб-службы открывал несколько подключений к службе Azure Signal R. К сожалению, инстансу-концентратору 01 и инстансу-концентратору 03 было назначено большинство этих соединений. Это означает, что они возьмут на себя основную часть нашего трафика и в конечном итоге начнут нагреваться.

Это приводит меня к следующим вопросам:

1. Есть ли что-то, что мы можем сделать в нашей существующей веб-службе, чтобы убедиться, что соединения, которые мы устанавливаем со службой Azure Signal R, равномерно распределены по инстансам-концентраторам?
2. Что мы можем сделать, если один из наших инстансов Hub начнет нагреваться? Кажется, что просто добавление еще одного инстанса-концентратора не поможет, потому что этому экземпляру будут назначены только новые клиенты. Есть ли способ перебалансировать соединения службы Azure Signal R при подключении нового инстанса-концентратора?
3. Как влияют клиентские соединения, если экземпляр сервера приложений выходит из строя (т. Е. Для развертывания обновлений)? Разорваны ли клиентские соединения, а затем клиент должен восстановить соединение?
4. Как сбалансированы соединения в службе Azure Signal R, если самому кластеру службы Signal R необходимо увеличить или уменьшить масштаб?

Answer 1

Мы сталкиваемся с похожей проблемой, и из того, что я прочитал в документации Microsoft, они предлагают включить объединительную плату с использованием Redis или служебной шины в архитектуру для управления соединениями.