Compreendendo o padrão API Gateway em microsserviços: um guia simples

A transição de um aplicativo único e monolítico para uma arquitetura de microsserviços resolve muitos problemas. Ele permite que as equipes trabalhem de forma independente, implantem serviços separadamente e dimensionem partes do sistema conforme necessário. No entanto, também introduz um novo desafio: como os clientes interagem com todos estes serviços independentes?

Se você tiver dez, cinquenta ou centenas de pequenos microsserviços, um aplicativo móvel ou página da web deveria se conectar diretamente a cada um deles?

É aqui que entra o API Gateway Pattern. Neste guia, detalharemos o que é um API Gateway, por que você precisa dele e como ele simplifica seu sistema de microsserviços usando palavras simples e analogias do mundo real.

A analogia do mundo real: a recepcionista do hotel

Imagine que você está hospedando-se em um grande hotel resort de luxo. O resort possui muitos departamentos diferentes:

• Limpeza (para lençóis limpos)
• Serviço de quarto (para alimentação)
• Concierge (para reserva de passeios)
• Faturamento (para pagar a conta)

Se você quiser uma toalha limpa, não ande pelo resort tentando encontrar o prédio da limpeza. Se quiser jantar, não bata na porta da cozinha. Em vez disso, você liga para a recepcionista da recepção.

A recepcionista ouve sua solicitação, determina qual departamento pode resolvê-la e conecta você ou trata disso para você.

Neste cenário:

• Você é o Cliente (aplicativo móvel ou navegador).
• A recepcionista é o API Gateway.
• Os departamentos (Housekeeping, Room Service, Billing) são os Microserviços.

O problema: comunicação direta entre cliente e serviço

Antes de ver como o gateway funciona, vamos ver o que acontece se não usarmos um.

Suponha que seu aplicativo de comércio eletrônico tenha três microsserviços separados:

1. Atendimento ao usuário (gerencia perfis)
2. Serviço de Produto (gerencia catálogo)
3. Serviço de pedidos (gerencia a finalização da compra)

Sem um API Gateway, o aplicativo cliente precisa enviar solicitações separadas diretamente para o endereço individual de cada serviço (IP ou URL):

Essa abordagem de conexão direta cria várias dores de cabeça importantes:

• Muitos endpoints: o aplicativo cliente deve lembrar três URLs separados. Se você dividir um serviço ou alterar seu endereço, será necessário atualizar o aplicativo cliente.
• Pesadelo de segurança: cada microsserviço deve implementar separadamente autenticação (verificação de tokens de login), certificados SSL e regras de firewall.
• Sobrecarga de rede: o cliente pode precisar fazer três solicitações de rede separadas em redes móveis lentas apenas para carregar uma única página (por exemplo, buscar perfil, buscar detalhes do produto e buscar histórico de pedidos).
• Diferenças de protocolo: seu aplicativo cliente pode preferir usar protocolos web padrão, como HTTP/JSON, mas seus serviços internos podem se comunicar mais rapidamente usando protocolos especializados, como gRPC ou AMQP.

A solução: o padrão API Gateway

Um API Gateway é um servidor auxiliar que fica entre os aplicativos cliente e os microsserviços internos. Ele atua como o único ponto de entrada para todas as solicitações recebidas.

Em vez de chamar três serviços diferentes, o cliente faz uma chamada para o API Gateway. O gateway então encaminha a solicitação para o serviço interno correto, coleta os resultados e os envia de volta ao cliente.

Principais responsabilidades de um API Gateway

Um API Gateway faz muito mais do que apenas direcionar tráfego. Ele cuida de “preocupações transversais” - tarefas para as quais todo microsserviço teria que escrever código:

1. Roteamento: O gateway pega uma URL de entrada (como /api/v1/orders) e a mapeia para o endereço de serviço interno correto.
2. Autenticação e Autorização: O gateway valida tokens de segurança (como JWTs) na porta de entrada. Se a solicitação for inválida, ela será rejeitada imediatamente, evitando que seus microsserviços desperdicem ciclos de CPU em solicitações não autenticadas.
3. Limitação de taxa: evita que bots maliciosos ou clientes com bugs enviem spam para seu sistema, limitando quantas solicitações um usuário pode fazer por minuto.
4. Balanceamento de carga: o gateway pode distribuir o tráfego de entrada uniformemente entre várias instâncias de um microsserviço para evitar a sobrecarga de qualquer servidor único.
5. Tradução de protocolo: pode traduzir solicitações JSON voltadas ao usuário em mensagens gRPC internas de alto desempenho, permitindo que os serviços se comuniquem entre si em seus idiomas preferidos.

Uma implementação simples: exemplo de código

Para ver como o roteamento se torna fácil, vejamos duas maneiras comuns de configurar um API Gateway.

1. Roteamento declarativo (Spring Cloud Gateway YAML)

Em sistemas Java corporativos, muitas vezes você configura o roteamento usando um arquivo de configuração simples. O gateway encaminha automaticamente solicitações com base nestas regras:

spring:
  cloud:
    gateway:
      routes:
        - id: user_service_route
          uri: http://internal-user-service:8081
          predicates:
            - Path=/api/users/**
        - id: product_service_route
          uri: http://internal-product-service:8082
          predicates:
            - Path=/api/products/**

2. Roteamento programático (modelo de gateway Node.js)

Se você deseja construir um API Gateway leve em Javascript usando Express, terá a seguinte aparência:

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
const PORT = 3000;

// 1. Simple Security/Authentication Check at the door
const authenticate = (req, res, next) => {
    const token = req.headers['authorization'];
    if (token === 'secret-handshake-token') {
        next(); // Token is valid, proceed
    } else {
        res.status(401).json({ error: 'Unauthorized Access!' });
    }
};

// Apply auth check to all incoming gateway requests
app.use(authenticate);

// 2. Route requests to correct internal microservices
app.use('/api/users', createProxyMiddleware({ target: 'http://localhost:8081', changeOrigin: true }));
app.use('/api/products', createProxyMiddleware({ target: 'http://localhost:8082', changeOrigin: true }));
app.use('/api/orders', createProxyMiddleware({ target: 'http://localhost:8083', changeOrigin: true }));

app.listen(PORT, () => {
    console.log(`API Gateway running smoothly on port ${PORT}`);
});

Prós e contras do padrão API Gateway

Como qualquer decisão arquitetônica, usar um API Gateway tem vantagens e desvantagens:

Conclusão

O API Gateway Pattern é a base da arquitetura moderna de microsserviços. Ao atuar como um ponto de entrada único e inteligente, ele protege os aplicativos clientes da complexidade das configurações de serviços internos. Ele simplifica o código do lado do cliente, centraliza a segurança e gerencia o tráfego com eficiência.

Embora introduza um salto de rede menor e precise ser configurado com alta disponibilidade na produção, os benefícios de bases de código mais limpas, seguras e gerenciáveis ​​o tornam um padrão altamente recomendado para qualquer sistema distribuído em crescimento.

Explore mais insights sobre desenvolvimento de software e engenharia de back-end no Blog Ghaznix →