Recomendações para lidar com falhas transitórias

  • Artigo

Aplica-se a esta recomendação de lista de verificação de confiabilidade do Azure Well-Architected Framework:

RE:07 Fortaleça a resiliência e a capacidade de recuperação de sua carga de trabalho implementando medidas de autopreservação e autorrecuperação. Crie recursos na solução usando padrões de confiabilidade baseados em infraestrutura e padrões de design baseados em software para lidar com falhas de componente e erros transitórios. Crie recursos no sistema para detectar falhas de componente da solução e iniciar automaticamente a ação corretiva enquanto a carga de trabalho continua operando com funcionalidade completa ou reduzida.

Guias relacionados:Trabalhos em segundo plano | Autopreservação

Este guia descreve as recomendações para lidar com falhas transitórias em seus aplicativos de nuvem. Todos os aplicativos que se comunicam com serviços e recursos remotos são suscetíveis a falhas transitórias. Isso é especialmente verdadeiro para aplicativos executados na nuvem, em que, devido à natureza do ambiente e à conectividade pela Internet, esse tipo de falha provavelmente será encontrado com mais frequência. As falhas transitórias incluem a perda momentânea de conectividade de rede com componentes e serviços, a indisponibilidade temporária de um serviço e os tempos limite que ocorrem quando um serviço está ocupado. Essas falhas geralmente são auto-corrigidas, portanto, se a ação for repetida após um atraso adequado, é provável que tenha êxito.

Este artigo fornece diretrizes gerais para tratamento de falhas transitórias. Para obter informações sobre como lidar com falhas transitórias, consulte o padrão de repetição e, ao usar os serviços do Azure, consulte as diretrizes de repetição para serviços do Azure.

Principais estratégias de design

As falhas transitórias podem ocorrer em qualquer ambiente, em qualquer plataforma ou sistema operacional e em qualquer tipo de aplicativo. Para soluções executadas na infraestrutura local local, o desempenho e a disponibilidade do aplicativo e seus componentes normalmente são mantidos por meio de redundância de hardware cara e geralmente subutilizada, e componentes e recursos estão localizados próximos uns dos outros. Essa abordagem torna a falha menos provável, mas falhas transitórias ainda podem ocorrer, assim como interrupções causadas por eventos imprevistos, como problemas externos de alimentação ou de rede, ou por cenários de desastre.

A hospedagem na nuvem, incluindo sistemas de nuvem privada, pode oferecer uma disponibilidade geral mais alta usando recursos compartilhados, redundância, failover automático e alocação dinâmica de recursos em muitos nós de computação de mercadoria. No entanto, devido à natureza dos ambientes de nuvem, falhas transitórias são mais propensas a ocorrer. Há vários motivos para isso:

  • Muitos recursos em um ambiente de nuvem são compartilhados e o acesso a esses recursos está sujeito à limitação para proteger os recursos. Alguns serviços recusam conexões quando a carga sobe para um nível específico ou quando uma taxa de taxa de transferência máxima é atingida, para permitir o processamento de solicitações existentes e manter o desempenho do serviço para todos os usuários. A limitação ajuda a manter a qualidade do serviço para vizinhos e outros locatários que usam o recurso compartilhado.

  • Os ambientes de nuvem usam um grande número de unidades de hardware de commodities. Eles fornecem desempenho distribuindo dinamicamente a carga entre várias unidades de computação e componentes de infraestrutura. Eles fornecem confiabilidade reciclando ou substituindo automaticamente unidades com falha. Devido a essa natureza dinâmica, falhas transitórias e falhas de conexão temporárias podem ocorrer ocasionalmente.

  • Geralmente, há mais componentes de hardware, incluindo infraestrutura de rede, como roteadores e balanceadores de carga, entre o aplicativo e os recursos e serviços que ele usa. Essa infraestrutura adicional pode, ocasionalmente, introduzir latência de conexão adicional e falhas de conexão transitórias.

  • As condições de rede entre o cliente e o servidor podem ser variáveis, especialmente quando a comunicação cruza a Internet. Mesmo em locais, cargas pesadas de tráfego podem retardar a comunicação e causar falhas intermitentes de conexão.

