Режим обслуживания в службе 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 заключается в том, что вместо подключения клиента и центрального сервера напрямую клиент и сервер подключаются к Служба SignalR и используют службу в качестве прокси-сервера. На следующей схеме показана типичная структура приложения в режиме по умолчанию.

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

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

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

Важно!

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

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

Примечание.

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

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

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

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

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

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

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

Примечание.

REST API и WebSockets поддерживаются в пакете SDK для управления службами SignalR. Если вы используете язык, отличный от .NET, можно также вручную вызвать ИНТЕРФЕЙСы REST API после этой спецификации.

Ваше серверное приложение также может получать сообщения и события подключения от клиентов. Служба 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)