Modo de serviço no Serviço Azure SignalR
O modo de serviço é um conceito importante no Serviço Azure SignalR. Atualmente, o Serviço SignalR suporta três modos de serviço: Padrão, Sem Servidor e Clássico. Seu recurso de serviço SignalR se comporta de forma diferente em cada modo. Neste artigo, você aprenderá a escolher o modo de serviço correto com base no seu cenário.
Definindo o modo de serviço
Você é solicitado a especificar um modo de serviço ao criar um novo recurso SignalR no portal do Azure.
Você também pode alterar o modo de serviço mais tarde 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 predefinido
Como o nome indica, o modo Padrão é o modo de serviço padrão para o Serviço 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 de hub, e os clientes têm comunicação full duplex com o servidor de hub. A diferença entre ASP.NET Core SignalR e o Serviço Azure SignalR é: Com ASP.NET Core SignalR, o cliente se conecta diretamente ao servidor de hub. Com o Serviço SignalR do Azure, o cliente e o servidor de hub se conectam ao Serviço 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 o Serviço SignalR.
Roteamento de conexão no modo padrão
No modo Padrão, há conexões WebSocket entre o servidor hub e o Serviço SignalR chamadas conexões de servidor. Essas conexões são usadas para transferir mensagens entre um servidor e um cliente. Quando um novo cliente é conectado, o Serviço SignalR roteia 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 permanece no mesmo servidor de hub durante sua vida útil. Essa propriedade é conhecida como aderência de conexão. Quando o cliente envia mensagens, elas sempre vão para o mesmo servidor de hub. Com o comportamento de aderência, 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 precisa 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 ao serviço primeiro. Se todos os servidores de hub estiverem desconectados devido a 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 certificar-se de que há sempre pelo menos um servidor hub conectado ao serviço SignalR. Por exemplo, você pode projetar seu aplicativo com vários servidores de hub e, em seguida, certificar-se de que eles não ficarão todos offline ao mesmo tempo.
O modelo de roteamento padrão também significa que quando um servidor de hub fica offline, as conexões roteadas para esse servidor são descartadas. Você deve esperar que as conexões caiam quando o servidor hub estiver offline para manutenção e manipular a reconexão para minimizar os efeitos em seu aplicativo.
Nota
No modo Padrão, você também pode usar a API REST, o SDK de gerenciamento e a vinculação de funções para enviar mensagens diretamente a um cliente se 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 os 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 requer que um servidor hub esteja em execução, e é por isso que esse modo é chamado de "sem servidor". O Serviço SignalR é responsável pela manutenção das conexões do cliente. Não há garantia de aderência de conexão e as solicitações HTTP podem ser menos eficientes do que as conexões WebSockets.
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 SignalR para o Azure Functions, chamadas de vinculação de função, para enviar mensagens como uma ligação de saída.
Como não há conexão com o servidor, se você tentar usar um SDK do servidor para estabelecer uma conexão com o servidor, receberá um erro. O Serviço SignalR rejeita as tentativas de conexão do servidor no modo sem servidor.
O modo sem servidor não tem aderência de conexão, mas você ainda pode ter mensagens push de aplicativos do lado do servidor para clientes. Há duas maneiras de enviar mensagens por push para clientes no modo sem servidor:
- Use 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.
Nota
A API REST e os WebSockets são suportados no SDK de gerenciamento de serviços 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 seu aplicativo de servidor receba mensagens e eventos de conexão de clientes. O Serviço SignalR entrega mensagens e eventos de conexão para pontos de extremidade pré-configurados (chamados pontos de extremidade upstream) usando ganchos da Web. Os pontos de extremidade upstream só podem ser configurados no modo sem servidor. Para obter mais informações, consulte Pontos de extremidade upstream.
O diagrama a seguir mostra como o modo sem servidor funciona.
Modo clássico
Nota
O modo clássico é principalmente para compatibilidade com versões anteriores para aplicativos criados antes da introdução dos modos Padrão e Sem Servidor. Não use o modo Clássico, exceto como último recurso. Use Padrão ou Sem servidor para novos aplicativos, com base no seu cenário. Você deve considerar redesenhar aplicativos existentes para eliminar a necessidade do modo Clássico.
Clássico é um modo misto de modos Padrão e Sem Servidor. No modo Clássico, o tipo de conexão é decidido se há um servidor hub conectado quando a conexão do cliente é estabelecida. Se houver um servidor de hub, a conexão do cliente será roteada para um servidor de hub. Se um servidor de hub não estiver disponível, a conexão do cliente será feita em um modo sem servidor limitado em que as mensagens de cliente para servidor não podem ser entregues a um servidor de hub. As conexões sem servidor de modo clássico não suportam alguns recursos, como pontos de extremidade upstream.
Se todos os seus 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.
Escolha o modo de serviço certo
Agora você deve entender as diferenças entre os modos de serviço e saber como escolher entre eles. Como discutido anteriormente, o modo Clássico não é recomendado para aplicativos novos ou existentes. Aqui estão mais algumas dicas que podem ajudá-lo a fazer a escolha certa para o modo de serviço e ajudá-lo a desativar o modo Clássico para aplicativos existentes.
Escolha o modo Padrão se já estiver familiarizado com o funcionamento da biblioteca do SignalR e quiser mudar de um SignalR auto-hospedado para usar o Serviço do Azure SignalR. O modo padrão funciona exatamente da mesma maneira que o SignalR auto-hospedado e você pode usar o mesmo modelo de programação na biblioteca do SignalR. O Serviço SignalR atua como um proxy entre clientes e servidores hub.
Escolha o modo sem servidor se estiver criando um novo aplicativo e não quiser manter o servidor hub e as conexões do servidor. O modo sem servidor funciona em conjunto com o Azure Functions para que você não precise manter nenhum servidor. Você ainda pode ter comunicações full duplex com API REST, SDK de gerenciamento ou vinculação de função + ponto de extremidade upstream, mas o modelo de programação é diferente da biblioteca SignalR.
Escolha o modo padrão se você tiver ambos os servidores de hub para servir conexões de cliente e um aplicativo de back-end para enviar mensagens diretamente para os 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. API REST/SDK de gerenciamento/vinculação de função pode ser usada em ambos os modos.
Considere separar casos de uso em várias instâncias do Serviço SignalR com o modo de serviço definido de acordo com o uso, se você realmente tiver um cenário misto. Um exemplo de um cenário misto que requer o modo Clássico é quando você tem dois hubs diferentes no mesmo recurso 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óximos passos
Consulte os artigos a seguir para saber mais sobre como usar os modos Padrão e Sem Servidor.