O que é um API Gateway e por que ele é essencial?

Introdução às APIs

O que é uma API (Interface de Programação de Aplicações)? Uma API é uma forma padrão de trocar dados entre diferentes aplicações e sistemas. Muitas equipes de desenvolvimento adotam a abordagem API-first, onde a iteração é focada na API, desde o design, implementação, teste, segurança, implantação, solução de problemas e análise de APIs, que é o gerenciamento do ciclo de vida completo da API (APIM).

Antes do advento das APIs, não havia uma forma padrão de trocar dados. Os programas de computador se comunicavam entre si usando uma variedade de protocolos, como FTP, FTPS, SFTP, HTTPS, etc. A falta de padrões cria altos custos de desenvolvimento e riscos de segurança ocultos em muitas dimensões: controle de permissões, gerenciamento de dados, limitação de taxa, auditoria, etc. Este é o "Torre de Babel" no mundo da computação. Para construir um produto suficientemente complexo, devemos resolver os problemas causados por sistemas desenvolvidos em diferentes linguagens e diferentes esquemas de armazenamento de dados.

O surgimento da API resolveu com sucesso o problema da "Torre de Babel". Os desenvolvedores só precisam se concentrar nas APIs expostas por outros sistemas e não precisam entender os detalhes de implementação subjacentes.

A conexão e a transmissão de dados entre dispositivos clientes e servidores para aplicativos móveis, jogos online, streaming de vídeo ao vivo, conferências remotas e dispositivos IoT são todos inseparáveis das APIs. As APIs desempenham um papel importante em suas comunicações.

Por que usar um API Gateway?

O API Gateway é um componente essencial no gerenciamento do ciclo de vida completo da API. Ele é responsável pela configuração, liberação, reversão de versão, segurança e balanceamento de carga da API no ambiente de produção. Além disso, o API gateway é a entrada de todo o tráfego do cliente, responsável por rotear a solicitação de API do cliente para o serviço upstream correto para processamento e, em seguida, retornar os dados devolvidos ao solicitante original, garantindo a segurança, confiabilidade e baixa latência de todo o processo.

Quando não há muitas APIs no início, o API gateway geralmente é um componente virtual unido pelo servidor web e serviços upstream. Funcionalidades simples, como roteamento, encaminhamento, proxy reverso e balanceamento de carga, são feitas por Apache, NGINX e alguns outros componentes; outras funcionalidades, como autenticação e limitação de taxa, dependem dos serviços upstream.

Por que você precisa de um API Gateway?

No entanto, à medida que o número de APIs aumenta, os desenvolvedores "preguiçosos" encontraram um problema grave. Em diferentes partes dos serviços upstream, a mesma autenticação, limitação de taxa, registro e algumas outras funções são codificadas repetidamente. Isso não só é um desperdício de recursos, mas também um pesadelo de gerenciamento de código. Quando uma parte do código é modificada ou atualizada, o código em outros lugares também precisará ser atualizado. Como resolvemos esse problema? Os desenvolvedores inteligentes encontraram uma solução rapidamente: abstrair (extrair) as funções comuns e colocá-las em um único componente. Extraímos o código que não está relacionado à lógica de negócios dos serviços upstream e aprimoramos os componentes Apache e NGINX. Essa é a evolução do API gateway de primeira geração.

A direção da evolução do API gateway é incorporar o maior número possível de funcionalidades não relacionadas ao negócio. Para acelerar a iteração do produto, os desenvolvedores de front-end e back-end exigem cada vez mais dos API gateways, não apenas limitados a funcionalidades tradicionais, como roteamento, encaminhamento, proxy reverso e balanceamento de carga, mas também demandam funcionalidades para observabilidade, como gRPC e GraphQL.

O papel dos API gateways

Para tornar o API gateway mais flexível e eficiente, os desenvolvedores de API gateways fizeram muitas inovações na estrutura subjacente, como:

• Plugins de Funcionalidades. À medida que mais e mais funcionalidades são incorporadas ao API gateway, como separamos cada funcionalidade para facilitar o desenvolvimento? Um mecanismo de plugin semelhante ao Lego seria a solução perfeita. Os principais API gateways usam plugins. No Apache APISIX, é chamado de "plugins". No Envoy, é chamado de "filtros". Os plugins libertam os desenvolvedores de gateways dos detalhes de implementação, e menos recursos de desenvolvimento são necessários para implementar novas funcionalidades.
• Separação do Plano de Dados e Plano de Controle. Na primeira geração de API gateway, o Plano de Dados e o Plano de Controle são implementados no mesmo processo de computador. É mais fácil para os usuários implantar e usar, mas cria riscos de segurança significativos. O Plano de Dados fornece serviços diretamente para o mundo exterior. Se hackers invadirem o Plano de Dados a partir do exterior, eles poderão obter permissões de controle e dados do Plano de Controle (como certificados SSL), potencialmente causando danos mais devastadores. Portanto, a maioria dos API gateways de código aberto agora implantam DP e CP separadamente e usam bancos de dados relacionais ou etcd para gerenciamento e sincronização de configurações.

