Modo de serviço no Serviço do Azure SignalR
O modo de serviço é um conceito importante no Serviço do Azure SignalR. O Serviço do Azure SignalR atualmente dá suporte a três modos de serviço: Padrão, Sem servidor e Clássico. Seu recurso de Serviço do SignalR se comportará de forma diferente em cada modo. Neste artigo, você aprenderá como escolher o modo de serviço correto com base em seu cenário.
Definindo o modo de serviço
Ao criar um novo recurso do SignalR no portal do Azure, você será solicitado a especificar um modo de serviço.
Você também pode alterar o modo de serviço posteriormente no menu de configurações.
Use az signalr create e az signalr update para definir ou alterar o modo de serviço usando a CLI do Azure SignalR.
Modo padrão
Como o nome indica, o modo Padrão é o modo de serviço padrão do Serviço do SignalR. No modo Padrão, seu aplicativo funciona como um aplicativo típico ASP.NET Core SignalR ou ASP.NET SignalR (preterido). Você tem um aplicativo de servidor Web que hospeda um hub, chamado de servidor hub, e os clientes têm comunicação duplex completa com o servidor hub. A diferença entre o ASP.NET Core SignalR e o Serviço do Azure SignalR é que, em vez de conectar o cliente e o servidor de hub diretamente, o cliente e o servidor se conectam ao Serviço do SignalR e usam o serviço como um proxy. O diagrama a seguir mostra a estrutura típica do aplicativo no modo Padrão.
O modo padrão geralmente é a escolha certa quando você tem um aplicativo SignalR que deseja usar com Serviço do SignalR.
Roteamento de conexão no modo Padrão
No modo Padrão, haverá conexões WebSocket entre o servidor de hub e o Serviço do SignalR chamadas de conexões de servidor. Essas conexões são usadas para transferir mensagens entre o servidor e o cliente. Quando um novo cliente estiver conectado, o Serviço do SignalR roteará o cliente para um servidor de hub (suponha que você tenha mais de um servidor) por meio de conexões de servidor existentes. A conexão do cliente irá para o mesmo servidor de hub durante seu tempo de vida. Essa propriedade é conhecida como adesão à conexão. Quando o cliente envia mensagens, elas sempre vão para o mesmo servidor de hub. Com o comportamento de adesão, você pode manter com segurança alguns estados para conexões individuais no servidor de hub. Por exemplo, se você quiser transmitir algo entre servidor e cliente, não será necessário considerar o caso em que os pacotes de dados vão para servidores diferentes.
Importante
No modo Padrão, um cliente não pode se conectar sem que um servidor hub seja conectado primeiro ao serviço. Se todos os servidores do hub estiverem desconectados devido à interrupção da rede ou reinicialização do servidor, as conexões do cliente receberão um erro informando que nenhum servidor está conectado. É sua responsabilidade garantir que haja sempre pelo menos um servidor de hub conectado ao Serviço do SignalR. Por exemplo, você pode projetar seu aplicativo com vários servidores de hub e, em seguida, verificar se eles não ficarão offline ao mesmo tempo.
Esse modelo de roteamento também significa que quando um servidor de hub ficar offline, as conexões roteadas para esse servidor serão suspensas. Você deve esperar que as conexões sejam suspensas quando o servidor de hub estiver offline para manutenção e manipular a reconexão para minimizar os efeitos no aplicativo.
Observação
No modo Padrão, você também pode usar a API REST, o SDK de gerenciamento e a associação de função para enviar mensagens diretamente a um cliente se você não quiser passar por um servidor de hub. No modo Padrão, as conexões de cliente ainda são tratadas por servidores de hub e pontos de extremidade upstream não funcionarão nesse modo.
Modo sem servidor
Ao contrário do modo Padrão, o modo Sem servidor não exige que um servidor de hub esteja em execução, e é por isso que esse modo é chamado de "sem servidor". O Serviço do SignalR é responsável por manter conexões de cliente. Não há nenhuma garantia de adesão e as solicitações HTTP podem ser menos eficientes do que as conexões WebSocket.
O modo Sem servidor funciona com o Azure Functions para fornecer recursos de mensagens em tempo real. Os clientes trabalham com associações do Serviço do SignalR para Azure Functions, chamadas de associação de função, para enviar mensagens como uma associação de saída.
Como não há nenhuma conexão de servidor, se você tentar usar um SDK do servidor para estabelecer uma conexão de servidor, você receberá um erro. O Serviço do SignalR rejeitará tentativas de conexão de servidor no modo Sem servidor.
O modo Sem servidor não tem adesão à conexão, mas você ainda pode ter mensagens por push de aplicativo do lado do servidor para os clientes. Há duas maneiras de enviar mensagens por push para clientes no modo Sem servidor:
- Usar APIs REST para um evento de envio único ou
- Use uma conexão WebSocket para que você possa enviar várias mensagens com mais eficiência. Essa conexão WebSocket é diferente de uma conexão de servidor.
Observação
Ambos os modos de API REST e WebSocket têm suporte no SDK de gerenciamento de serviço do SignalR. Se você estiver usando uma linguagem diferente do .NET, também poderá invocar manualmente as APIs REST seguindo esta especificação.
Também é possível que o aplicativo de servidor receba mensagens e eventos de conexão de clientes. O Serviço do SignalR fornecerá mensagens e eventos de conexão para pontos de extremidade pré-configurados (chamados pontos de extremidade upstream) usando web hooks. Pontos de extremidade upstream só podem ser configurados no modo Sem servidor. Para obter mais informações, confira Pontos de extremidade de upstream.
O seguinte diagrama mostra como o modo Sem servidor funciona.
Modo clássico
Observação
O modo Clássico é principalmente para compatibilidade com versões anteriores para os aplicativos criados antes de existir um modo Padrão e Sem servidor. Não use o modo Clássico, exceto como último recurso. Para novos aplicativos, escolha Padrão ou Sem servidor com base em seu cenário. Você deve considerar reprojetar aplicativos existentes para eliminar a necessidade do modo Clássico.
O Clássico é um modo misto de modo Padrão e Sem servidor. No modo Clássico, o tipo de conexão é decidido caso haja um servidor de hub conectado quando a conexão do cliente é estabelecida. Se houver um servidor de hub, a conexão do cliente será roteada para ele. Se um servidor de hub não estiver disponível, a conexão do cliente será feita em um modo limitado sem servidor, em que as mensagens cliente a servidor não podem ser entregues a um servidor de hub. As conexões sem servidor no modo Clássico não dão suporte a alguns recursos, como pontos de extremidade upstream.
Se todos os servidores de hub estiverem offline por qualquer motivo, as conexões serão feitas no modo Sem servidor. É sua responsabilidade garantir que pelo menos um servidor de hub esteja sempre disponível.
Escolher a camada de serviço correta
Agora você deve entender as diferenças entre os modos de serviço e saber como escolher entre eles. Conforme discutido anteriormente, o modo Clássico não é recomendado para aplicativos novos ou existentes. Aqui estão algumas dicas que podem ajudá-lo a fazer a escolha certa para novos aplicativos e desativar o modo Clássico para aplicativos existentes.
Se você já estiver familiarizado com a forma como funciona a biblioteca do SignalR e deseja mudar de um SignalR auto-hospedado para usar o Serviço do Azure SignalR, escolha o modo Padrão. O modo Padrão funciona exatamente da mesma forma que o SignalR auto-hospedado e você pode usar o mesmo modelo de programação na biblioteca do SignalR. O Serviço do SignalR atua como um proxy entre clientes e servidores de hub.
Se você estiver criando um novo aplicativo e não quiser manter o servidor de hub e as conexões de servidor, escolha o modo Sem servidor. O modo Sem servidor geralmente funciona junto com o Azure Functions para que você não precise manter nenhum servidor. Você ainda pode ter comunicações duplex completas com API REST, SDK de gerenciamento ou associação de função + ponto de extremidade upstream, mas o modelo de programação será diferente da biblioteca SignalR.
Escolha o modo Padrão se você tiver os dois servidores de hub para atender conexões de cliente e um aplicativo de back-end para enviar mensagens por push diretamente aos clientes. A principal diferença entre o modo Padrão e Sem servidor é se você tem servidores de hub e como as conexões de cliente são roteadas. A associação de função/SDK de gerenciamento/API REST pode ser usada nos dois modos.
Se você realmente tiver um cenário misto, considere separar casos de uso em várias instâncias do Serviço do SignalR com o modo de serviço definido de acordo com o uso. Um exemplo de um cenário misto que requer o modo Clássico é onde você tem dois hubs diferentes no mesmo recurso do SignalR. Um hub é usado como um hub SignalR tradicional e o outro hub é usado com o Azure Functions. Este exemplo deve ser dividido em dois recursos, com uma instância no modo Padrão e outra no modo Sem servidor.
Próximas etapas
Para saber mais sobre como usar o modo Padrão e sem servidor, leia os seguintes artigos.