Um erro comum ao migrarmos nossas aplicações para a nuvem, é esperarmos que a mesma funcione exatamente igual a quando hospedamos on-premises, porém, com o poder da elasticidade oferecido pela nuvem. No entanto, acabamos encontrando erros transientes e difíceis de reproduzir.
Muitas vezes esses erros estão relacionados com a maneira que o provedor de nuvem alterna os recursos de hardware para melhor balanceamento de diversas cargas de trabalho. Durante esse período de reconfiguração, você pode enfrentar problemas de conectividade com o Banco de Dados SQL ou quando faz uma chamada à um serviço externo via http.
Sendo assim, devemos assumir que estes erros irão acontecer e preparar nossas aplicações para tratar erros transientes e efetuar uma nova tentativa à operação algum tempo depois (considerando milissegundos ou até mesmo segundos de delay).
Por ser um “erro” comum, já existe um padrão de projeto para o erro descrito anteriormente. Trata-se do Retry Pattern.
Padrão de projeto
Em engenharia de software, um padrão de projeto (do inglês design pattern) é uma solução geral reutilizável para um problema que ocorre com frequência dentro de um determinado contexto no projeto de software.
Retry Pattern:
Exemplo de implementação:
int tentativas = 3;
while(true) {
try {
ExecutarOperacao();
break; // sucesso!
} catch {
if(--tentativas == 0) throw;
else Thread.Sleep(1000);
}
}
Repare que no exemplo anterior não estamos tratando a Exception e efetuando uma nova tentativa até um limite máximo de três tentativas. O ideal seria validar se trata-se de um erro transiente ou não, antes de tentar executar novamente.
Por exemplo:
int tentativas = 3;
while(true) {
try {
ExecutarOperacao();
break; // sucesso!
} catch(TimeoutException e) {
if(--tentativas == 0) throw;
else Thread.Sleep(1000);
}
catch {
throw;
}
}
Observação: os exemplos acima servem apenas para demonstrar como funciona o padrão de projeto e não devem ser usados em produção!
Para uso em produção, eu recomendo o uso de bibliotecas que forneçam maior flexibilidade para tratamento dos erros, número de tentativas e do delay. Você pode usar o The Transient Fault Handling Application Block da Microsoft ou a biblioteca Polly.
Muitas vezes o padrão de projeto Retry Pattern é usado em conjunto com o Padrão Circuit Breaker, para evitar novas chamadas à serviços que sabemos que estão fora do ar e/ou sobrecarregados.
Para maiores informações sobre o Circuit Breaker, acesse:
Até o próximo artigo, pessoal!
De 0 a 10, o quanto você recomendaria este artigo para um amigo?