Recomendações para lidar com falhas transitórias

  • Artigo

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

RE:07 Reforce a resiliência e a capacidade de recuperação da sua carga de trabalho ao implementar medidas de auto-preservação e autorrecuperação. Crie capacidades na solução com padrões de fiabilidade baseados na infraestrutura e padrões de conceção baseados em software para lidar com falhas de componentes e erros transitórios. Crie capacidades no sistema para detetar falhas de componentes da solução e iniciar automaticamente a ação corretiva enquanto a carga de trabalho continua a funcionar com funcionalidades completas ou reduzidas.

Guias relacionados:Trabalhos em segundo plano | Auto-preservação

Este guia descreve as recomendações para lidar com falhas transitórias nas suas aplicações na cloud. Todas as aplicações que comunicam com serviços e recursos remotos devem ser sensíveis a falhas transitórias. Isto aplica-se especialmente às aplicações que são executadas na cloud, onde, devido à natureza do ambiente e da conectividade através da Internet, é provável que este tipo de falha seja encontrado com mais frequência. As falhas transitórias incluem a perda momentânea da conectividade de rede a componentes e serviços, a indisponibilidade temporária de um serviço e tempos limite que ocorrem quando um serviço está ocupado. Muitas vezes, estas falhas são auto-corrigidas, pelo que, se a ação for repetida após um atraso adequado, é provável que seja bem-sucedida.

Este artigo fornece orientações gerais para o processamento de falhas transitórias. Para obter informações sobre como lidar com falhas transitórias, veja o padrão de repetição e, quando estiver a utilizar os serviços do Azure, veja a Documentação de orientação sobre a repetição dos serviços do Azure.

Principais estratégias de conceção

As falhas transitórias podem ocorrer em qualquer ambiente, em qualquer plataforma ou sistema operativo e em qualquer tipo de aplicação. Para soluções executadas na infraestrutura local no local, o desempenho e a disponibilidade da aplicação e dos respetivos componentes são normalmente mantidos através de redundância de hardware dispendiosa e, muitas vezes, subutilizado, e os componentes e recursos estão localizados perto uns dos outros. Esta abordagem torna a falha menos provável, mas continuam a ocorrer falhas transitórias, assim como falhas causadas por eventos imprevistos, como problemas de rede ou fontes de alimentação externas ou cenários de desastre.

O alojamento na cloud, incluindo os sistemas de nuvem privada, pode oferecer uma maior disponibilidade geral ao utilizar recursos partilhados, redundância, ativação pós-falha automática e alocação de recursos dinâmicos em muitos nós de computação de produtos. No entanto, devido à natureza dos ambientes na cloud, é mais provável que ocorram falhas transitórias. Existem diversos motivos para tal:

  • Muitos recursos num ambiente na cloud são partilhados e o acesso a estes recursos está sujeito a limitação para proteger os recursos. Alguns serviços recusam ligações quando a carga sobe para um nível específico ou quando é atingida uma taxa de débito máxima, para permitir o processamento de pedidos existentes e manter o desempenho do serviço para todos os utilizadores. A limitação ajuda a manter a qualidade do serviço para vizinhos e outros inquilinos que utilizam o recurso partilhado.

  • Os ambientes de cloud utilizam um grande número de unidades de hardware de base. Proporcionam desempenho ao distribuir dinamicamente a carga por várias unidades de computação e componentes de infraestrutura. Proporcionam fiabilidade ao reciclar ou substituir automaticamente unidades falhadas. Devido a esta natureza dinâmica, podem ocorrer ocasionalmente falhas transitórias e falhas de ligação temporárias.

  • Muitas vezes, existem mais componentes de hardware, incluindo a infraestrutura de rede, como routers e balanceadores de carga, entre a aplicação e os recursos e serviços que utiliza. Esta infraestrutura adicional pode por vezes introduzir mais latência de ligação e falhas de ligação transitória.

  • As condições de rede entre o cliente e o servidor podem ser variáveis, especialmente quando a comunicação atravessa a Internet. Mesmo em localizações no local, as cargas de tráfego pesadas podem abrandar a comunicação e causar falhas de ligação intermitentes.

Desafios

