API Gateway vs Load Balancer

Com o desenvolvimento da tecnologia da Internet, o número de solicitações de dados de rede aumentou drasticamente, o que coloca uma pressão maior nos servidores. Na arquitetura de sistemas dos primeiros dias, um balanceador de carga era tipicamente usado para distribuir o tráfego de rede entre vários servidores, reduzindo assim a carga em um único servidor.

No entanto, atualmente, muitos tipos diferentes de serviços de backend expõem APIs para o mundo externo, resultando em um número crescente de APIs. Como resultado, as limitações da arquitetura de sistemas que dependem principalmente de balanceadores de carga tornaram-se evidentes, já que eles operam principalmente na camada 4 e têm funcionalidade limitada na camada 7. Isso levou ao surgimento de uma infraestrutura chamada API Gateway, que opera principalmente na camada 7 e oferece extensas capacidades de extensão.

Neste artigo, apresentaremos as características distintas do balanceador de carga e dos gateways de API, e exploraremos suas diferenças para ajudar os leitores a entender melhor sua relação.

O que é um Balanceador de Carga?

O papel principal de um balanceador de carga é fornecer funcionalidade de balanceamento de carga para vários serviços de backend, permitindo que eles distribuam o tráfego com base em diferentes algoritmos de balanceamento de carga. A história dos balanceadores de carga é extensa e pode ser categorizada aproximadamente nas seguintes etapas:

• Primeira etapa: Os balanceadores de carga nesta etapa são tipicamente compostos por dispositivos de hardware, que têm alta performance e alta confiabilidade, mas são inflexíveis e caros.

• Segunda etapa: Os balanceadores de carga começaram a ser implementados em software, mais flexíveis e escaláveis, frequentemente aparecendo em distribuições de software e, portanto, menos caros. LVS (Linux Virtual Server) é um exemplo desse tipo.

• Terceira etapa: Com o surgimento da tecnologia de computação em nuvem, os balanceadores de carga também começaram a ter versões em nuvem. Uma vantagem significativa de tal balanceador de carga é que ele pode ajudar as empresas a obter serviços de balanceamento de carga de alta performance a um custo menor. Outra vantagem é que ele pode aproveitar a escalabilidade e elasticidade da computação em nuvem para melhorar a disponibilidade geral. Exemplos de balanceadores de carga em nuvem incluem o Classic Load Balancer, Application Load Balancer e Network Load Balancer da AWS.

Além de distribuir o tráfego e melhorar a escalabilidade da rede, os balanceadores de carga também podem ser usados para melhorar a segurança da rede. Por exemplo, eles podem ser usados para isolar servidores internos da internet pública, prevenindo ataques maliciosos e acesso não autorizado. Um caso de uso simples é um servidor interno contendo informações sensíveis, que um balanceador de carga pode isolar dentro da rede interna para proteger sua segurança de forma eficaz.

O que é um Gateway de API?

Em resumo, um Gateway de API é uma infraestrutura que gerencia e encaminha o tráfego de API, operando principalmente na camada 7. Ele oferece uma robusta escalabilidade que os balanceadores de carga não possuem, incluindo autenticação, observabilidade e plugins personalizados. Algumas de suas principais características são:

• Estratégias de roteamento ricas: Como o Gateway de API opera na camada 7, ele pode analisar dados na camada HTTP/HTTPS. Portanto, ele pode direcionar solicitações para vários servidores upstream com base em condições como o caminho da solicitação, domínio ou cabeçalho.

• Autenticação: O Gateway de API suporta múltiplos métodos de autenticação no nível da API para prevenir solicitações não autorizadas, como OAuth2 e JWT. A autenticação pode ser separada da lógica de negócios e mantida independente para ser não intrusiva ou minimamente intrusiva ao código de negócios.

• Limitação de taxa: A limitação de taxa granular pode ser aplicada em diferentes níveis de roteamento para prevenir ataques maliciosos e evitar sobrecarga dos serviços de backend.

• Observabilidade: Observabilidade refere-se à capacidade de observar o status de execução e a utilização de recursos do programa interno a partir do exterior do sistema. O Gateway de API suporta a vinculação de logs ao Kafka, Google Cloud Logging Service, Elasticsearch, etc., e a vinculação de métricas relevantes ao prometheus, datadog, etc.

• Extensão: Como o Gateway de API em si é um gateway, ele é projetado para ser capaz de se adaptar a diferentes cenários de aplicação de diferentes empresas, como diferentes autenticações de identidade, lançamento canário, políticas de segurança e coleta de logs. Além disso, o Gateway de API deve permitir que os usuários selecionem extensões ou realizem desenvolvimento personalizado; portanto, a escalabilidade é forte, e a seleção de extensões disponíveis é bastante diversificada. Por exemplo, o Apache APISIX tem 13 extensões de autenticação diferentes, cobrindo quase todas as necessidades comuns de autenticação no mercado.

Atualmente, há muitos gateways de API diferentes disponíveis no mercado, como Apache APISIX, Kong, Tyk, Zuul, etc. Os desenvolvedores podem selecionar o Gateway de API mais apropriado de acordo com suas necessidades específicas.

Principais Diferenças Entre Gateway de API e Balanceador de Carga

Áreas de Foco Distintas

Embora tanto o Gateway de API quanto o balanceador de carga suportem proxies de camada 4 e camada 7, o Gateway de API foca principalmente na camada 7, enquanto o balanceador de carga foca principalmente na camada 4.

Portanto, o balanceador de carga, operando na camada 4, tem muitas características vantajosas. Primeiro, ele reduz a sobrecarga de análise de protocolo em comparação com o Gateway de API, resultando em maior capacidade de throughput. Segundo, ele suporta o encaminhamento transparente do endereço IP do cliente, enquanto o Gateway de API normalmente passa o endereço IP do cliente através de cabeçalhos HTTP.