Desafios

Falhas transitórias podem ter um efeito significativo na disponibilidade percebida de um aplicativo, mesmo que ele tenha sido completamente testado em todas as circunstâncias previsíveis. Para garantir que os aplicativos hospedados na nuvem operem de forma confiável, você precisa garantir que eles possam responder aos seguintes desafios:

  • O aplicativo deve ser capaz de detectar falhas quando elas ocorrem e determinar se as falhas provavelmente serão transitórias, são de longa duração ou são falhas terminais. É provável que diferentes recursos retornem respostas diferentes quando ocorrer uma falha, e essas respostas também podem variar dependendo do contexto da operação. Por exemplo, a resposta para um erro quando o aplicativo está lendo do armazenamento pode ser diferente da resposta de um erro ao gravar no armazenamento. Muitos recursos e serviços têm contratos de falha transitória bem documentados. No entanto, quando essas informações não estão disponíveis, pode ser difícil descobrir a natureza da falha e se ela provavelmente será transitória.

  • O aplicativo deve ser capaz de repetir a operação se determinar que a falha provavelmente será transitória. Ele também precisa acompanhar o número de vezes que a operação é repetida.

  • O aplicativo deve usar uma estratégia apropriada para novas tentativas. A estratégia especifica o número de vezes que o aplicativo deve tentar novamente, o atraso entre cada tentativa e as ações a serem executadas após uma tentativa com falha. O número apropriado de tentativas e o atraso entre cada uma delas geralmente são difíceis de determinar. A estratégia varia dependendo do tipo de recurso e das condições operacionais atuais do recurso e do aplicativo.

Diretrizes gerais

As diretrizes a seguir podem ajudá-lo a criar mecanismos de tratamento de falhas transitórios adequados para seus aplicativos.

Determinar se há um mecanismo de repetição interno

  • Muitos serviços fornecem uma biblioteca de cliente ou um SDK que contém um mecanismo de tratamento para falha transitória. A política de repetição usada por ele geralmente é personalizado para a natureza e os requisitos do serviço de destino. Como alternativa, as interfaces REST para serviços podem retornar informações que podem ajudá-lo a determinar se uma repetição é apropriada e quanto tempo aguardar antes da próxima tentativa de repetição.

  • Você deve usar o mecanismo de repetição interno quando estiver disponível, a menos que tenha requisitos específicos e bem compreendidos que tornem um comportamento de repetição diferente mais apropriado.

Determinar se a operação é adequada para tentar novamente

  • Execute operações de repetição somente quando as falhas forem transitórias (normalmente indicadas pela natureza do erro) e quando houver pelo menos alguma probabilidade de que a operação tenha êxito quando tentar novamente. Não adianta repetir operações que tentam uma operação inválida, como uma atualização de banco de dados para um item que não existe ou uma solicitação para um serviço ou recurso que sofreu um erro fatal.

  • Em geral, implemente novas tentativas somente quando você puder determinar o efeito total de fazer isso e quando as condições forem bem compreendidas e puderem ser validadas. Caso contrário, permita que o código de chamada implemente novas tentativas. Lembre-se de que os erros retornados de recursos e serviços fora do controle podem evoluir ao longo do tempo e talvez seja necessário revisitar sua lógica transitória de detecção de falhas.

  • Ao criar serviços ou componentes, considere implementar códigos de erro e mensagens que ajudam os clientes a determinar se eles devem tentar novamente operações com falha. Em particular, indique se o cliente deve repetir a operação (talvez retornando um valor isTransient ) e sugerir um atraso adequado antes da próxima tentativa de repetição. Se você criar um serviço Web, considere retornar erros personalizados definidos em seus contratos de serviço. Embora clientes genéricos possam não ser capazes de ler esses erros, eles são úteis na criação de clientes personalizados.