As falhas transitórias podem ter um efeito significativo na perceção de disponibilidade de uma aplicação, mesmo que tenha sido completamente testada em todas as circunstâncias previsíveis. Para garantir que as aplicações alojadas na cloud funcionam de forma fiável, tem de garantir que podem responder aos seguintes desafios:

  • A aplicação tem de ser capaz de detetar falhas quando ocorrem e determinar se é provável que as falhas sejam transitórias, sejam de longa duração ou se são falhas de terminal. É provável que diferentes recursos devolvam respostas diferentes quando ocorre uma falha e estas respostas também podem variar consoante o contexto da operação. Por exemplo, a resposta para um erro quando a aplicação está a ler a partir do armazenamento pode ser diferente da resposta de um erro quando está a escrever 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 é provável que seja transitória.

  • A aplicação tem de conseguir repetir a operação se determinar que é provável que a falha seja transitória. Também precisa de controlar o número de vezes que a operação é repetida.

  • A aplicação tem de utilizar uma estratégia adequada para repetições. A estratégia especifica o número de vezes que a aplicação deve tentar novamente, o atraso entre cada tentativa e as ações a executar após uma tentativa falhada. O número adequado de tentativas e o atraso entre cada uma são muitas vezes difíceis de determinar. A estratégia varia consoante o tipo de recurso e as condições operacionais atuais do recurso e da aplicação.

Orientações gerais

As diretrizes seguintes podem ajudá-lo a conceber mecanismos de processamento de falhas transitórios adequados para as suas aplicações.

Determinar se existe um mecanismo de repetição incorporado

  • Muitos serviços fornecem um SDK ou biblioteca de cliente que contém um mecanismo de processamento de falhas transitórias. Normalmente, a política de repetição que este utiliza está adaptada à natureza e aos requisitos do serviço de destino. Em alternativa, as interfaces REST para serviços podem devolver informações que podem ajudá-lo a determinar se uma repetição é adequada e quanto tempo deve aguardar antes da próxima tentativa de repetição.

  • Deve utilizar o mecanismo de repetição incorporado quando estiver disponível, a menos que tenha requisitos específicos e bem compreendidos que tornem mais adequado um comportamento de repetição diferente.

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

  • Executar operações de repetição apenas quando as falhas são transitórias (normalmente indicadas pela natureza do erro) e quando há, pelo menos, alguma probabilidade de a operação ser bem-sucedida quando repetida. Não faz sentido repetir operações que tentem uma operação inválida, como uma atualização da base de dados para um item que não existe ou um pedido para um serviço ou recurso que sofreu um erro fatal.

  • Em geral, implemente as repetições apenas quando pode determinar o efeito completo de fazê-lo e quando as condições são bem compreendidas e podem ser validadas. Caso contrário, deixe que o código de chamada implemente repetições. Lembre-se de que os erros devolvidos de recursos e serviços fora do seu controlo podem evoluir ao longo do tempo e poderá ter de rever a lógica transitória de deteção de falhas.

  • Quando criar serviços ou componentes, considere implementar códigos de erro e mensagens que ajudam os clientes a determinar se devem repetir operações falhadas. Em particular, indique se o cliente deve repetir a operação (talvez devolvendo um valor isTransient ) e sugira um atraso adequado antes da próxima tentativa de repetição. Se criar um serviço Web, considere devolver erros personalizados definidos nos contratos de serviço. Embora os clientes genéricos possam não conseguir ler estes erros, são úteis na criação de clientes personalizados.

