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

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

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

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

портал Azure— выбор режима работы при создании службы SignalR

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

Обновить сервисный режим

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

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

Как подразумевает имя, режим по умолчанию — это режим обслуживания по умолчанию для Служба 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. Например, вы можете разработать приложение с несколькими серверами концентраторов, а затем убедиться, что они не будут работать в автономном режиме одновременно.

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

Примечание.

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

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

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

Бессерверный режим работает с Azure Functions для обеспечения возможности мессенджинга в реальном времени. Клиенты работают с привязками службы 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 Functions. Этот пример должен быть разделен на два ресурса с одним экземпляром в режиме по умолчанию и одним в бессерверном режиме.

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

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

  • Last updated on