Criando uma rede de aplicativos tolerante a falhas

Criando uma rede de aplicativos tolerante a falhas

Criando uma rede de aplicativos tolerante a falhas
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Uma rede de aplicativos permite que as organizações conectem aplicativos, dados e dispositivos por meio de APIs que expõem seus ativos e dados a outros sistemas na rede. À medida que uma rede de aplicativos cresce, mais reutilização será fornecida. Reutilizar APIs anda de mãos dadas com um alto grau de dependência entre APIs. Portanto, um alto grau de dependência entre suas APIs significa que as falhas durante a chamada de uma API afetarão outras implementações de API e os serviços que eles oferecem à rede de aplicativos. Enquanto tudo seguir o caminho feliz, nada acontecerá. Porém, assim que algo der errado durante uma chamada de API – e em algum momento algo der errado – as falhas serão propagadas transitivamente pela rede de aplicativos e causarão falhas posteriores de outras APIs dependentes. Por esse motivo, tornar suas invocações de API tolerantes a falhas é fundamental para uma rede de aplicativos bem-sucedida.

Esteja você criando suas primeiras APIs ou já possuindo uma enorme rede de aplicativos, saiba como tornar sua rede de aplicativos mais tolerante a falhas.

Como obter tolerância a falhas em uma rede de aplicativos

Um cliente de API é um componente de aplicativo que acessa um serviço chamando uma API desse serviço. Um exemplo disso pode ser chamar uma API de experiência de um aplicativo da web. Porém, com a conectividade liderada por API, isso pode ser chamado de API de processo dentro de uma API de experiência ou de API de sistema a partir de uma API de processo.

Uma chamada de API tolerante a falhas é uma chamada de um cliente de API para uma implementação de API em que uma falha da chamada não leva a uma falha do cliente. Como o próprio cliente geralmente é uma implementação de API, a API fornecida por essa implementação de API não faz com que seus clientes tenham falhas.

Leia Também  30 APIs para rastrear vírus Corona

A prioridade número um de tornar as invocações da API tolerantes a falhas é interromper a propagação transitiva de falhas.

Um cliente de API (verde) que é em si uma implementação de API expõe uma API a clientes de API upstream (azul) e que emprega invocações de API tolerantes a falhas para uma API downstream (vermelho).

Etapas para implementar invocações de API tolerantes a falhas:

1. Timeout

A primeira etapa para aplicar a tolerância a falhas na sua rede de aplicativos é configurar um tempo limite para suas solicitações. Isso reduzirá o risco de quebrar o SLA do cliente da API, mesmo que a chamada da API tenha êxito. Também reduzirá a probabilidade maior do que o normal de falhar de qualquer maneira sem tempo limite. Por esses dois motivos, os tempos limite para invocações da API devem ser definidos com cuidado – o mais baixo possível – e de acordo com o SLA do cliente da API.

Os clientes de API que foram implementados como aplicativos Mule e estão executando no mecanismo de tempo de execução do Mule oferecem opções diferentes para configurar tempos limite. Você pode configurá-lo no nível da sua solicitação HTTP, para toda a transação ou como parte das construções de controle (por exemplo, Scatter-Gather).

Depois que uma chamada de API falhar, ela poderá ser bem-sucedida ao tentar chamar essa API novamente. Mas essa abordagem só terá êxito se a falha for transitória e não permanente. Geralmente, é difícil para um cliente de API detectar, sem dúvida, que uma falha, que ocorreu durante uma chamada de API, é de natureza transitória. É por isso que a abordagem padrão é tentar novamente todas as chamadas de API com falha.

Com as APIs REST, um código de resposta no intervalo de 4xx significa um erro do cliente que é quase sempre permanente e, portanto, não deve ser tentado novamente. Isso não se aplica aos códigos de resposta HTTP “408 Request Timeout”, “423 Locked” e “429 Too Many Requests”, que devem ser tratados como falhas transitórias. Sempre se espera que os códigos de resposta HTTP no intervalo de 5xx signifiquem uma falha de natureza transitória. Além disso, apenas métodos HTTP idempotentes (GET, HEAD, OPTIONS, PUT e DELETE) podem ser tentados novamente sem causar processamento duplicado indesejado.

