O Serviço do Azure SignalR está pronto para uso em produção?
Sim, o suporte para ASP.NET Core SignalR e ASP.NET SignalR está em disponibilidade geral.
Quando há vários servidores de aplicativos, as mensagens de cliente são enviadas a todos os servidores ou apenas a um deles?
Há um mapeamento de um para um entre um cliente e um servidor de aplicativos. Mensagens de um cliente sempre são enviadas para o mesmo servidor de aplicativos.
O mapeamento é mantido até que o cliente ou o servidor de aplicativos desconecte.
Se um dos meus servidores de aplicativos estiver inativo, como poderei encontrá-lo e ser notificado?
O Serviço do Azure SignalR monitora pulsações de 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 esse servidor de aplicativos serão desconectadas.
Por que meu `IUserIdProvider` personalizado gera uma exceção quando alterno do SDK do ASP.NET Core do SignalR para o SDK do Serviço do Azure SignalR?
O parâmetro HubConnectionContext context é diferente entre o SDK do ASP.NET Core SignalR e o SDK do Serviço do Azure SignalR quando IUserIdProvider é chamado.
No ASP.NET Core SignalR, HubConnectionContext context é o contexto da conexão de cliente física com os valores válidos para todas as propriedades.
No SDK de Serviço do Azure SignalR, HubConnectionContext context é o contexto de conexão de cliente lógica. O cliente físico está conectado à instância do Serviço do Azure SignalR, 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 do Azure SignalR no lado do servidor, com o ASP.NET Core SignalR? Por exemplo, posso desabilitar o transporte de WebSocket?
Sim. Confira Configuração de transporte para saber como configurar.
Você também pode configurar os transportes do lado do cliente conforme documentado na configuração do SignalR para ASP.NET Core.
Qual é o significado das métricas, como contagem de mensagens ou contagem de conexões, mostradas no portal do Azure? Qual tipo de agregação devo escolher?
Você pode encontrar detalhes sobre como calculamos essas métricas em Mensagens e conexões no Serviço do Azure SignalR.
No painel de visão geral dos recursos do Serviço do 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 faço para 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, usam 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 criado para oferecer compatibilidade com versões anteriores para aplicativos existentes, portanto não deve ser usado para novos aplicativos.
Para obter mais informações sobre o modo de serviço, confira Modo de serviço no Serviço do Azure SignalR.
Posso enviar mensagens do cliente no modo sem servidor?
Você poderá enviar a mensagem do cliente se configurar pontos de extremidade de upstream em sua instância do SignalR. Os pontos de extremidade de upstream são um conjunto de pontos de extremidade que pode receber mensagens e eventos de conexão do Serviço do SignalR. Se nenhum ponto de extremidade de upstream estiver configurado, as mensagens do cliente serão ignoradas.
Para obter mais informações, confira Pontos de extremidade de upstream.
O recurso de pontos de extremidade upstream está atualmente em versão prévia pública.
Há alguma diferença de recursos ao usar o Serviço do Azure SignalR ou o ASP.NET SignalR?
Quando você usa o Serviço do Azure SignalR, algumas APIs e recursos do ASP.NET SignalR não têm suporte:
- A capacidade de passar um estado arbitrário entre clientes e o hub (geralmente chamada de
HubState) não terá suporte. - A classe
PersistentConnectionnão tem suporte. - Não há suporte para o transporte de Quadro Contínuo.
- O Serviço do Azure SignalR não repete mais as mensagens enviadas ao cliente quando o cliente está offline.
- Quando você está usando o Serviço do Azure SignalR, o tráfego para uma conexão de cliente sempre é roteado (também chamado de adesivo) para uma instância do servidor de aplicativos durante a conexão.
O suporte para o ASP.NET SignalR concentra-se na compatibilidade. Portanto, nem todos os novos recursos do ASP.NET Core SignalR têm suporte. Por exemplo, MessagePack e Streaming estão disponíveis somente para aplicativos do ASP.NET Core SignalR.
Você pode configurar o Serviço do Azure SignalR para diferentes modos de serviço: Classic, Default e Serverless. O modo Serverless não tem suporte para o ASP.NET. A API REST do plano de dados também não tem suporte.
Onde meus dados residem?
O Azure SignalR Service não armazena dados do cliente. Se você usar o serviço Azure SignalR Service 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 fazer escolher entre o Serviço do Azure SignalR e o serviço Azure Web PubSub?
O Serviço do 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 permitir 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 do Azure SignalR caso já use a biblioteca do SignalR para compilar aplicativos em tempo real. Em vez disso, se você estiver procurando uma solução genérica para compilar um aplicativo em tempo real com base no WebSocket e no padrão publish-subscribe, poderá escolher o serviço Azure Web PubSub. O serviço Azure Web PubSub não é um substituto do Serviço do Azure SignalR ou vice-versa. Eles servem para diferentes casos. As diretrizes a seguir vão ajudar você a decidir qual serviço usar no seu caso.
Serviço do Azure SignalR é mais adequado se:
- Você já estiver usando o ASP.NET ou o ASP.NET Core SignalR, principalmente usando o .NET ou precisa se integrar ao ecossistema do .NET (como o Blazor).
- Há um cliente do SignalR disponível para sua plataforma.
- Você precisa de um protocolo estabelecido que dê suporte a 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 pelo WebSocket.
- Você deseja criar seu próprio subprotocolo ou usar protocolos avançados existentes no 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.