Determinar uma contagem e intervalo de repetição apropriados

  • Otimize a contagem de repetições e o intervalo para o tipo de caso de uso. Se você não tentar novamente horas suficientes, o aplicativo não poderá concluir a operação e provavelmente falhará. Se você tentar muitas vezes ou com um intervalo muito curto entre tentativas, o aplicativo poderá conter recursos como threads, conexões e memória por longos períodos, o que afeta negativamente a integridade do aplicativo.

  • Adapte valores para o intervalo de tempo e o número de tentativas de repetição para o tipo de operação. Por exemplo, se a operação fizer parte de uma interação do usuário, o intervalo deverá ser curto e apenas algumas tentativas deverão ser tentadas. Usando essa abordagem, você pode evitar fazer com que os usuários aguardem por uma resposta, que contém conexões abertas e pode reduzir a disponibilidade de outros usuários. Se a operação fizer parte de um fluxo de trabalho de execução prolongada ou crítico, em que cancelar e reiniciar o processo é caro ou demorado, é apropriado esperar mais tempo entre tentativas e repetir mais vezes.

  • Tenha em mente que determinar os intervalos apropriados entre repetições é a parte mais difícil de criar uma estratégia bem-sucedida. As estratégias comuns usam os seguintes tipos de intervalo de repetição:

    • Retirada exponencial. O aplicativo aguarda um pouco antes da primeira repetição e, em seguida, aumenta exponencialmente o tempo entre cada repetição subsequente. Por exemplo, ele pode repetir a operação após 3 segundos, 12 segundos, 30 segundos e assim por diante.

    • Intervalos incrementais. O aplicativo aguarda um pouco antes da primeira repetição e, em seguida, aumenta incrementalmente o tempo entre cada repetição subsequente. Por exemplo, ele pode repetir a operação após 3 segundos, 7 segundos, 13 segundos e assim por diante.

    • Intervalos regulares. O aplicativo aguarda o mesmo período entre cada tentativa. Por exemplo, ele pode repetir a operação a cada 3 segundos.

    • Repetição imediata. Às vezes, uma falha transitória é breve, possivelmente causada por um evento como uma colisão de pacote de rede ou um pico em um componente de hardware. Nesse caso, tentar novamente a operação imediatamente é apropriado porque ela pode ter êxito se a falha for limpa no tempo necessário para o aplicativo montar e enviar a próxima solicitação. No entanto, nunca deve haver mais de uma tentativa de repetição imediata. Você deve alternar para estratégias alternativas, como ações de retirada exponencial ou fallback, se a repetição imediata falhar.

    • Aleatoriedade. Qualquer uma das estratégias de repetição listadas anteriormente pode incluir uma randomização para evitar que várias instâncias do cliente enviem tentativas de repetição subsequentes ao mesmo tempo. Por exemplo, uma instância pode repetir a operação após 3 segundos, 11 segundos, 28 segundos e assim por diante, enquanto outra instância pode repetir a operação após 4 segundos, 12 segundos, 26 segundos e assim por diante. A randomização é uma técnica útil que pode ser combinada com outras estratégias.

  • Como diretriz geral, use uma estratégia de retirada exponencial para operações em segundo plano e use estratégias de repetição de intervalo imediatas ou regulares para operações interativas. Em ambos os casos, você deve escolher o intervalo e a contagem de repetições para que a latência máxima de todas as tentativas de repetição esteja dentro do requisito obrigatório de latência de ponta a ponta.

  • Leve em conta a combinação de todos os fatores que contribuem para o tempo limite máximo geral para uma operação repetida. Esses fatores incluem o tempo necessário para que uma conexão com falha produza uma resposta (normalmente definida por um valor de tempo limite no cliente), o atraso entre tentativas de repetição e o número máximo de tentativas. O total de todos esses tempos pode resultar em longos tempos gerais de operação, especialmente quando você usa uma estratégia de atraso exponencial em que o intervalo entre repetições cresce rapidamente após cada falha. Se um processo precisar atender a um SLA (contrato de nível de serviço) específico, o tempo de operação geral, incluindo todos os tempos limite e atrasos, deverá estar dentro dos limites definidos no SLA.

  • Não implemente estratégias de repetição excessivamente agressivas. Essas são estratégias que têm intervalos muito curtos ou repetições que são muito frequentes. Eles podem ter um efeito adverso no recurso ou serviço de destino. Essas estratégias podem impedir que o recurso ou o serviço se recupere de seu estado sobrecarregado e ele continuará bloqueando ou recusando solicitações. Esse cenário resulta em um círculo vicioso, em que cada vez mais solicitações são enviadas para o recurso ou serviço. Consequentemente, sua capacidade de recuperação é ainda mais reduzida.

  • Leve em conta o tempo limite das operações ao escolher intervalos de repetição para evitar iniciar uma tentativa subsequente imediatamente (por exemplo, se o período de tempo limite for semelhante ao intervalo de repetição). Além disso, considere se você precisa manter o período total possível (o tempo limite mais os intervalos de repetição) abaixo de um tempo total específico. Se uma operação tiver um tempo limite extraordinariamente curto ou longo, o tempo limite poderá influenciar quanto tempo aguardar e com que frequência repetir a operação.

  • Use o tipo da exceção e todos os dados que ela contém, ou os códigos de erro e mensagens retornados do serviço, para otimizar o número de repetições e o intervalo entre eles. Por exemplo, algumas exceções ou códigos de erro (como o código HTTP 503, Serviço Indisponível, com um cabeçalho Retry-After na resposta) podem indicar quanto tempo o erro pode durar ou que o serviço falhou e não responderá a nenhuma tentativa subsequente.

  • Considere usar uma abordagem de fila de mensagens mortas para garantir que todas as informações da invocação de entrada não se percam depois que todas as tentativas de repetição tiverem sido esgotadas.