Determinar uma contagem e intervalo de repetições adequados

  • Otimize a contagem de repetições e o intervalo para o tipo de caso de utilização. Se não repetir vezes suficientes, a aplicação não conseguirá concluir a operação e provavelmente falhará. Se repetir demasiadas vezes ou com um intervalo demasiado curto entre tentativas, a aplicação poderá conter recursos como threads, ligações e memória durante longos períodos, o que afeta negativamente o estado de funcionamento da aplicação.

  • 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 utilizador, o intervalo deve ser curto e devem ser tentadas apenas algumas repetições. Ao utilizar esta abordagem, pode evitar fazer com que os utilizadores aguardem por uma resposta, que contém ligações abertas e pode reduzir a disponibilidade de outros utilizadores. Se a operação fizer parte de um fluxo de trabalho crítico ou de execução prolongada, em que cancelar e reiniciar o processo é dispendioso ou demorado, é apropriado esperar mais tempo entre tentativas e repetir mais vezes.

  • Tenha em atenção que determinar os intervalos adequados entre repetições é a parte mais difícil de conceber uma estratégia com êxito. As estratégias normais utilizam os seguintes tipos de intervalo de repetições:

    • Recuo exponencial. A aplicação aguarda um pouco antes da primeira repetição e, em seguida, aumenta exponencialmente o tempo entre cada repetição subsequente. Por exemplo, pode repetir a operação após 3 segundos, 12 segundos, 30 segundos e assim sucessivamente.

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

    • Intervalos regulares. A aplicação aguarda o mesmo tempo entre cada tentativa. Por exemplo, pode repetir a operação a cada 3 segundos.

    • Repetição imediata. Por vezes, uma falha transitória é breve, possivelmente causada por um evento como uma colisão de pacotes de rede ou um pico num componente de hardware. Neste caso, repetir a operação imediatamente é apropriado porque poderá ser bem-sucedido se a falha for desmarcada no tempo que a aplicação demora a montar e enviar o pedido seguinte. No entanto, nunca deve haver mais do que uma tentativa de repetição imediata. Deve mudar para estratégias alternativas, como vés exponencial ou ações de contingência, se a repetição imediata falhar.

    • Aleatorização. Qualquer uma das estratégias de repetição listadas anteriormente pode incluir uma aleatoriedade para impedir 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 sucessivamente, enquanto outra instância poderá repetir a operação após 4 segundos, 12 segundos, 26 segundos e assim sucessivamente. A aleatoriedade é uma técnica útil que pode ser combinada com outras estratégias.

  • Como orientação geral, utilize uma estratégia de recuo exponencial para operações em segundo plano e utilize estratégias de repetição de intervalos imediatos ou regulares para operações interativas. Em ambos os casos, deve escolher o atraso e a contagem de repetições de forma a que a latência máxima de todas as tentativas de repetição estejam dentro do requisito necessário de latência ponto a ponto.

  • Tenha em conta a combinação de todos os fatores que contribuem para o tempo limite máximo geral para uma operação repetida. Estes fatores incluem o tempo que uma ligação falhada demora a produzir 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 estes tempos pode resultar em longos tempos de operação gerais, especialmente quando utiliza uma estratégia de atraso exponencial em que o intervalo entre repetições aumenta rapidamente após cada falha. Se um processo tiver de cumprir um contrato de nível de serviço (SLA) específico, o tempo de operação geral, incluindo todos os tempos limite e atrasos, tem de estar dentro dos limites definidos no SLA.

  • Não implemente estratégias de repetição demasiado agressivas. Estas são estratégias que têm intervalos demasiado curtos ou repetições que são demasiado frequentes. Podem ter um efeito adverso no recurso ou serviço de destino. Estas estratégias podem impedir que o recurso ou serviço recupere do estado sobrecarregado e continuarão a bloquear ou recusar pedidos. Este cenário resulta num círculo vicioso, onde cada vez mais pedidos são enviados para o recurso ou serviço. Consequentemente, a sua capacidade de recuperação é ainda mais reduzida.

  • Tenha em conta o tempo limite das operações quando escolher intervalos de repetição para evitar iniciar imediatamente uma tentativa subsequente (por exemplo, se o período de tempo limite for semelhante ao intervalo de repetição). Além disso, considere se precisa de 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 invulgarmente curto ou longo, o tempo limite poderá influenciar o tempo de espera e a frequência de repetição da operação.

  • Utilize o tipo de exceção e quaisquer dados que contenha, ou os códigos de erro e mensagens devolvidas pelo serviço, para otimizar o número de repetições e o intervalo entre as mesmas. Por exemplo, algumas exceções ou códigos de erro (como o código HTTP 503, Serviço Indisponível, com um cabeçalho de Retry-After na resposta) podem indicar quanto tempo o erro pode durar ou que o serviço falhou e não responde a nenhuma tentativa subsequente.

  • Considere utilizar uma abordagem de fila de mensagens não entregues para garantir que todas as informações da invocação recebida não se perdem depois de esgotadas todas as tentativas de repetição.