Leia Também  Como fazer o trabalho de casa ... trabalhar!

Nos aplicativos Mule, você pode usar o Conector de Solicitações HTTP e o Escopo até o Sucesso para configurar novas tentativas de chamadas de API. O HTTP Request Connector fornece a capacidade de interpretar certos códigos de status de resposta HTTP como falhas.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Tentando novamente as chamadas da API duas vezes, com pequenos atrasos entre novas tentativas e tempos limite curtos para cada chamada da API.

No entanto, como uma chamada de API de tempo limite excede a falha, definir um tempo limite com uma estratégia de repetição é apenas o primeiro passo para obter tolerância a falhas.

2. Chamada de fallback

Caso uma chamada de API falhe – mesmo após um certo número de tentativas – pode ser adequado chamar uma API diferente como fallback. Uma API de fallback, por definição, nunca será ideal para a finalidade do cliente da API, caso contrário, seria a API principal.

Aqui estão alguns exemplos de APIs de fallback:

  • Uma versão antiga e obsoleta da mesma API.
  • Um ponto de extremidade alternativo da mesma API e versão (por exemplo, API em outra região do CloudHub).
  • Uma API que faz mais do que o necessário e, portanto, não é tão eficiente quanto a API principal.
  • Uma API está fazendo menos do que o necessário e, portanto, forçando o API Client a oferecer um serviço degradado – o que ainda é melhor do que nenhum serviço.

Os clientes da API implementados como aplicativos Mule oferecem à sua disposição as estratégias “Até escopo e exceção até o sucesso”, que juntos permitem configurar ações de fallback, como uma invocação da API de fallback.

Após as tentativas na API principal não terem sido bem-sucedidas, uma API de fallback é invocada, mesmo que a API não seja uma substituição completa da API principal.

Caso a API primária e a API de fallback se esgotem, vamos adicionar outra estratégia para tornar nossa rede de aplicativos mais tolerante a falhas.

3. Cache do lado do cliente

Essa estratégia usará um resultado de uma chamada de API anterior. O cliente da API precisa implementar o cache do lado do cliente, onde os resultados das invocações da API são preservados indexados pela entrada. O resultado de uma chamada de API pode ser encontrado no cache pela entrada da chamada de API que acabou de falhar. Somente resultados de métodos HTTP seguros como GET, HEAD ou OPTIONS devem ser armazenados em cache.

Leia Também  Portfólios digitais de produtos para energia e serviços públicos

No entanto, o armazenamento em cache aumenta o espaço de memória do cliente da API e adiciona uma sobrecarga de processamento para preencher o cache após cada chamada de API bem-sucedida.

Os clientes da API implementados como aplicativos Mule têm disponível o Escopo do Cache e o Conector de Armazenamento de Objeto, ambos compatíveis com o cache do lado do cliente.

Usando um resultado em cache como um substituto para falhas nas invocações da API.

Caso você não tenha o cache do lado do cliente implementado ou simplesmente não exista um resultado em cache, vamos dar uma olhada em nossa estratégia final de tolerância a falhas.

4. Resultado de fallback

A última razão para evitar falhas que se propagam transitivamente pela rede de aplicativos é fornecer ao cliente da API um resultado estático. Essa estratégia funciona melhor para APIs que retornam resultados relacionados a dados de referência, como países, estados, moedas ou produtos. Pode não ser o resultado ideal para o seu cliente de API, mas pode ser a melhor opção do que não retornar um resultado. O princípio é preferir um serviço degradado a nenhum serviço.

Os clientes de API implementados como aplicativos Mule têm muitas opções disponíveis para armazenar e carregar resultados estáticos. Uma dessas opções é usar propriedades que podem ser atualizadas via Anypoint Runtime Manager usando a interface da Web da Web ou APIs da plataforma, caso o aplicativo Mule seja implementado no CloudHub.

Usando resultados configurados estaticamente como fallback para falhas de invocações de API e nenhum cache do lado do cliente.

Tornar a sua rede de aplicativos tolerante a falhas se torna cada vez mais importante quanto maior a sua rede de aplicativos. Se você quiser saber mais sobre como criar redes de aplicativos com sucesso, consulte o curso Anypoint Platform Architecture: Application Networks.


cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso