Режим обслуживания в службе Azure SignalR

Режим обслуживания — важная концепция в службе Azure SignalR. Служба SignalR в настоящее время поддерживает три режима обслуживания: По умолчанию, бессерверным и классическим. Ресурс Служба SignalR работает по-разному в каждом режиме. Из этой статьи вы узнаете, как выбрать правильный режим обслуживания на основе вашего сценария.

Настройка режима обслуживания

Вам будет предложено указать режим обслуживания при создании нового ресурса SignalR в портал Azure.

Вы также можете изменить режим службы позже в меню параметров.

Используйте az signalr create и az signalr update задайте или измените режим обслуживания с помощью Интерфейса командной строки Azure SignalR.

Режим по умолчанию

Как подразумевает имя, режим по умолчанию — это режим обслуживания по умолчанию для Служба SignalR. В режиме по умолчанию приложение работает как типичное приложение ASP.NET Core SignalR или ASP.NET SignalR (устаревшее). У вас есть приложение веб-сервера, на котором размещен концентратор, называемый сервером концентратора, и клиенты имеют полное дуплексное взаимодействие с сервером концентратора. Разница между ASP.NET Core SignalR и Служба Azure SignalR: с помощью ASP.NET Core SignalR клиент подключается непосредственно к главному серверу. При использовании Служба Azure SignalR клиент и главный сервер подключаются к Служба SignalR и используют службу в качестве прокси-сервера. На следующей схеме показана типичная структура приложения в режиме по умолчанию.

Режим по умолчанию обычно подходит, если у вас есть приложение SignalR, которое вы хотите использовать с Служба SignalR.

Маршрутизация подключений в режиме по умолчанию

В режиме по умолчанию между сервером концентратора и Служба SignalR называется подключениями к серверу WebSocket по умолчанию. Эти подключения используются для передачи сообщений между сервером и клиентом. При подключении нового клиента Служба SignalR перенаправляет клиент на один центральный сервер (предполагается, что у вас несколько серверов) через существующие подключения к серверу. Подключение клиента сохраняется на одном и том же концентраторе сервера во время его существования. Это свойство называется прилипанием подключения. Когда клиент отправляет сообщения, они всегда отправляются на один и тот же центральный сервер. С поведением прилипания можно безопасно поддерживать некоторые состояния для отдельных подключений на сервере концентратора. Например, если вы хотите передавать что-то между сервером и клиентом, вам не нужно учитывать ситуацию, когда пакеты данных отправляются на разные серверы.

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

Бессерверный режим

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

Бессерверный режим работает с Функции Azure для предоставления возможностей обмена сообщениями в режиме реального времени. Клиенты работают с привязками Служба SignalR для Функции Azure, называемой привязкой функции, для отправки сообщений в качестве выходной привязки.

Так как подключение к серверу отсутствует, если вы пытаетесь использовать пакет SDK сервера для установления подключения к серверу, возникает ошибка. Служба SignalR отклоняет попытки подключения к серверу в бессерверном режиме.

Бессерверный режим не имеет прилипания к подключению, но вы по-прежнему можете отправлять сообщения на стороне сервера клиентам. Существует два способа отправки сообщений клиентам в бессерверном режиме:

• Использование REST API для однократного события отправки или
• Используйте подключение WebSocket, чтобы можно было более эффективно отправлять несколько сообщений. Это подключение WebSocket отличается от подключения к серверу.

Ваше серверное приложение также может получать сообщения и события подключения от клиентов. Служба SignalR предоставляет сообщения и события подключения для предварительно настроенных конечных точек (называемых конечными точками вышестоящего потока) с помощью веб-перехватчиков. Конечные точки вышестоящего потока можно настроить только в бессерверном режиме. Дополнительные сведения см. в разделе "Конечные точки вышестоящего потока".

На следующей схеме показано, как работает бессерверный режим.

Классический режим

Классический — это смешанный режим режимов по умолчанию и бессерверным режимам. В классическом режиме тип подключения определяется тем, подключен ли главный сервер при установке подключения клиента. Если есть центральный сервер, подключение клиента направляется на главный сервер. Если центральный сервер недоступен, подключение клиента выполняется в ограниченном бессерверном режиме, где сообщения клиента к серверу не могут быть доставлены на центральный сервер. Классические бессерверные подключения не поддерживают некоторые функции, такие как конечные точки вышестоящего сервера.

Если все серверы концентратора отключены по какой-либо причине, подключения выполняются в бессерверном режиме. Это ваша ответственность за то, чтобы по крайней мере один центральный сервер всегда доступен.

Выберите правильный режим службы

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

• Выберите режим по умолчанию, если вы уже знакомы с работой библиотеки SignalR и хотите перейти от локального SignalR для использования Служба Azure SignalR. Режим по умолчанию работает точно так же, как и локальная служба SignalR, и вы можете использовать ту же модель программирования в библиотеке SignalR. Служба SignalR выступает в качестве прокси-сервера между клиентами и концентраторами.

• Выберите бессерверный режим, если вы создаете новое приложение и не хотите поддерживать подключения к концентратору и серверу. Бессерверный режим работает вместе с Функции Azure таким образом, что вам не нужно поддерживать ни один сервер вообще. Вы по-прежнему можете иметь полный дуплексный обмен данными с REST API, пакетом SDK для управления или привязкой функций + вышестоящей конечной точкой, но модель программирования отличается от библиотеки SignalR.

• Выберите режим по умолчанию, если у вас есть оба центральных сервера для обслуживания клиентских подключений и серверного приложения, чтобы напрямую отправлять сообщения клиентам. Ключевым различием между режимом по умолчанию и бессерверным является наличие центральных серверов и маршрутизация клиентских подключений. REST API/SDK управления / привязка функций могут использоваться в обоих режимах.

• Рассмотрите возможность разделения вариантов использования на несколько Служба SignalR экземпляров с заданным режимом обслуживания в соответствии с использованием, если у вас действительно есть смешанный сценарий. Пример смешанного сценария, требующего классического режима, заключается в том, что у вас есть два разных концентратора в одном ресурсе SignalR. Один концентратор используется в качестве традиционного концентратора SignalR, а другой — с Функции Azure. Этот пример должен быть разделен на два ресурса с одним экземпляром в режиме по умолчанию и одним в бессерверном режиме.

Следующие шаги

Дополнительные сведения об использовании режимов по умолчанию и бессерверным режимам см. в следующих статьях.

• Azure SignalR Service internals (Внутренние компоненты Службы Azure SignalR)

• Azure Functions development and configuration with Azure SignalR Service (Разработка и настройка функций Azure с помощью Службы Azure SignalR)