Evitar antipadrões

  • Na maioria dos casos, evite implementações que incluam camadas duplicadas de código de repetição. Evite designs que incluam mecanismos de repetição em cascata ou que implementem novas tentativas em cada estágio de uma operação que envolva uma hierarquia de solicitações, a menos que você tenha requisitos específicos que exijam isso. Nessas circunstâncias excepcionais, use políticas que evitem números de repetições e períodos de intervalo excessivos, e assegure-se de entender as consequências. Por exemplo, digamos que um componente faça uma solicitação para outro, que acessa o serviço de destino. Se você implementar nova tentativa com uma contagem de três em ambas as chamadas, haverá nove tentativas de repetição no total em relação ao serviço. Muitos serviços e recursos implementam um mecanismo de repetição interno. Você deve investigar como pode desabilitar ou modificar esses mecanismos se precisar implementar novas tentativas em um nível mais alto.

  • Nunca implemente um mecanismo de repetição infinita. Isso provavelmente impedirá que o recurso ou o serviço se recupere de situações de sobrecarga e cause limitação e conexões recusadas para continuar por mais tempo. Use um número finito de repetições ou implemente um padrão como Disjuntor para permitir que o serviço se recupere.

  • Nunca execute uma repetição imediata mais de uma vez.

  • Evite usar um intervalo de repetição regular ao acessar serviços e recursos no Azure, especialmente quando você tiver um alto número de tentativas de repetição. A melhor abordagem nesse cenário é uma estratégia exponencial de retirada com uma funcionalidade de quebra de circuito.

  • Impedir que várias instâncias do mesmo cliente ou várias instâncias de clientes diferentes enviem novas tentativas simultaneamente. Se esse cenário provavelmente ocorrer, introduza a randomização nos intervalos de repetição.