Tomando o Apache APISIX como exemplo, o seguinte diagrama de arquitetura ilustra as inovações acima:

Desafios do Cloud-Native

A maior mudança tecnológica na TI na última década foi o cloud-native. O Docker, nascido em 2013, abriu o cenário do cloud-native. Desde então, o hardware físico e as máquinas virtuais foram substituídos por contêineres, e as arquiteturas monolíticas foram substituídas por microsserviços. No entanto, o cloud-native não é uma simples revolução tecnológica. A força motriz por trás disso vem do rápido desenvolvimento e da feroz concorrência dos produtos da Internet. As tecnologias relacionadas ao cloud-native nasceram no momento certo e rapidamente se popularizaram, substituindo muitas arquiteturas e soluções técnicas anteriores. Especificamente, os desafios do API gateway no cloud-native vêm principalmente de dois dos seguintes aspectos:

Monolítico para Microsserviços

Depois que a arquitetura de microsserviços ganhou popularidade entre os desenvolvedores, liberou enormes dividendos técnicos. Os microsserviços podem ser atualizados e liberados em seu próprio ritmo, sem se preocupar com o acoplamento com outros serviços. As iterações de produtos são, portanto, ágeis, com dezenas ou até centenas de lançamentos por dia.

No entanto, o desenvolvimento de microsserviços também traz alguns efeitos colaterais, como:

• O número de APIs e microsserviços cresceu de dezenas para milhares ou até dezenas de milhares.
• Como localizamos rapidamente qual API causou o erro?
• Como garantimos a segurança da API?
• Como alcançamos o circuito de serviço e a degradação de serviço?

O API gateway não pode resolver problemas de segurança, observabilidade e lançamento canário por si só. Ele precisa cooperar com muitos outros projetos de código aberto e serviços SaaS, como Prometheus, Zipkin, Skywalking, Datadog, Okta, etc., para fornecer melhores soluções para as empresas.

Gerenciamento Dinâmico e de Cluster

O primeiro desafio vem do ecossistema, enquanto o segundo vem da tecnologia.

Dinâmico

A popularidade dos contêineres e do Kubernetes tornou a dinâmica uma característica padrão de todos os componentes fundamentais do cloud-native. No ambiente do Kubernetes, os contêineres estão constantemente sendo criados e destruídos, e o dimensionamento elástico tornou-se uma necessidade, não uma opção.

Imagine um cenário: uma empresa de comércio eletrônico realiza uma promoção, e milhões de usuários entram em uma hora e saem após o término da promoção. Nesse cenário, empresas com arquitetura tradicional devem comprar um lote de servidores físicos para lidar com o tráfego de API nos horários de pico. Em contraste, empresas com arquitetura cloud-native podem usar os recursos elásticos na nuvem pública a qualquer momento. Eles podem ajustar a escala da rede, poder de computação, bancos de dados e outros recursos automaticamente com base no número de solicitações de API.

Também há desafios técnicos associados ao dimensionamento elástico de contêineres:

• Serviços upstream mudando frequentemente endereços IP e portas.
• Atualizações frequentes de listas de permissões e negações de IP.
• Detecção e tratamento de exceções de saúde do serviço.
• Lançamentos regulares de APIs.
• Atualização de registro e descoberta de serviços.
• Renovação quente e rotação automática de certificados SSL.

No centro da resolução desses desafios técnicos está a dinâmica.

Os API gateways de primeira geração representados pelo NGINX têm capacidades dinâmicas fracas. Como o NGINX é impulsionado por arquivos de configuração estáticos locais, qualquer alteração na configuração exigirá a recarga do serviço NGINX para entrar em vigor, o que é inaceitável para empresas na era do cloud-native. Este é o primeiro ponto de dor técnico do API gateway de primeira geração.

Gerenciamento de Cluster

O segundo ponto de dor técnico é o gerenciamento de cluster.

A WPS, uma empresa de software de escritório SaaS na China, que fornece software como o Microsoft Office 365. Eles têm centenas de máquinas físicas executando o Apache APISIX, quase 10.000 núcleos de CPU processando solicitações de API de clientes e processando dezenas de bilhões de APIs diariamente.

Nesse ambiente de API gateway em escala ultra-grande, é impossível para os desenvolvedores modificar a configuração de cada API gateway um por um e, em seguida, recarregá-los. Em vez disso, eles querem um console integrado para operar todo o cluster. Infelizmente, quando a primeira geração de API gateways nasceu, não havia uma escala de instância tão grande, então os desenvolvedores da primeira geração de gateways não consideraram as necessidades de gerenciamento de cluster.

API Gateway de Próxima Geração

Os desafios e pontos de dor acima deram origem gradualmente a uma nova geração de API gateways.

Características do API Gateway de Próxima Geração