Riqueza de Recursos

Por exemplo, os balanceadores de carga têm capacidades mais fracas de processamento de camada 7 HTTP e frequentemente carecem de recursos como autenticação, autorização, lógica de roteamento complexa e coleta de logs. Enquanto os gateways de API têm capacidades mais fortes de processamento de protocolo de camada 7 e podem anexar várias extensões de recursos, como controle de acesso, registro de logs, gerenciamento de API e computação sem servidor.

Desenvolvimento Personalizado

No mercado de tecnologia em rápida evolução de hoje, muitas empresas exigem a capacidade de suportar desenvolvimento personalizado. Os gateways de API oferecem várias opções de desenvolvimento personalizado, como suporte para diferentes linguagens de programação e a capacidade de injetar lógica de processamento personalizada em diferentes estágios de encaminhamento de tráfego. Por outro lado, os balanceadores de carga não oferecem nenhuma opção de desenvolvimento personalizado.

Formas de Distribuição de Tráfego

Os balanceadores de carga geralmente usam distribuição direta de tráfego para alcançar o balanceamento de carga. Por meio de algoritmos, os dados de tráfego são enviados diretamente para nós específicos de servidores backend, o que significa que cada instância de serviço esperando receber tráfego deve se comportar de forma consistente, reduzindo certa flexibilidade. Em contraste, os gateways de API distribuem o tráfego com base em diferentes dimensões, como URL Path, Domain e Header. Como resultado, as instâncias de serviço esperando receber tráfego podem variar, como uma API privada ou uma API GRPC, tornando a distribuição de tráfego altamente flexível.

Casos de Uso

Caso de Uso de Microsserviços

Para sistemas de arquitetura de microsserviços, um Gateway de API é essencial. Primeiro, ele pode facilmente gerenciar e rotear vários serviços de backend. Segundo, um Gateway de API pode fornecer muitos recursos avançados, como autenticação, autorização, limitação de taxa, encaminhamento e registro de logs. Portanto, diferentes microsserviços não precisam mais implementar repetidamente funções como limitação de taxa e autenticação, tornando a implementação de funções de cada microsserviço mais focada e reduzindo os custos de desenvolvimento.

A arquitetura de microsserviços envolve muitos serviços, tornando os balanceadores de carga de camada 4 inadequados para o balanceamento de carga de vários serviços de backend. Em vez disso, eles são mais adequados para serem usados com serviços de backend monolíticos. Enquanto isso, os balanceadores de carga de camada 7 geralmente não podem oferecer recursos avançados, o que torna suas vantagens sobre os gateways de API em microsserviços menos significativas.

Gerenciamento e Implantação de APIs

O Gateway de API também é altamente adequado em cenários onde há a necessidade de gerenciar e implantar um grande número de APIs, pois ele possui poderosas capacidades de gerenciamento de API. Neste caso, você poderia facilmente habilitar ou desabilitar uma API específica, modificar rapidamente a configuração de encaminhamento de uma API e adicionar recursos como limitação de taxa, autenticação e registro de logs a uma API sem a necessidade de reiniciar o Gateway de API.

Tomando o Apache APISIX como exemplo, ele é um projeto de código aberto de alto nível sob a fundação Apache e atualmente o projeto de gateway de código aberto mais ativo. Como um Gateway de API dinâmico, em tempo real e de alta performance, o Apache APISIX fornece várias funções de gerenciamento de tráfego, como balanceamento de carga, upstream dinâmico, lançamento canário, disjuntor, autenticação de identidade, observabilidade, etc.

Por outro lado, os balanceadores de carga tradicionais são relativamente mais fracos em relação ao gerenciamento de API e precisam de recursos avançados tão ricos.

Acesso de Rede de Alta Performance

Para cenários que exigem alto tráfego e extrema estabilidade para acesso à rede, um balanceador de carga de camada 4 é obviamente mais adequado. Ele pode distribuir diretamente o tráfego original de camada 4 da rede para cada serviço de backend sem o impacto de múltiplas análises de protocolos de camada de aplicação nas camadas intermediárias, tornando-o mais capaz de lidar com maior throughput.

Em contraste, o Gateway de API operando na camada 7, como o ponto de entrada unificado, terá um certo limite de throughput devido à necessidade de analisar protocolos. Mesmo que usar um Gateway de API de camada 4 para acesso à rede não seja particularmente vantajoso porque essa camada não é o foco do Gateway de API. Em comparação com os muitos anos de acumulação técnica dos balanceadores de carga nessa camada, as vantagens dos gateways de API são muito menos significativas.

Resumo

Em geral, o Gateway de API e o balanceador de carga são soluções de infraestrutura usadas para resolver problemas diferentes. O Gateway de API é principalmente usado como um proxy para interfaces de API de backend, fornecendo um ponto de entrada único para acessar diferentes tipos de APIs e funções independentes como limitação de taxa, autenticação e monitoramento. Por outro lado, um balanceador de carga é principalmente usado para distribuição de tráfego de camada 4, espalhando solicitações por vários servidores backend para equilibrar a carga de solicitações e melhorar a disponibilidade geral e a tolerância a falhas do sistema.

Sob um design arquitetônico razoável, o Gateway de API e o balanceador de carga são geralmente usados juntos. Um balanceador de carga é o acesso à rede de todo o sistema, distribuindo o tráfego para várias instâncias de Gateway de API. Cada instância de Gateway de API então roteia, autentica e autoriza solicitações separadamente para tornar toda a rede mais robusta, confiável e escalável.