Testar sua estratégia e implementação de repetição

  • Teste totalmente sua estratégia de repetição em um conjunto de circunstâncias o mais amplo possível, especialmente quando o aplicativo e os recursos ou serviços de destino que ele usa estão sob carga extrema. Para verificar o comportamento durante o teste, você pode:

    • Injetar falhas transitórias e não transitórias no serviço. Por exemplo, envie solicitações inválidas ou adicione código que detecte solicitações de teste e responda com diferentes tipos de erro.

    • Crie uma simulação do recurso ou serviço que retorna um intervalo de erros que o serviço real pode retornar. Cubra todos os tipos de erros que sua estratégia de repetição foi projetada para detectar.

    • Para serviços personalizados que você cria e implanta, force erros transitórios a ocorrerem desabilitando ou sobrecarregando temporariamente o serviço. (Não tente sobrecarregar recursos compartilhados ou serviços compartilhados no Azure.)

    • Use bibliotecas ou soluções que interceptam e modificam o tráfego de rede para replicar cenários desfavoráveis de seus testes automatizados. Por exemplo, os testes podem adicionar tempos extras de ida e volta, remover pacotes, modificar cabeçalhos ou até mesmo alterar o corpo da solicitação em si. Isso permite o teste determinístico de um subconjunto das condições de falha, para falhas transitórias e outros tipos de falhas.

    • Ao testar a resiliência de um aplicativo Web cliente para falhas transitórias, use as ferramentas de desenvolvedor do navegador ou a capacidade da estrutura de teste de simular ou bloquear solicitações de rede.

    • Execute testes simultâneos e fator de alta carga para garantir que o mecanismo de repetição e a estratégia funcionem corretamente nessas condições. Esses testes também ajudam a garantir que a repetição não tenha um efeito adverso na operação do cliente ou cause contaminação cruzada entre solicitações.

Gerenciar configurações de política de repetição

  • Uma política de repetição é uma combinação de todos os elementos de sua estratégia de repetição. Ele define o mecanismo de detecção que determina se uma falha provavelmente será transitória, o tipo de intervalo a ser usado (como retirada regular, exponencial e randomização), os valores de intervalo reais e o número de vezes a tentar novamente.

  • Implemente novas tentativas em muitos lugares, mesmo no aplicativo mais simples e em cada camada de aplicativos mais complexos. Em vez de codificar os elementos de cada política em vários locais, considere usar um ponto central para armazenar todas as políticas. Por exemplo, armazene valores como o intervalo e a contagem de repetições nos arquivos de configuração do aplicativo, leia-os em runtime e crie programaticamente as políticas de repetição. Isso facilita o gerenciamento das configurações e a modificação e ajuste dos valores para responder a requisitos e cenários em mudança. No entanto, crie o sistema para armazenar os valores em vez de reler um arquivo de configuração todas as vezes e use padrões adequados se os valores não puderem ser obtidos da configuração.

  • Armazene os valores usados para criar as políticas de repetição em runtime no sistema de configuração do aplicativo para que você possa alterá-las sem precisar reiniciar o aplicativo.

  • Aproveite as estratégias de repetição internas ou padrão que estão disponíveis nas APIs do cliente que você usa, mas somente quando forem apropriadas para o seu cenário. Essas estratégias normalmente são genéricas. Em alguns cenários, eles podem ser tudo o que você precisa, mas em outros cenários eles não oferecem a gama completa de opções para atender aos seus requisitos específicos. Para determinar os valores mais apropriados, você precisa executar testes para entender como as configurações afetam seu aplicativo.