Diferente da primeira geração de API gateways, a comunidade de código aberto é a principal força que impulsiona o desenvolvimento da próxima geração de API gateways na era do cloud-native. Com o poder da comunidade e inúmeros contribuidores de código aberto, esses API gateways têm a oportunidade de formar um ciclo de iteração e evolução positivo:

• Capaz de coletar as necessidades e pontos de dor dos desenvolvedores e usuários muito mais rapidamente
• Tentar resolver esses problemas em projetos de código aberto
• Projetos de código aberto ficam mais fáceis de usar, atraindo mais desenvolvedores

Nesse processo, o API gateway de próxima geração rompe com o posicionamento de balanceamento de carga e proxy reverso dos gateways tradicionais e assume mais responsabilidades, como conexão de tráfego, agendamento, filtragem, análise, conversão de protocolo, governança e integração (veja abaixo).

API Gateway suporta desenvolvimento secundário de menor custo

Ao mesmo tempo, permitir que os desenvolvedores realizem desenvolvimento personalizado a um custo menor também se tornou o destaque do API gateway de próxima geração. A integração é uma das funções essenciais do API Gateway. Para o downstream, é a resolução e conversão de protocolos, incluindo GraphQL, gRPC, Dubbo, etc.; para o upstream, integra Okta, Keycloak, Datadog e Prometheus para serviços de autenticação e observabilidade e os serviços internos de certificação, registro, auditoria e outros da empresa.

O API gateway não pode cobrir todos os componentes do processo de integração. Portanto, é inevitável que os desenvolvedores realizem desenvolvimento personalizado por meio de plugins para atender às suas próprias necessidades de negócios.

Diferentes API gateways fornecem diferentes linguagens de programação e métodos de desenvolvimento para desenvolvimento personalizado. Por exemplo, tanto o Apache APISIX quanto o Kong podem usar Lua para escrever plugins nativos, enquanto o Envoy usa C++ para escrever plugins nativos. Ao mesmo tempo, o Apache APISIX também pode usar Go, Python, Node.js, Java e Wasm para desenvolver plugins. Quase todos os desenvolvedores usam uma dessas linguagens de programação principais.

Código aberto e desenvolvimento personalizado fácil são as características mais importantes do API gateway de próxima geração. Eles fornecem mais escolhas para os desenvolvedores. Enquanto isso, os desenvolvedores podem usar com confiança o API gateway em um ambiente de multi-nuvem ou nuvem híbrida, sem se preocupar em ficar preso a provedores de serviços em nuvem.

Exemplo: API Gateway para Tráfego de Black Friday

A seguir, vamos explicar o que um API Gateway faz com um exemplo concreto.

Na Black Friday, as empresas de comércio eletrônico terão muitas promoções, e o volume de solicitações de API durante esse período é dezenas de vezes maior que o normal. Primeiro, vamos dar uma olhada em como seria a arquitetura técnica se não houvesse um API Gateway:

Como você pode ver na imagem acima, as funções de autenticação e registro são duplicadas nos serviços de Pedido e Pagamento. Um serviço de comércio eletrônico geralmente consiste em milhares de serviços diferentes. Nesse momento, muitos dos códigos e procedimentos serão repetidos.

A figura a seguir é o diagrama de arquitetura após adicionar o API gateway:

Como você pode ver acima, integramos os serviços comuns na camada do API gateway. Como resultado, os serviços de back-end só precisam se concentrar em seus próprios negócios, proporcionando mais possibilidades para dimensionamento elástico.

Quando a promoção começa, milhões de solicitações de API de clientes entram no API gateway, e o serviço de back-end precisa realizar um dimensionamento elástico rápido. Para proteger os negócios críticos de serem afetados por tráfego repentino, precisamos identificar rastreadores maliciosos no API gateway e implementar a limitação de taxa, degradação de serviço e circuito de serviço.

Também podemos desligar temporariamente alguns serviços, como avaliação de produtos, consultas de entrega, etc. No entanto, negócios principais, como informações de estoque, compra e pagamento, não podem falhar. Portanto, precisamos gerenciar o serviço de contêiner através do K8s e gerar mais cópias de serviço para manter sua operação adequada. Nesse momento, o API gateway precisa rotear a solicitação de API do cliente para o serviço de réplica recém-copiado e remover automaticamente o serviço com falha, como mostrado na figura a seguir:

Resumo

Em resumo, o API Gateway não é um novo middleware. No entanto, ele ganhou cada vez mais importância à medida que as arquiteturas técnicas evoluem e os produtos iteram em um ritmo cada vez mais rápido. O surgimento do API gateway de próxima geração cloud-native resolve os pontos de dor dos usuários empresariais em termos de gerenciamento de cluster, dinâmica, ecossistema, observabilidade e segurança.

O API Gateway pode lidar não apenas com o tráfego de API, mas também com o tráfego do Kubernetes Ingress e service mesh, reduzindo ainda mais a curva de aprendizado dos desenvolvedores e ajudando as empresas a gerenciar o tráfego de forma integrada.

Entre em contato conosco para saber mais sobre os produtos Apache APISIX, API7 Enterprise Edition e API7 Cloud.