Evitar anti-padrõ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 a repetição em todas as fases de uma operação que envolva uma hierarquia de pedidos, a menos que tenha requisitos específicos que exijam fazê-lo. Nestas circunstâncias excecionais, utilize políticas que impeçam números excessivos em termos de repetições e períodos de atraso, e certifique-se de que compreende as consequências. Por exemplo, digamos que um componente faz um pedido a outro, que, em seguida, acede ao serviço de destino. Se implementar a repetição com uma contagem de três em ambas as chamadas, existem nove tentativas de repetição no total em relação ao serviço. Muitos serviços e recursos implementam um mecanismo de repetição incorporado. Deve investigar como pode desativar ou modificar estes mecanismos se precisar de implementar repetições num nível mais elevado.

  • Nunca implemente um mecanismo de repetição permanente. Ao fazê-lo, é provável que impeça que o recurso ou serviço recupere de situações de sobrecarga e faça com que as ligações de limitação e recusadas continuem por mais tempo. Utilize um número finito de repetições ou implemente um padrão como Disjuntor Automático para permitir que o serviço recupere.

  • Nunca efetue uma repetição imediata mais do que uma vez.

  • Evite utilizar um intervalo de repetição regular quando acede a serviços e recursos no Azure, especialmente quando tem um número elevado de tentativas de repetição. A melhor abordagem neste cenário é uma estratégia de recuo exponencial com uma capacidade de interrupção de circuitos.

  • Impedir que várias instâncias do mesmo cliente ou várias instâncias de clientes diferentes enviem repetições em simultâneo. Se for provável que este cenário ocorra, introduza aleatoriedade nos intervalos de repetição.

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

  • Teste totalmente a estratégia de repetição num conjunto de circunstâncias o mais amplo possível, especialmente quando a aplicação e os recursos ou serviços de destino que utiliza estão sob carga extrema. Para verificar o comportamento durante os testes, pode:

    • Injetar falhas transitórias e nãotransientes no serviço. Por exemplo, envie pedidos inválidos ou adicione código que detete os pedidos de teste e responda com diferentes tipos de erros.

    • Crie uma maquete do recurso ou serviço que devolve um intervalo de erros que o serviço real pode devolver. Abrange todos os tipos de erros que a estratégia de repetição foi concebida para detetar.

    • Para serviços personalizados que cria e implementa, force a ocorrência de erros transitórios ao desativar ou sobrecarregar temporariamente o serviço. (Não tente sobrecarregar quaisquer recursos partilhados ou serviços partilhados no Azure.)

    • Utilize bibliotecas ou soluções que intercetam e modificam o tráfego de rede para replicar cenários desfavoráveis dos seus testes automatizados. Por exemplo, os testes podem adicionar tempos de ida e volta extra, largar pacotes, modificar cabeçalhos ou até mesmo alterar o corpo do próprio pedido. Ao fazê-lo, permite o teste determinista de um subconjunto das condições de falha, para falhas transitórias e outros tipos de falhas.

    • Ao testar a resiliência de uma aplicação Web cliente para falhas transitórias, utilize as ferramentas de programador do browser ou a capacidade da arquitetura de teste de simular ou bloquear pedidos de rede.

    • Execute testes simultâneos e fator de carga elevados para garantir que o mecanismo de repetição e a estratégia funcionam corretamente nestas condições. Estes testes também ajudam a garantir que a repetição não tem um efeito adverso no funcionamento do cliente ou causa contaminação cruzada entre pedidos.

Gerir configurações de políticas de repetição

  • Uma política de repetição é uma combinação de todos os elementos da sua estratégia de repetição. Define o mecanismo de deteção que determina se é provável que uma falha seja transitória, o tipo de intervalo a utilizar (como trás-off regular, exponencial e aleatoriedade), os valores de intervalo reais e o número de vezes a repetir.

  • Implemente repetições em muitos locais, mesmo na aplicação mais simples e em todas as camadas de aplicações mais complexas. Em vez de codificar os elementos de cada política em várias localizações, considere utilizar um ponto central para armazenar todas as políticas. Por exemplo, armazene valores como o intervalo e a contagem de repetições nos ficheiros de configuração da aplicação, leia-os no runtime e crie programaticamente as políticas de repetição. Ao fazê-lo, é mais fácil gerir as definições e modificar e ajustar os 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 ficheiro de configuração de cada vez e utilize predefinições adequadas se os valores não puderem ser obtidos a partir da configuração.

  • Armazene os valores que são utilizados para criar as políticas de repetição no runtime no sistema de configuração da aplicação para que possa alterá-los sem ter de reiniciar a aplicação.

  • Tire partido das estratégias de repetição incorporadas ou predefinidas que estão disponíveis nas APIs de cliente que utiliza, mas apenas quando forem adequadas para o seu cenário. Estas estratégias são geralmente genéricas. Em alguns cenários, podem ser tudo o que precisa, mas noutros cenários não oferecem o leque completo de opções de acordo com os seus requisitos específicos. Para determinar os valores mais adequados, tem de efetuar testes para compreender como as definições afetam a sua aplicação.