Registrar e rastrear falhas transitórias e não transitórias

  • Como parte de sua estratégia de repetição, inclua tratamento de exceção e outras instrumentações que registram novamente tentativas. Uma falha transitória ocasional e uma repetição são esperadas e não indicam um problema. No entanto, números regulares e crescentes de repetições geralmente são um indicador de um problema que pode causar uma falha ou que degrada o desempenho e a disponibilidade do aplicativo.

  • Registre falhas transitórias como entradas de aviso e não como entradas de erro para que os sistemas de monitoramento não as detectem como erros de aplicativo que podem disparar alertas falsos.

  • Considere armazenar um valor em suas entradas de log que indique se as novas tentativas são causadas pela limitação no serviço ou por outros tipos de falhas, como falhas de conexão, para que você possa diferenciá-las durante a análise dos dados. Um aumento no número de erros de limitação geralmente é um indicador de uma falha de design no aplicativo ou a necessidade de alternar para um serviço premium que ofereça hardware dedicado.

  • Considere medir e registrar em log os tempos decorridos gerais para operações que incluem um mecanismo de repetição. Essa métrica é um bom indicador do efeito geral de falhas transitórias nos tempos de resposta do usuário, na latência do processo e na eficiência dos casos de uso do aplicativo. Registre também o número de repetições que ocorrem para que você possa entender os fatores que contribuem para o tempo de resposta.

  • Considere implementar um sistema de telemetria e monitoramento que pode gerar alertas quando o número e a taxa de falhas, o número médio de repetições ou os tempos gerais decorridos antes do sucesso das operações aumentarem.

Gerenciar operações que falham continuamente

  • Considere como lidar com operações que continuam falhando em todas as tentativas. Situações como esta são inevitáveis.

    • Embora uma estratégia de repetição defina o número máximo de vezes que uma operação deve ser repetida, ela não impede que o aplicativo repita a operação com o mesmo número de repetições. Por exemplo, se um serviço de processamento de pedidos falhar com um erro fatal que o coloque fora de ação permanentemente, a estratégia de repetição poderá detectar um tempo limite de conexão e considerá-lo uma falha transitória. O código tenta novamente a operação um número especificado de vezes e, em seguida, desiste. No entanto, quando outro cliente faz um pedido, a operação é tentada novamente, mesmo que falhe sempre.

    • Para evitar novas tentativas contínuas de operações que falham continuamente, você deve considerar a implementação do padrão de Disjuntor. Quando você usa esse padrão, se o número de falhas em uma janela de tempo especificada exceder um limite, as solicitações retornam ao chamador imediatamente como erros e não há nenhuma tentativa de acessar o recurso ou serviço com falha.

    • O aplicativo pode testar o serviço periodicamente, de modo intermitente e com intervalos longos entre as solicitações, a fim de detectar quando ele se tornar disponível. Um intervalo apropriado depende de fatores como a criticalidade da operação e a natureza do serviço. Pode ser qualquer coisa entre alguns minutos e várias horas. Quando o teste for bem-sucedido, o aplicativo poderá retomar operações normais e passar solicitações para o serviço recém-recuperado.

    • Enquanto isso, você pode ser capaz de fazer fallback para outra instância do serviço (talvez em um datacenter ou aplicativo diferente), usar um serviço semelhante que ofereça funcionalidade compatível (talvez mais simples) ou executar algumas operações alternativas com base na esperança de que o serviço estará disponível em breve. Por exemplo, pode ser apropriado armazenar solicitações para o serviço em uma fila ou armazenamento de dados e repeti-las mais tarde. Ou você pode redirecionar o usuário para uma instância alternativa do aplicativo, degradar o desempenho do aplicativo, mas ainda oferecer funcionalidade aceitável ou apenas retornar uma mensagem ao usuário para indicar que o aplicativo não está disponível no momento.

