Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Azure Web PubSub Service é um serviço de mensagens totalmente gerido e em tempo real que permite comunicação bidirecional entre servidores e clientes utilizando o protocolo WebSocket. Um único recurso Web PubSub pode escalar para um milhão de ligações WebSocket concorrentes. O serviço suporta vários padrões de mensagens, incluindo transmissão servidor-a-cliente, mensagens para grupos nomeados, pub/sub cliente-a-cliente e streaming de tokens de IA.
Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.
Este artigo descreve como tornar o Azure Web PubSub Service resiliente a uma variedade de potenciais interrupções e problemas, incluindo falhas transitórias, falhas em zonas de disponibilidade e falhas regionais. Descreve também como o serviço gere a manutenção e destaca informações chave sobre o acordo de nível de serviço (SLA) do Azure Web PubSub Service.
Recomendações de implantação de produção para confiabilidade
Para cargas de trabalho em produção, siga estas recomendações:
- Usa o nível Premium. O nível premium é resistente a falhas de zonas de disponibilidade em regiões suportadas e permite configurar a geo-replicação.
- Utilize o Azure Web PubSub Client SDK ao construir aplicações clientes, ou siga orientações de gestão de falhas transitórias reconectando-se em segurança. Falhas de zona, falhas regionais e falhas transitórias interrompem as ligações ativas.
- Permitir a geo-replicação para proteger contra falhas regionais. Dimensione cada réplica com unidades suficientes para suportar toda a carga de tráfego esperada durante um evento de failover.
Visão geral da arquitetura de confiabilidade
Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.
Arquitetura lógica
O recurso que crias é um recurso Web PubSub. Configura-se um recurso com um número de unidades, que representa a capacidade do recurso, incluindo o número máximo de ligações concorrentes. Para mais informações, consulte o guia de desempenho para Azure Web PubSub Serviço.
Um recurso Web PubSub tem um endpoint globalmente único semelhante a contoso.webpubsub.azure.com. Os clientes estabelecem ligações WebSocket a este endpoint. Os servidores de aplicação ligam-se ao mesmo endpoint para enviar mensagens e receber eventos dos clientes.
Para mais informações, consulte os internos do serviço Azure Web PubSub.
Arquitetura física
O Azure Web PubSub Service gere o estado da ligação WebSocket e o encaminhamento das mensagens através de um conjunto de recursos de computação. A Microsoft gere a infraestrutura subjacente. Não vês nem interages diretamente com VMs individuais que o serviço utiliza, nem com outros componentes de infraestrutura.
Resiliência a falhas transitórias
Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.
Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.
O WebSocket é um protocolo de ligação de longa duração. Eventos de rede transitórios, reinícios da infraestrutura de back-end e operações de manutenção de serviço podem interromper uma ligação ativa. Uma reconexão básica restaura a ligação, mas sem lógica adicional o cliente perde mensagens que estavam em operação ou em fila durante a interrupção.
O Serviço Azure Web PubSub resolve este problema através de subprotocolos fiáveis que assentam na ligação WebSocket bruta. Os subprotocolos acompanham a sequência de mensagens e o estado da ligação para que, quando uma ligação cai, o cliente renegocie com o serviço e retome de onde tinha parado.
Normalmente, não há perda de mensagens depois de uma conexão cair e ser restabelecida. No entanto, existem algumas situações em que pode ocorrer perda de mensagem. Por exemplo, se o cliente se desligar por mais de um minuto e depois se reconectar com o mesmo ID de ligação, a operação de reconexão mostra um estado de falha para indicar que pode ocorrer perda de mensagem.
Para tirar partido dos subprotocolos fiáveis, siga estas recomendações:
Sempre que possível, utilize um Azure Web PubSub client SDK. O SDK implementa automaticamente o subprotocolo fiável. Não é necessária qualquer configuração adicional. Para obter mais informações, consulte:
Se não conseguires usar o SDK, implementa um dos subprotocolos fiáveis diretamente no código do cliente WebSocket. Para a especificação completa e orientação de implementação, consulte Criar clientes WebSocket fiáveis.
Resiliência a falhas na zona de disponibilidade
Zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.
O Azure Web PubSub Service suporta implementações redundantes por zonas quando utiliza o nível Premium. Quando cria ou atualiza um recurso Web PubSub de nível Premium numa região que suporta zonas de disponibilidade, a redundância de zonas é automaticamente ativada. O serviço distribui a sua infraestrutura por várias zonas de disponibilidade na região. Se uma zona falhar, o serviço encaminha o tráfego para infraestruturas na zona saudável.
Requisitos
Apoio regional: A redundância de zonas é suportada na maioria das regiões onde ambas as condições se aplicam:
- O serviço Azure Web PubSub está disponível. Para uma lista de regiões onde o serviço está disponível, consulte Disponibilidade de Produtos por Região.
- A região suporta zonas de disponibilidade. Para ver a lista de regiões com zonas de disponibilidade, consulte Azure regions list.
No entanto, o Japan West atualmente não suporta redundância de zonas para o Azure Web PubSub.
Tier: A redundância de zonas está disponível no nível Premium.
Custo
A redundância de zona não acrescenta custo, e pagas a tarifa padrão do nível Premium. Para mais informações, consulte Azure Web PubSub preços de serviço.
Configurar o suporte à zona de disponibilidade
A redundância de zona não requer configuração além de selecionar o nível Premium. Está ativado automaticamente em ambos os casos:
Crie um novo recurso Web PubSub redundante em zonas. Selecione um SKU de nível Premium ao criar o recurso. Para mais informações, consulte Criar um recurso Azure Web PubSub.
Atualiza um recurso existente para o nível Premium. A redundância de zonas é ativada automaticamente quando se atualiza um recurso existente para um SKU de nível Premium. Fazer a atualização de Standard para Premium não causa tempo de inatividade no serviço. Para mais informações, consulte Escalar uma instância de serviço Azure Web PubSub.
Comportamento quando todas as zonas estão íntegras
Esta secção descreve o que esperar quando configura um recurso Azure Web PubSub para redundância de zonas e todas as zonas de disponibilidade estão operacionais.
Operação entre zonas: O serviço Azure Web PubSub gere automaticamente como as ligações e operações são distribuídas nas zonas de disponibilidade. A infraestrutura em múltiplas zonas processa o tráfego num modelo ativo-ativo. Não precisas de configurar nada para tirar partido deste comportamento. O serviço encaminha mensagens entre instâncias entre zonas automaticamente, de modo que uma mensagem enviada por um cliente numa zona é entregue a clientes ligados a qualquer outra zona.
Replicação de dados entre zonas: Azure Web PubSub O serviço não persiste os dados do cliente. O serviço mantém metadados de sessão, como o estado da ligação e informações de sequência de mensagens para ligações ativas. Estes metadados são replicados de forma síncrona entre as zonas de disponibilidade.
Comportamento durante uma falha de zona
Esta secção descreve o que esperar quando configura um recurso Azure Web PubSub para redundância de zonas e há uma falha numa das zonas de disponibilidade.
- Deteção e resposta: A plataforma Azure Web PubSub Service é responsável por detetar uma falha numa zona de disponibilidade. Não precisas de tomar qualquer acção para iniciar um failover de zona.
- Notificação: A Microsoft não te informa automaticamente quando uma zona está inativa. No entanto, pode utilizar o Azure Resource Health para monitorizar a integridade de um recurso individual, e pode configurar alertas de integridade de recursos para notificá-lo de problemas. Também pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Saúde do Serviço para o notificar de problemas.
Pedidos ativos: Durante uma falha na zona, as ligações WebSocket ativas à infraestrutura da zona afetada são interrompidas. Se os seus clientes lidarem adequadamente com falhas transitórias , como ao reconectarem-se após um curto período de tempo, normalmente evitam um impacto significativo.
Perda de dados esperada: Azure Web PubSub O serviço não persiste mensagens, por isso não se espera que uma falha de zona cause perda de dados dentro do serviço Azure Web PubSub. No entanto, quaisquer ligações ativas são cortadas durante um evento de falha de zona e, por isso, é possível que quaisquer dados que estejam a ser transmitidos sejam perdidos.
Se os editores utilizarem um Azure Web PubSub Client SDK ou implementarem os subprotocolos fiáveis, as suas mensagens são reconhecidas pelo serviço após o serviço as receber. Quando uma mensagem é reconhecida, é replicada em todas as zonas de disponibilidade, por isso a falha da zona do editor não faz com que a mensagem se perca. No entanto, se um assinante não receber a mensagem antes de esta ser descartada, poderá não a receber.
Tempo de inatividade previsto: A reconexão das ligações ativas caídas normalmente demora alguns segundos. Os clientes que implementam a lógica de reconexão experienciam perturbações mínimas.
Redistribuição: Azure Web PubSub O serviço deteta a perda da zona e redistribui automaticamente o tráfego entre as zonas saudáveis. Você não precisa tomar nenhuma medida.
Recuperação de zona
Quando uma zona de disponibilidade recupera, o Azure Web PubSub Service reintegra-a automaticamente na topologia de serviço ativo. Não precisas de tomar qualquer ação para recuperar a zona.
Depois de uma zona recuperar, novas ligações podem ser redirecionadas para a infraestrutura na zona recuperada. Quaisquer ligações existentes não serão movidas ou reequilibradas para a zona recuperada, mas serão gradualmente reequilibradas à medida que as ligações existentes forem caindo e voltando a ligar ao longo do tempo. O desequilíbrio de ligação entre zonas não tem qualquer impacto na tua carga de trabalho.
Teste de falhas de zona
O Azure Web PubSub Service gere automaticamente o encaminhamento de tráfego, o failover e a recuperação de zona para recursos de nível Premium com redundância de zona. Você não precisa iniciar nada. Como a redundância de zona é totalmente gerida, não é necessário validar processos de falha de zona de disponibilidade.
Resiliência a falhas em toda a região
Azure Web PubSub Service é um serviço de uma única região. Se a região ficar indisponível, o seu recurso Web PubSub também não está disponível.
Para proteger a sua aplicação contra falhas regionais, pode usar a geo-replicação, que está disponível no nível Premium. Alternativamente, pode construir uma solução multirregional personalizada implementando múltiplos recursos Web PubSub em diferentes regiões.
Geo-replicação
A geo-replicação permite-lhe adicionar réplicas do seu recurso Web PubSub noutras regiões Azure. Todas as réplicas partilham um único ponto final (contoso.webpubsub.azure.com). Por trás deste endpoint, o Gestor de Tráfego do Azure utiliza o encaminhamento baseado em DNS para direcionar cada cliente para a réplica regional saudável mais próxima. Se uma região falhar, o Gestor de Tráfego deteta a falha através de verificações de saúde e deixa de direcionar clientes para essa réplica. As novas ligações do cliente são automaticamente encaminhadas para a réplica saudável mais próxima.
A região onde criou o recurso Web PubSub chama-se região primária, e a sua réplica é a réplica primária. O plano de controlo do recurso primário gere a configuração do seu recurso Web PubSub.
Requisitos
- Region support: Pode adicionar réplicas em qualquer região em que o Azure Web PubSub Service estiver disponível.
- Tier: Deve usar o nível Premium para permitir a geo-replicação.
- Limite de réplicas: Cada recurso principal do Web PubSub suporta até oito réplicas.
Considerações
Herança de configuração: As réplicas herdam a maioria das definições de configuração do recurso principal. Certas definições devem ser configuradas separadamente em cada réplica. Para a lista completa de definições que não são herdadas, veja Geo-replication em Azure Web PubSub.
Alterações na configuração: O plano de controlo primário, na região primária, processa quaisquer alterações de configuração no recurso Web PubSub. Se o plano de controlo primário não estiver disponível, não poderá atualizar a configuração dos recursos, embora as réplicas existentes continuem a processar o tráfego de dados sem interrupção.
Custo
Cada réplica é faturada separadamente com base no seu próprio número de unidades e volume de mensagens de saída. Se uma mensagem for transferida entre réplicas e depois entregue a um cliente ou servidor noutra região, é faturada como uma mensagem de saída. Para mais informações, consulte Azure Web PubSub preços de serviço.
Configurar a replicação geográfica
Para adicionar ou remover uma réplica a um recurso Web PubSub, veja Geo-replication em Azure Web PubSub.
Planejamento e gerenciamento de capacidade
Cada réplica gere o tráfego de forma independente. Durante um failover regional, os clientes da região falhada reconectam-se à réplica saudável mais próxima. Para garantir que as réplicas sobreviventes têm capacidade suficiente para absorver esta carga extra, configure cada réplica com unidades que consigam lidar com todo o tráfego esperado da carga de trabalho, e não apenas a parte que normalmente serve.
Em alternativa, ative a autoescalabilidade em cada réplica para que as unidades possam escalar automaticamente em resposta a uma carga mais elevada. O autoscaling continua a funcionar quando uma réplica secundária não está disponível, mas o autoscaling não funciona se o plano de controlo primário não estiver disponível. Para mais informações sobre autoscaling, veja Escalar automaticamente unidades de um serviço Azure Web PubSub.
Para orientações gerais sobre sobreaprovisionamento como estratégia, veja Gerir capacidade por sobreaprovisionamento.
Comportamento quando todas as regiões estão saudáveis
Esta secção descreve o que esperar quando configura o Azure Web PubSub Service para geo-replicação e todas as regiões estão operacionais.
Cross-region operation: Gestor de Tráfego do Azure encaminha cada cliente para a réplica regional saudável mais próxima. Clientes em diferentes áreas geográficas podem conectar-se a réplicas diferentes. O Web PubSub Service sincroniza mensagens entre réplicas para que os clientes ligados a qualquer réplica possam comunicar entre si.
Replicação de dados entre regiões: Quando uma mensagem é enviada para uma réplica, o serviço transfere essa mensagem de forma síncrona para outras réplicas, de modo que os clientes ligados noutros locais a possam receber. A sobrecarga de sincronização é mínima para a maioria dos padrões de mensagens comuns, como transmitir para grandes grupos ou enviar mensagens a uma única ligação. Enviar mensagens a pequenos grupos (menos de 10 membros) pode gerar uma sobrecarga de sincronização ligeiramente superior.
O Azure Web PubSub Service não persiste mensagens; apenas a entrega ativa é sincronizada entre réplicas.
Comportamento durante uma interrupção regional
Esta secção descreve o que esperar quando configura o Azure Web PubSub Service para geo-replicação e há uma falha numa das regiões réplica.
- Deteção e resposta: O Web PubSub Service é responsável por detetar uma falha numa região e redirecionar automaticamente o tráfego recebido para uma réplica numa das outras regiões que configura.
Notificação: A Microsoft não o notifica automaticamente quando uma região está inativa. No entanto:
Você pode usar a Integridade dos Recursos do Azure para monitorar a integridade de um recurso individual e pode configurar alertas de Integridade de Recursos para notificá-lo sobre problemas.
Pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas regionais, e pode configurar alertas Service Health alerts para o notificar de problemas.
Pedidos ativos: As ligações WebSocket ativas à réplica na região falhada são cortadas. Os clientes têm de se reconectar após a réplica fazer failover.
Perda de dados esperada: O serviço Azure Web PubSub não armazena mensagens. Mensagens que estavam em trânsito para clientes na região falhada no momento da falha podem ser perdidas. Não se espera perda persistente de dados porque o serviço não armazena os dados dos clientes.
Tempo de inatividade esperado: Gestor de Tráfego do Azure realiza verificações de saúde em cada réplica. Quando uma interrupção numa região faz com que uma réplica falhe à sua verificação de integridade, o Traffic Manager remove o endpoint dessa réplica dos seus resultados de resolução DNS. Após a remoção do endpoint, o TTL DNS de 90 segundos deve passar antes de os clientes verem registos DNS atualizados. No total, a transição normalmente demora alguns minutos. Clientes bem desenhados que implementam lógica de reconexão podem retomar o funcionamento normal após se reconectarem à réplica saudável.
Se o plano de controlo primário não estiver disponível, não pode fazer alterações à configuração do seu recurso Web PubSub nem às suas réplicas. No entanto, as ligações WebSocket continuam a funcionar em réplicas saudáveis.
Redistribuição: O Gestor de Tráfego do Azure direciona os pedidos recebidos para as réplicas saudáveis. No entanto, se um cliente tentar reconectar-se antes de o Gestor de Tráfego do Azure ter detetado o failover da réplica e as entradas DNS atualizadas se propagarem para o cliente, então a tentativa de reconexão do cliente pode continuar a direcionar-se para a região indisponível e pode falhar.
Após a propagação da atualização DNS, os clientes de reconexão são automaticamente encaminhados para a réplica saudável mais próxima.
Recuperação da região
Quando a região com falha recupera, a verificação de estado do Gestor de Tráfego deteta a réplica restaurada e inclui novamente o seu endpoint na resolução de DNS. Os clientes atualmente conectados a outras réplicas não são afetados e permanecem conectados até se desconectarem. Novas conexões são redirecionadas para a réplica da região recuperada quando esta é a réplica saudável mais próxima.
Teste para falhas regionais
Para simular um failover regional e testar o comportamento de reconexão da sua aplicação cliente, pode desativar o endpoint de uma réplica. Esta ação faz com que o Gestor de Tráfego pare de encaminhar tráfego para essa réplica, o que lhe permite observar como os seus clientes se comportam quando a réplica a que se ligam se torna indisponível. Para passos detalhados, consulte Desativar ou ativar o endpoint da réplica.
Soluções multirregional personalizadas para resiliência
Se precisar de resiliência entre regiões mas não estiver a usar geo-replicação, pode implementar e gerir recursos Web PubSub separados em várias regiões e implementar a sua própria lógica de failover no seu servidor de aplicações. Esta abordagem é mais complexa do que a geo-replicação e não suporta failover sem interrupção para conectividade de cliente a cliente. Para uma visão detalhada da arquitetura, padrões de failover e orientações de teste, veja Resiliência e recuperação de desastres em Azure Web PubSub Serviço.
Backup e restauração
Azure Web PubSub Service é um serviço de mensagens sem estado. Não armazena mensagens de clientes e não tem capacidade de backup ou restauro.
Para proteger a configuração dos seus recursos, defina os seus recursos Web PubSub usando infraestrutura como código (como templates Bicep ou ARM) e armazene essas definições no controlo de versão. Se precisares de recriar um recurso, reimplementa-o a partir da configuração armazenada.
Resiliência à manutenção de serviços
A Microsoft aplica regularmente atualizações de serviço e realiza outras manutenções. A plataforma Azure gere estas atividades automaticamente, garantindo que a manutenção é fluida e transparente para si. Não é esperado qualquer tempo de indisponibilidade durante os eventos de manutenção, a menos que tenha sido informado através da manutenção planeada do Azure Service Health.
Contrato de nível de serviço
O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para mais informações, consulte Acordos de Nível de Serviço (SLA) para serviços online.