Design para resiliência
 A carga de trabalho deve continuar a operar com funcionalidade total ou reduzida. |
|---|
Você deve esperar que ocorram falhas de componentes, interrupções de plataforma, degradações de desempenho e outras falhas. Crie resiliência no sistema para que ele seja tolerante a falhas e possa degradar-se graciosamente.
Cenário de exemplo
A Contoso Air é uma companhia aérea comercial que tem um departamento de desenvolvimento interno. O aplicativo LOB principal é uma solução de reserva que permite que os clientes reservem voos diretamente com a Contoso Air. O aplicativo é criado no Azure e usa o Serviço de Aplicativo do Azure, o Cosmos DB, o Azure Functions, os Aplicativos Lógicos do Azure e o Barramento de Serviço do Azure.
Determinar os riscos de falha
Identificar potenciais pontos de falha no sistema, especialmente para os componentes críticos, e determinar o efeito sobre os fluxos do usuário e do sistema.
Analise o caso de falha, o raio de explosão e a intensidade da falha para cada ponto de falha potencial. Os casos de falha e sua intensidade podem variar de cenários de impacto relativamente baixo, como a perda temporária de um processo de back-end, a interrupções em grande escala resultantes de desastres. A execução dessa análise ajuda a determinar o design dos recursos de tratamento de erros no nível do componente.
O desafio da Contoso
- O aplicativo LOB fornece muitas funções-chave que vão desde o marketing até o comércio. O fluxo de usuários de compra de tíquetes foi identificado como o fluxo mais crítico. A equipe de carga de trabalho determinou que mais medidas de confiabilidade devem ser implementadas para garantir que o fluxo seja otimizado para resiliência.
- A equipe tem tempo orçado para melhorias como dissociar componentes e redesenhar fluxos, mas quer garantir que está usando esse tempo para se concentrar nas melhorias de maior valor.
Aplicação da abordagem e dos resultados
- A equipe identifica o gateway de pagamento externo como um potencial ponto de falha. O gateway é altamente disponível, mas há um potencial para usuários que experimentam falhas transitórias ocasionais resultantes de problemas de rede ou explosões de solicitações extremamente altas. O gateway pode rejeitar algumas solicitações quando está sobrecarregado por várias solicitações simultâneas sendo enviadas.
- A equipe determina que os usuários devem reenviar solicitações quando o gateway rejeita suas solicitações iniciais, causando uma experiência de usuário negativa.
Implementar mecanismos de autopreservação
Crie recursos de autopreservação usando padrões de projeto corretamente e modularizando o projeto para isolar falhas.
Ao criar recursos de autopreservação no sistema, você poderá evitar que um problema afete os componentes a jusante. O sistema será capaz de mitigar falhas transitórias e permanentes, gargalos de desempenho e outros problemas que podem afetar a confiabilidade. Você também será capaz de minimizar o raio de explosão.
O desafio da Contoso
- A equipe quer minimizar o risco de falhas transitórias que fazem com que as solicitações dos usuários sejam rejeitadas pelo gateway de pagamento. Devido à natureza transitória de algumas das condições de erro, há uma alta probabilidade de que a mesma solicitação seja bem-sucedida se for reenviada.
Aplicação da abordagem e dos resultados
- A equipe desenvolve uma lógica personalizada no fluxo para tentar novamente a transação após um pequeno atraso quando uma falha que pode ser repetida é detetada.
- O design da solução será modificado para incorporar o Padrão de Repetição, aumentando ligeiramente o tempo de espera entre as novas tentativas até que a solicitação seja processada com êxito ou o número máximo de falhas seja atingido.
- A equipe também decide dissociar a interação do usuário e a funcionalidade de processamento de pagamento de back-end desse fluxo usando uma abordagem orientada a eventos com o Barramento de Serviço do Azure. Quando ocorrem falhas irrecuperáveis durante o processamento da mensagem (após o número máximo de tentativas), o processador de back-end abandona o processamento dessa solicitação, deixando a mensagem na fila para que possa ser reprocessada posteriormente.
Crie redundância e resiliência abrangentes
Crie redundância em camadas e resiliência em várias camadas de aplicativos.
Visar redundância em utilitários físicos e replicação imediata de dados. Visar também redundância na camada funcional que abrange serviços, operações e pessoal. A redundância ajuda a minimizar pontos únicos de falha. Por exemplo, se houver uma interrupção que afete um ou mais componentes, uma zona de disponibilidade ou uma regional inteira, uma implantação redundante (ativo-ativo ou ativo-passivo) permitirá que você atinja as metas de tempo de atividade.
A adição de intermediários evita a dependência direta entre componentes e melhora o buffer. Ambos os benefícios endurecem a resiliência do sistema.
O desafio da Contoso
- A implementação de novas tentativas e a dissociação das chamadas de gateway de pagamento da interface do usuário usando o Service Bus aumentaram drasticamente a confiabilidade desse fluxo, mas as partes interessadas do negócio ainda se preocupam com a perda de dados que pode acontecer devido a uma falha catastrófica na região primária.
Aplicação da abordagem e dos resultados
- A equipe decide atualizar para o nível premium do Service Bus. Ao fazer isso, eles podem aproveitar a funcionalidade de suporte às zonas de disponibilidade dessa camada. Com essa funcionalidade, várias cópias dos dados são armazenadas em três instalações fisicamente separadas (zonas de disponibilidade), e o serviço tem reservas de capacidade suficientes para lidar instantaneamente com a perda completa e catastrófica de um datacenter.
- Além disso, a equipe configura a recuperação de desastres geográficos do Barramento de Serviço do Azure para replicar continuamente dados para uma região secundária que será usada no caso improvável de uma falha completa da região primária.