Outras considerações

  • Ao decidir sobre os valores para o número de repetições e os intervalos de repetição de uma política, considere se a operação no serviço ou no recurso faz parte de uma operação de execução prolongada ou de várias etapas. Pode ser difícil ou caro compensar todas as outras etapas operacionais que já tiveram êxito quando uma falha. Nesse caso, um intervalo muito longo e um grande número de tentativas podem ser aceitáveis, desde que essa estratégia não bloqueie outras operações mantendo ou bloqueando recursos escassos.

  • Considere se repetir a mesma operação pode causar inconsistências nos dados. Se algumas partes de um processo de várias etapas forem repetidas e as operações não forem idempotentes, podem ocorrer inconsistências. Por exemplo, se uma operação que incrementa um valor for repetida, ela produzirá um resultado inválido. Repetir uma operação que envia uma mensagem para uma fila pode causar uma inconsistência no consumidor da mensagem se o consumidor não conseguir detectar mensagens duplicadas. Para evitar esses cenários, crie cada etapa como uma operação idempotente. Para obter mais informações, consulte Padrões de idempopotência.

  • Considere o escopo das operações que são repetidas. Por exemplo, talvez seja mais fácil implementar o código de repetição em um nível que engloba várias operações e repita todas elas se uma falhar. No entanto, isso pode resultar em problemas de idempotência ou operações de reversão desnecessárias.

  • Se você escolher um escopo de repetição que engloba várias operações, leve em conta a latência total de todas elas ao determinar intervalos de repetição, ao monitorar os tempos decorridos da operação e antes de gerar alertas para falhas.

  • Considere como sua estratégia de repetição pode afetar vizinhos e outros locatários em um aplicativo compartilhado e quando você usa recursos e serviços compartilhados. As políticas de repetição agressivas podem aumentar o número de falhas transitórias que ocorrem para esses outros usuários e para aplicativos que compartilham os recursos e serviços. Da mesma forma, seu aplicativo pode ser afetado pelas políticas de repetição implementadas por outros usuários dos recursos e serviços. Para aplicativos comercialmente críticos, talvez você queira usar serviços premium que não são compartilhados. Isso oferece mais controle sobre a carga e a consequente limitação desses recursos e serviços, o que pode ajudar a justificar o custo extra.

Observação

Consulte Problemas e considerações no artigo Padrão de repetição para obter mais diretrizes sobre compensações e riscos.

Facilitação do Azure

A maioria dos SDKs de cliente e serviços do Azure fornece um mecanismo de repetição. No entanto, esses mecanismos diferem porque cada serviço tem características e requisitos diferentes e cada mecanismo de repetição é ajustado para o serviço específico. Esta seção resume os recursos do mecanismo de repetição para alguns serviços do Azure comumente usados.

Serviço Recursos de repetição Configuração de política Escopo Recursos de telemetria
Microsoft Entra ID Nativo na MSAL (Biblioteca de Autenticação da Microsoft) Inserido na biblioteca MSAL Interna Nenhum
Azure Cosmos DB Nativo no serviço Não configurável Global TraceSource
Armazenamento do Azure Data Lake Nativo no cliente Não configurável Operações individuais Nenhum
Hubs de eventos do Azure Nativo no cliente Programático Cliente Nenhum
Hub IoT do Azure Nativo no SDK do cliente Programático Cliente Nenhum
Cache Redis do Azure Nativo no cliente Programático Cliente TextWriter
Azure Cognitive Search Nativo no cliente Programático Cliente ETW ou personalizado
Barramento de Serviço do Azure Nativo no cliente Programático NamespaceManager, MessagingFactory e client ETW
Azure Service Fabric Nativo no cliente Programático Cliente Nenhum
banco de dados SQL do Azure com ADO.NET Polly Programático e declarativo Instruções ou blocos de código únicos Personalizado
Banco de dados SQL com o Entity Framework Nativo no cliente Programático Global por AppDomain Nenhum
Banco de dados SQL com Entity Framework Core Nativo no cliente Programático Global por AppDomain Nenhum
Armazenamento do Azure Nativo no cliente Programático Operações individuais e de cliente TraceSource

Observação

Para a maioria dos mecanismos de repetição internos do Azure, atualmente não há como aplicar uma política de repetição diferente para diferentes tipos de erros ou exceções. Você deve configurar uma política que fornece o melhor desempenho médio e disponibilidade. Uma maneira de ajustar sua política é analisar arquivos de log para determinar o tipo de falhas transitórias que estão ocorrendo.

Exemplo

Confira Padrão de aplicativo Web confiável para .NET para obter um exemplo que usa muitos dos padrões discutidos neste artigo. Também há uma implementação de referência no GitHub.

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade