10 Common API Resilience Design Patterns with API Gateway
November 1, 2023
A resiliência de API trata-se de construir APIs robustas que possam suportar uma variedade de desafios, garantindo que continuem a funcionar de forma eficaz. Os API Gateways desempenham um papel fundamental nisso, atuando como o ponto de entrada para solicitações externas e gerenciando a comunicação entre diferentes serviços, levando em consideração padrões comuns de resiliência de API. Um dos gateways de API de código aberto mais populares, o Apache APISIX, oferece uma variedade de recursos para melhorar a resiliência e robustez das APIs. Neste artigo, exploraremos 10 padrões comuns de design de resiliência de API e como eles podem ser implementados usando o APISIX.
Aqui está uma lista de todos os 10 padrões de resiliência de API:
- Limitação de taxa.
- Repetição.
- Tempo limite.
- Fallback.
- Cache.
- Redundância.
- Verificações de saúde.
- Circuit breaker.
- Bulkhead.
- Injeção de falhas.
O que é resiliência de API?
A resiliência de API refere-se à capacidade de uma API de desempenhar suas funções pretendidas de forma consistente e confiável, mesmo diante de erros, tráfego intenso ou condições inesperadas. Não se trata de evitar falhas, mas de aceitar o fato de que as falhas acontecerão e responder a elas de uma forma que evite tempo de inatividade ou perda de dados. O objetivo da resiliência é retornar a aplicação a um estado de pleno funcionamento após uma falha. APIs resilientes são construídas para lidar com falhas de forma elegante, sejam essas falhas originadas dentro da própria API, de serviços dependentes ou devido a fatores externos, como problemas de rede ou latência, incompatibilidade de versão da API e outros problemas que possam surgir devido a mudanças no ambiente ou comportamento inesperado do usuário.
Por que resiliência de API no API Gateway?
Muitas estruturas de desenvolvimento de software existentes abrangem um conjunto de práticas e padrões projetados para garantir que as APIs permaneçam disponíveis, responsivas e precisas. No entanto, implementar a resiliência de API no nível do API Gateway, em vez de em serviços individuais ou em outro lugar do sistema, oferece várias vantagens estratégicas.
1. Controle centralizado: O API Gateway serve como um ponto central de entrada para todas as solicitações de API, proporcionando uma oportunidade única de gerenciar e impor padrões de resiliência em todos os serviços de forma unificada. Essa centralização simplifica a implementação e manutenção de recursos de resiliência.
2. Consistência: Ao lidar com a resiliência no API Gateway, você garante uma abordagem consistente para lidar com falhas, limitação de taxa, tempos limite e outras estratégias de resiliência em todos os serviços. Essa consistência é crucial para manter um comportamento de sistema confiável e previsível.
3. Redução da complexidade: Implementar recursos de resiliência em cada microsserviço pode levar a esforços duplicados e aumento da complexidade. O API Gateway abstrai essas preocupações, permitindo que os desenvolvedores de serviços se concentrem na lógica de negócios em vez de lidar com a resiliência.
4. Melhor utilização de recursos: O API Gateway pode gerenciar recursos de forma eficiente e distribuir o tráfego, garantindo que nenhum serviço único seja sobrecarregado. Esse balanceamento de carga contribui para a resiliência geral do sistema.
5. Monitoramento e registro facilitados: Ter um único ponto por onde todo o tráfego de API flui facilita o monitoramento da saúde dos seus serviços e o registro de quaisquer problemas. Essa visão centralizada é inestimável para identificar e responder rapidamente a problemas.
6. Segurança simplificada: Medidas de segurança, como autenticação, autorização e criptografia, podem ser aplicadas de forma consistente no API Gateway, garantindo que todos os serviços estejam protegidos sem a necessidade de configurações redundantes.
7. Desempenho aprimorado: O API Gateway pode implementar cache e agregação de respostas, reduzindo o número de chamadas para serviços de backend e melhorando o desempenho geral do sistema.
8. Degradação graciosa: No caso de uma falha de serviço, o API Gateway pode redirecionar o tráfego ou fornecer respostas de fallback, garantindo que o sistema degrade de forma graciosa e continue a fornecer funcionalidade.
9. Recuperação mais rápida: A natureza centralizada do API Gateway permite a implementação rápida de correções e atualizações, garantindo que o sistema possa ser rapidamente restaurado ao pleno funcionamento após uma falha.
10. Interação simplificada com o cliente: Os clientes precisam interagir apenas com o API Gateway, que fornece uma interface consistente e confiável, abstraindo a complexidade dos microsserviços subjacentes.
Do ponto de vista do desenvolvimento, a abordagem do API Gateway também reduz o tempo para implementar padrões de resiliência comumente usados. Vamos descobrir cada padrão no exemplo da comunicação de API entre serviços em um aplicativo típico de conferência e entender como habilitá-los.
Este post foca principalmente na parte teórica e fornece referências à documentação relevante. Os desenvolvedores podem implementar esses padrões verificando cada link e seguindo os guias fornecidos. Com o APISIX, é possível configurar esses padrões de design usando a Admin API, um arquivo YAML estático ou o APISIX Dashboard.
1. Limitação de taxa
Como o nome sugere, a limitação de taxa controla o número de solicitações que um cliente pode fazer em um determinado período de tempo. O APISIX oferece um plugin limit-req para configurar a limitação de taxa. Este plugin permite que você defina regras com base nas propriedades de solicitações individuais (muitas de um determinado usuário, aplicativo cliente ou localização) para limitar solicitações, garantindo que sua API não seja sobrecarregada por muitas solicitações.
A política de limitação de taxa também pode ser usada para limitar o acesso a usuários não autorizados. Confira o guia para ver como usar o plugin para limitação de taxa.
2. Repetição
O padrão de repetição envolve a repetição automática de uma solicitação de API se ela falhar. Com o APISIX, você pode configurar o mecanismo de repetição para um objeto Upstream para especificar o número de repetições e as condições sob as quais uma repetição deve ser tentada.
Ao configurar o upstream com propriedades de repetição, o APISIX envia solicitações de repetição automática para o serviço backend de participantes se a solicitação anterior tiver expirado ou falhado devido a um problema de rede.
3. Tempo limite
Definir um tempo limite garante que uma solicitação não fique pendente indefinidamente se o serviço de backend não responder. O APISIX permite que você configure tempos limite para suas APIs na mesma configuração do objeto Upstream, garantindo que as solicitações sejam encerradas se demorarem muito para responder.
No caso de o serviço de participantes responder lentamente, o APISIX pode aplicar um padrão fail-fast e responder rapidamente à solicitação do aplicativo cliente para melhorar a responsividade do sistema geral.
4. Fallback
Um padrão de fallback fornece uma resposta padrão quando um serviço está indisponível. O APISIX permite que você defina as prioridades do upstream quando o endpoint principal falha, o API Gateway pode redirecionar o tráfego para um serviço secundário ou retornar uma resposta predefinida usando um plugin response-rewrite em caso de falhas de serviço como HTTP 500.
Ou você pode usar o plugin proxy-cache para armazenar respostas em cache e servi-las quando o backend estiver inativo. Por exemplo, o aplicativo móvel mostra uma lista de participantes da conferência em cache quando o serviço de participantes está inativo.
5. Cache
O cache de respostas pode reduzir significativamente a carga nos seus serviços de backend. O APISIX oferece um plugin proxy-cache que permite armazenar respostas em cache e servi-las diretamente do API Gateway, reduzindo a latência e melhorando o desempenho.
Confira o tutorial Cache API responses para aprender como usar o plugin proxy-cache.
6. Redundância
Todo API Gateway fornece um recurso comum como Load Balancing que distribui as solicitações de API recebidas entre vários serviços de backend (nós ou instâncias). Ter instâncias redundantes torna o sistema mais robusto contra eventos irregulares. O APISIX suporta vários algoritmos para balanceamento de carga, como round-robin, menor número de conexões e hashing consistente.
No caso do serviço de participantes, você pode iniciar duas instâncias e, se o servidor A falhar, as solicitações podem ser atendidas pelo segundo servidor.
7. Verificações de saúde
A verificação de saúde é um mecanismo que determina se os serviços upstream estão saudáveis ou não com base em sua capacidade de resposta. O APISIX identifica se o serviço está disponível ou não usando verificações de saúde ativas do upstream. Com as verificações de saúde habilitadas, o APISIX só encaminhará solicitações para serviços upstream considerados saudáveis e não encaminhará solicitações para serviços considerados não saudáveis.
Para verificar a saúde da API periodicamente, o APISIX precisa de um caminho HTTP do endpoint de saúde do serviço upstream. Portanto, você precisa primeiro adicionar o endpoint /health para o serviço de participantes.
8. Circuit breaker
O padrão Circuit Breaker impede que um sistema faça chamadas para um serviço que provavelmente falhará, protegendo assim o sistema de falhas em cascata. O APISIX oferece duas opções para implementar a funcionalidade de circuit breaker: Usando um plugin api-breaker em uma configuração de Route ou habilitando verificações de saúde passivas do upstream. Ambas as formas lidam com falhas e impedem que serviços upstream façam tentativas constantes de repetição se o serviço falhar ou estiver lento.
O APISIX monitora o número de falhas recentes que ocorreram e usa essas informações para decidir se permite que a operação prossiga ou simplesmente retorna uma exceção imediatamente.
9. Bulkhead
O padrão Bulkhead isola elementos dentro de uma aplicação, garantindo que, se uma parte do sistema falhar ou estiver sob carga pesada, as outras partes do sistema continuem a funcionar. Para garantir que o tráfego intenso ou problemas nas operações de leitura do serviço de participantes não afetem a disponibilidade e o desempenho das operações de escrita no serviço de participantes, você pode implementar o padrão Bulkhead usando o APISIX.
Você cria endpoints de rota separados no API Gateway para dois nós upstream, de modo que todas as solicitações de escrita sejam encaminhadas para o Serviço A e todas as solicitações de leitura para o Serviço B.
10. Teste de caos
O teste de caos pode ajudar a garantir que uma API seja resiliente em ambientes de produção. Usando-o, você pode avaliar e fortalecer a resiliência da sua aplicação ou APIs de microsserviços contra vários tipos de falhas, aumentando a confiabilidade. Esse método permite a introdução intencional de atrasos e o término forçado de solicitações com códigos de erro designados, facilitando a simulação de vários cenários adversos, incluindo interrupções de serviço, demanda excessiva de serviço, atrasos significativos de rede e segmentação de rede.
O Plugin de Injeção de Falhas do APISIX também oferece o mesmo mecanismo para simular vários cenários de falha, como erros ou atrasos no serviço de participantes, para testar como o aplicativo cliente reage a eles.
Conclusão
Neste post do blog, revisamos 10 padrões comuns de design de resiliência de API, demonstrando como implementá-los de forma eficaz usando o APISIX. Ao centralizar as estratégias de resiliência no nível do API Gateway, as organizações podem alcançar um gerenciamento consistente, simplificado e eficiente do tráfego de API e do tratamento de erros.