Registar e controlar falhas transitórias e nãotransientes

  • Como parte da sua estratégia de repetição, inclua o processamento de exceções e outra instrumentação que regista tentativas de repetição. Espera-se uma falha transitória ocasional e uma repetição e não indicam um problema. No entanto, o número regular e crescente de repetições é, muitas vezes, um indicador de um problema que pode causar uma falha ou que degrada o desempenho e a disponibilidade da aplicação.

  • Registe falhas transitórias como entradas de aviso e não como entradas de erro para que os sistemas de monitorização não as detetem como erros da aplicação que possam acionar alertas falsos.

  • Considere armazenar um valor nas entradas de registo que indica se as repetições são causadas pela limitação no serviço ou por outros tipos de falhas, como falhas de ligação, para que possa diferenciá-las durante a análise dos dados. Um aumento no número de erros de limitação costuma ser um indicador de um problema de design na aplicação ou da necessidade de mudar para um serviço premium que ofereça hardware dedicado.

  • Considere medir e registar os tempos decorridos gerais para operações que incluem um mecanismo de repetição. Esta métrica é um bom indicador do efeito geral das falhas transitórias nos tempos de resposta do utilizador, da latência do processo e da eficiência dos casos de utilização da aplicação. Registe também o número de repetições que ocorrem para que possa compreender os fatores que contribuem para o tempo de resposta.

  • Considere implementar um sistema de telemetria e monitorização que possa gerar alertas quando o número e a taxa de falhas, o número médio de tentativas ou os tempos gerais decorridos antes de as operações serem bem-sucedidas aumentar.

Gerir operações que falham continuamente

  • Considere como lidar com operações que continuam a falhar a cada tentativa. 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, não impede que a aplicação repita a operação com o mesmo número de repetições. Por exemplo, se um serviço de processamento de encomendas falhar com um erro fatal que o coloca fora de ação permanentemente, a estratégia de repetição poderá detetar um tempo limite de ligação e considerá-lo uma falha transitória. O código volta a tentar a operação um número especificado de vezes e, em seguida, desiste. No entanto, quando outro cliente efetua uma encomenda, a operação é novamente tentada, mesmo que falhe sempre.

    • Para evitar repetições contínuas para operações que falham continuamente, deve considerar implementar o padrão de Disjuntor Automático. Quando utiliza este padrão, se o número de falhas dentro de um período de tempo especificado exceder um limiar, os pedidos regressam ao autor da chamada imediatamente como erros e não há nenhuma tentativa de aceder ao recurso ou serviço com falha.

    • A aplicação pode testar periodicamente o serviço, de forma intermitente e com longos intervalos entre pedidos, para detetar quando fica disponível. Um intervalo adequado depende de fatores como a criticidade 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, a aplicação pode retomar as operações normais e transmitir pedidos para o serviço recentemente recuperado.

    • Entretanto, poderá ser capaz de reverter para outra instância do serviço (talvez num datacenter ou aplicação diferente), utilizar um serviço semelhante que ofereça funcionalidades compatíveis (talvez mais simples) ou realizar algumas operações alternativas com base na esperança de que o serviço esteja disponível em breve. Por exemplo, pode ser apropriado armazenar pedidos para o serviço numa fila ou arquivo de dados e repeti-los mais tarde. Em alternativa, poderá redirecionar o utilizador para uma instância alternativa da aplicação, degradar o desempenho da aplicação, mas continuar a oferecer uma funcionalidade aceitável ou simplesmente devolver uma mensagem ao utilizador para indicar que a aplicação não está atualmente disponível.

