O Serviço Azure SignalR está pronto para uso em produção?
Sim, tanto o suporte para ASP.NET Core SignalR e ASP.NET SignalR está disponível em geral.
Quando há vários servidores de aplicativos, as mensagens do cliente são enviadas para todos os servidores ou apenas para um deles?
Há um mapeamento um-para-um entre um cliente e um servidor de aplicativos. As mensagens de um cliente são sempre enviadas para o mesmo servidor de aplicativos.
O mapeamento é mantido até que o cliente ou o servidor de aplicativos se desconecte.
Se um dos meus servidores de aplicativos estiver inativo, como posso encontrá-lo e ser notificado?
O Serviço Azure SignalR monitora as pulsações dos servidores de aplicativos. Se as pulsações não forem recebidas por um período de tempo especificado, o servidor de aplicativos será considerado offline. Todas as conexões de cliente mapeadas para este servidor de aplicativos serão desconectadas.
Por que meu 'IUserIdProvider' personalizado gera uma exceção quando estou mudando do SDK do Core SignalR para o SDK do Serviço SignalR do Azure para ASP.NET SDK do Serviço SignalR do Azure?
O parâmetro HubConnectionContext context é diferente entre o SDK do ASP.NET Core SignalR e o SDK do Serviço Azure SignalR quando IUserIdProvider é chamado.
No ASP.NET Core SignalR, HubConnectionContext context é o contexto da conexão do cliente físico com valores válidos para todas as propriedades.
No SDK do Serviço SignalR do Azure, HubConnectionContext context é o contexto da conexão lógica do cliente. O cliente físico está conectado à instância do Serviço SignalR do Azure, portanto, apenas um número limitado de propriedades é fornecido.
Por enquanto, apenas HubConnectionContext.GetHttpContext() e HubConnectionContext.User estão disponíveis para acesso.
Você pode verificar o código-fonte.
Posso configurar os transportes disponíveis no Serviço Azure SignalR no lado do servidor com ASP.NET Core SignalR? Por exemplo, posso desativar o transporte WebSocket?
Sim. Consulte Configuração de transporte para saber como configurar.
Você também pode configurar transportes do lado do cliente conforme documentado em ASP.NET configuração do Core SignalR.
Qual é o significado de métricas como contagem de mensagens ou contagem de conexões mostradas no portal do Azure? Que tipo de agregação devo escolher?
Você pode encontrar detalhes sobre como calculamos essas métricas em Mensagens e conexões no Serviço Azure SignalR.
No painel de visão geral dos recursos do Serviço Azure SignalR, já escolhemos o tipo de agregação apropriado para você. Você pode usar métricas com suporte com o Azure Monitor como referência.
Qual é o significado dos modos de serviço 'Padrão', 'Sem servidor' e 'Clássico'? Como posso escolher?
Para novos aplicativos, apenas o modo padrão e sem servidor deve ser usado. A principal diferença é se você tem servidores de aplicativos que estabelecem conexões de servidor com o serviço (por exemplo, use AddAzureSignalR() para se conectar ao serviço). Se sim, use o modo padrão, caso contrário, use o modo sem servidor.
O modo clássico foi projetado para compatibilidade com versões anteriores de aplicativos existentes, portanto, não deve ser usado para novos aplicativos.
Para obter mais informações sobre o modo de serviço, consulte Modo de serviço no Serviço Azure SignalR.
Posso enviar mensagens do cliente no modo sem servidor?
Você pode enviar mensagens do cliente se configurar pontos de extremidade upstream em sua instância do SignalR. Os pontos de extremidade upstream são um conjunto de pontos de extremidade que podem receber mensagens e eventos de conexão do serviço SignalR. Se nenhum ponto de extremidade upstream for configurado, as mensagens do cliente serão ignoradas.
Para obter mais informações.consulte Pontos de extremidade upstream.
O recurso de pontos de extremidade upstream está atualmente em visualização pública.
Há alguma diferença de recurso no uso do Serviço Azure SignalR com ASP.NET SignalR?
Quando você estiver usando o Serviço SignalR do Azure, algumas APIs e recursos do ASP.NET SignalR não são suportados:
- A capacidade de passar o estado arbitrário entre os clientes e o hub (geralmente chamado
HubStatede ) não é suportada. - A
PersistentConnectionclasse não é suportada. - O transporte Forever Frame não é suportado.
- O Serviço Azure SignalR não reproduz mais mensagens enviadas ao cliente quando o cliente está offline.
- Quando você estiver usando o Serviço SignalR do Azure, o tráfego de uma conexão de cliente é sempre roteado (também chamado de sticky) para uma instância do servidor de aplicativos durante a duração da conexão.
O suporte para ASP.NET SignalR é focado na compatibilidade, portanto, nem todos os novos recursos do ASP.NET Core SignalR são suportados. Por exemplo, o MessagePack e o Streaming estão disponíveis apenas para aplicativos ASP.NET Core SignalR.
Você pode configurar o Serviço Azure SignalR para diferentes modos de serviço: Classic, Defaulte Serverless. O Serverless modo não é suportado para ASP.NET. A API REST do plano de dados também não é suportada.
Onde residem os meus dados?
O Serviço Azure SignalR não armazena dados do cliente. Se você usar o Serviço Azure SignalR junto com outros serviços do Azure, como o Armazenamento do Azure para diagnóstico, consulte Visão geral da privacidade do Azure (white paper) para obter orientação sobre como manter a residência de dados em regiões do Azure.
Como faço para escolher entre o serviço Azure SignalR e o serviço Azure Web PubSub?
O Serviço Azure SignalR e o serviço Azure Web PubSub ajudam os clientes a criar aplicativos Web em tempo real facilmente com grande escala e alta disponibilidade e permitem que os clientes se concentrem em sua lógica de negócios em vez de gerenciar a infraestrutura de mensagens. Em geral, você pode escolher o Serviço SignalR do Azure se já usar a biblioteca SignalR para criar aplicativos em tempo real. Em vez disso, se você estiver procurando uma solução genérica para criar um aplicativo em tempo real com base no WebSocket e no padrão publish-subscribe, você pode escolher o serviço Azure Web PubSub. O serviço Azure Web PubSub não substitui o Serviço Azure SignalR e vice-versa; visam diferentes cenários. As orientações a seguir ajudarão você a decidir qual serviço usar para seu cenário.
O Serviço Azure SignalR é mais adequado se:
- Você já está usando o ASP.NET ou ASP.NET Core SignalR, usando principalmente o .NET ou precisa se integrar ao ecossistema .NET (como o Blazor).
- Há um cliente SignalR disponível para sua plataforma.
- Você precisa de um protocolo estabelecido que suporte uma ampla variedade de:
- padrões de chamada (RPC e streaming)
- transportes (WebSocket, eventos enviados pelo servidor e sondagem longa)
- Você precisa de um cliente que gerencie o tempo de vida da conexão em seu nome.
O serviço Azure Web PubSub é mais adequado para situações em que:
- Você precisa criar aplicativos em tempo real com base na tecnologia WebSocket ou publicar-assinar sobre WebSocket.
- Você deseja criar seu próprio subprotocolo ou usar protocolos avançados existentes sobre WebSocket (por exemplo, MQTT, AMQP sobre WebSocket).
- Você está procurando um servidor leve, por exemplo, enviando mensagens para o cliente sem passar pelo back-end configurado.