Outras considerações

  • Quando estiver a decidir os valores do número de repetições e os intervalos de repetição de uma política, considere se a operação no serviço ou recurso faz parte de uma operação de execução longa ou de vários passos. Pode ser difícil ou dispendioso compensar todos os outros passos operacionais que já foram bem-sucedidos quando um falha. Neste caso, um intervalo muito longo e um grande número de repetições podem ser aceitáveis, desde que essa estratégia não bloqueie outras operações ao manter ou bloquear recursos escassos.

  • Considere se repetir a mesma operação pode causar inconsistências nos dados. Se algumas partes de um processo de vários passos forem repetidas e as operações não forem idempotentes, poderão ocorrer inconsistências. Por exemplo, se uma operação que incrementa um valor for repetida, produz 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 detetar mensagens duplicadas. Para impedir estes cenários, desenhe cada passo como uma operação idempotente. Para obter mais informações, veja Padrões de idempotência.

  • Considere o âmbito das operações que são repetidas. Por exemplo, poderá ser mais fácil implementar código de repetição a um nível que abranja várias operações e repita-as se uma falhar. No entanto, fazê-lo pode resultar em problemas de idempotência ou operações de reversão desnecessárias.

  • Se escolher um âmbito de repetição que abranja várias operações, tenha em conta a latência total de todas quando determinar intervalos de repetição, quando monitorizar os tempos decorridos da operação e antes de emitir alertas para falhas.

  • Considere como a estratégia de repetição pode afetar os vizinhos e outros inquilinos numa aplicação partilhada e quando utiliza recursos e serviços partilhados. As tentativas de repetição agressivas podem gerar um número maior de falhas transitórias para estes outros utilizadores e para aplicações que partilhem os recursos e serviços. Da mesma forma, a sua aplicação pode ser afetada pelas políticas de repetição implementadas por outros utilizadores dos recursos e serviços. Para aplicações críticas para a empresa, poderá querer utilizar serviços premium que não são partilhados. Fazê-lo dá-lhe mais controlo sobre a carga e consequente limitação destes recursos e serviços, o que pode ajudar a justificar o custo adicional.

Nota

Veja Problemas e considerações no artigo Padrão de repetição para obter mais orientações sobre compromissos e riscos.

Facilitação do Azure

A maioria dos serviços do Azure e dos SDKs de cliente fornecem um mecanismo de repetição. No entanto, estes mecanismos diferem porque cada serviço tem características e requisitos diferentes e cada mecanismo de repetição é otimizado para o serviço específico. Esta secção resume as funcionalidades do mecanismo de repetição para alguns serviços do Azure utilizados frequentemente.

Serviço Capacidades de repetição Configuração da política Âmbito Funcionalidades de telemetria
Microsoft Entra ID Nativo na Biblioteca de Autenticação da Microsoft (MSAL) Incorporado na biblioteca MSAL Interno Nenhuma
BD do Cosmos para o Azure Nativo no serviço Não configurável Global TraceSource
Azure Data Lake Storage Nativo no cliente Não configurável Operações individuais Nenhuma
Azure Event Hubs Nativo no cliente Programática Cliente Nenhuma
Hub IoT do Azure Nativo no SDK do cliente Programática Cliente Nenhuma
Cache do Azure para Redis Nativo no cliente Programática Cliente TextWriter
Azure Cognitive Search Nativo no cliente Programática Cliente ETW ou personalizado
Azure Service Bus Nativo no cliente Programática NamespaceManager, MessagingFactory e cliente ETW
Azure Service Fabric Nativo no cliente Programática Cliente Nenhuma
Base de Dados SQL do Azure com ADO.NET Polly Declarativa e programática Instruções únicas ou blocos de código Personalizado
Base de Dados SQL com o Entity Framework Nativo no cliente Programática Global por AppDomain Nenhuma
Base de Dados SQL com o Entity Framework Core Nativo no cliente Programática Global por AppDomain Nenhuma
Armazenamento do Azure Nativo no cliente Programática Operações individuais e do cliente TraceSource

Nota

Para a maioria dos mecanismos de repetição incorporados do Azure, não existe atualmente nenhuma forma de aplicar uma política de repetição diferente para diferentes tipos de erros ou exceções. Deve configurar uma política que forneça o desempenho e a disponibilidade médios ideais. Uma forma de ajustar a política é analisar ficheiros de registo para determinar o tipo de falhas transitórias que estão a ocorrer.

Exemplo

Veja Reliable Web app pattern for .NET (Padrão de aplicação Web fiável para .NET ) para obter um exemplo que utiliza muitos dos padrões abordados neste artigo. Também existe uma implementação de referência no GitHub.

Lista de verificação de fiabilidade

Veja o conjunto completo de recomendações.

Lista de verificação de fiabilidade