API Gateway: centralizando o acesso externo

1. Introdução ao API Gateway

Em arquiteturas de microsserviços, um dos desafios mais complexos é gerenciar a comunicação entre clientes externos e dezenas (ou centenas) de serviços internos. Cada microsserviço expõe seu próprio endpoint, com protocolos, formatos de dados e requisitos de segurança distintos. O API Gateway surge como uma camada de abstração que centraliza todo o tráfego externo, atuando como porta de entrada única para o sistema.

Um API Gateway é um servidor intermediário que recebe requisições de clientes, aplica regras de roteamento, autenticação, limitação de taxa e outras políticas, e encaminha as requisições para os serviços de backend apropriados. Diferentemente de um Load Balancer tradicional, que apenas distribui tráfego entre réplicas de um mesmo serviço, o API Gateway possui inteligência para entender o contexto da requisição, transformar protocolos, agregar respostas e aplicar políticas de segurança granulares.

Os principais problemas resolvidos pelo API Gateway incluem:
- Acoplamento cliente-servidor: clientes não precisam conhecer a topologia interna dos microsserviços
- Complexidade de múltiplos endpoints: um único ponto de entrada reduz a superfície de ataque e simplifica a documentação
- Cross-cutting concerns: autenticação, logging e rate limiting são implementados uma única vez

2. Funcionalidades Essenciais de um API Gateway

Roteamento inteligente e versionamento de APIs

O gateway roteia requisições com base em caminhos, cabeçalhos, parâmetros de consulta ou versões da API. Por exemplo:

# Configuração de roteamento no Kong Gateway
routes:
  - name: users-v1
    paths:
      - /v1/users
    methods:
      - GET
      - POST
    service:
      name: users-service-v1
      host: users.internal
      port: 8080

  - name: users-v2
    paths:
      - /v2/users
    methods:
      - GET
    service:
      name: users-service-v2
      host: users.internal
      port: 8081

Autenticação e autorização centralizadas

O gateway valida tokens JWT, chaves de API ou credenciais OAuth2 antes de encaminhar a requisição. Isso evita que cada microsserviço implemente sua própria lógica de autenticação.

# Plugin de autenticação JWT no Kong
plugins:
  - name: jwt
    service: users-v1
    config:
      key_claim_name: iss
      secret_is_base64: false
      claims_to_verify:
        - exp
        - nbf

Rate limiting e throttling

Protege serviços contra abusos e ataques de negação de serviço (DoS), limitando o número de requisições por cliente, IP ou chave de API.

# Rate limiting no Express Gateway (config.json)
"policies": ["rate-limiter"],
"pipelines": {
  "api-pipeline": {
    "policies": {
      "rate-limiter": {
        "action": {
          "max": 100,
          "windowMs": 60000,
          "message": "Limite de requisições excedido. Tente novamente em 1 minuto."
        }
      }
    }
  }
}

3. Padrões de Implementação e Topologias

Gateway monolítico vs. Gateway distribuído (federado)

  • Gateway monolítico: um único processo gerencia todo o tráfego. Simples de implantar, mas pode se tornar gargalo e ponto único de falha.
  • Gateway distribuído: múltiplas instâncias do gateway operam em paralelo, frequentemente combinadas com service discovery. Oferece maior resiliência e escalabilidade horizontal.

Integração com Service Discovery

Gateways modernos se integram a registries como Consul ou Eureka para descobrir dinamicamente os endpoints dos serviços de backend:

# Kong Gateway com Consul para service discovery
services:
  - name: orders-service
    host: orders.service.consul
    port: 80
    protocol: http
    path: /orders
    retries: 3
    connect_timeout: 60000
    write_timeout: 60000
    read_timeout: 60000

Estratégias de cache e response aggregation

O gateway pode armazenar em cache respostas de serviços para reduzir latência e carga no backend. Também pode agregar múltiplas chamadas em uma única resposta para o cliente (pattern de Backend for Frontend).

# Cache no Kong Gateway
plugins:
  - name: proxy-cache
    service: catalog-service
    config:
      response_code:
        - 200
        - 301
      request_method:
        - GET
      content_type:
        - application/json
      cache_ttl: 300
      strategy: memory

4. Tratamento de Cross-Cutting Concerns

Logging, tracing e monitoramento centralizado

Com OpenTelemetry, o gateway pode gerar spans de tracing e enviá-los para sistemas como Jaeger ou Zipkin:

# Plugin de OpenTelemetry no Kong
plugins:
  - name: opentelemetry
    config:
      endpoint: http://otel-collector:4318/v1/traces
      resource_attributes:
        service.name: api-gateway
        deployment.environment: production
      sampling_rate: 0.1

Transformação de protocolos

O gateway pode converter requisições HTTP para gRPC, ou vice-versa, permitindo que clientes REST se comuniquem com serviços gRPC:

# Transformação HTTP para gRPC no NGINX Plus
location /grpc-to-http {
    grpc_pass grpc://backend-service:50051;
    grpc_set_header Content-Type application/grpc;
    grpc_read_timeout 60s;
}

Manipulação de headers e payloads

Enriquecimento de requisições com cabeçalhos adicionais (como IDs de correlação) e sanitização de payloads:

# Manipulação de headers no Kong
plugins:
  - name: request-transformer
    config:
      add:
        headers:
          - X-Correlation-ID:uuid()
          - X-Forwarded-For:$(remote_addr)
      remove:
        headers:
          - X-Internal-Token

5. Resiliência e Tolerância a Falhas

Circuit breaker, retry e timeout

O gateway implementa padrões de resiliência para evitar que falhas em um serviço se propaguem:

# Circuit breaker no Kong
upstreams:
  - name: payments-upstream
    algorithm: least-connections
    healthchecks:
      active:
        type: http
        http_path: /health
        healthy:
          interval: 5
          successes: 3
        unhealthy:
          interval: 5
          tcp_failures: 3
          timeouts: 3
    slots: 10

Fallback responses e degradação graciosa

Quando um serviço está indisponível, o gateway pode retornar respostas de fallback pré-definidas:

# Fallback no Express Gateway
"policies": ["proxy", "fallback"],
"pipelines": {
  "api-pipeline": {
    "policies": {
      "proxy": [{
        "action": {
          "serviceEndpoint": "backend"
        }
      }],
      "fallback": [{
        "action": {
          "statusCode": 503,
          "body": {"message": "Serviço temporariamente indisponível. Tente novamente mais tarde."}
        }
      }]
    }
  }
}

6. Segurança no API Gateway

Proteção contra ataques comuns

O gateway pode inspecionar payloads para bloquear SQL injection, XSS e CSRF:

# Plugin de segurança no Kong
plugins:
  - name: request-validator
    config:
      allowed_content_types:
        - application/json
      body_schema:
        type: object
        properties:
          name:
            type: string
            pattern: "^[a-zA-Z0-9 ]+$"
          email:
            type: string
            format: email
      parameter_schema:
        type: object
        properties:
          id:
            type: integer
            minimum: 1

Gerenciamento de certificados TLS/SSL e mTLS

O gateway termina conexões TLS e pode exigir autenticação mútua (mTLS) para serviços internos:

# Configuração mTLS no Kong
services:
  - name: internal-service
    url: https://internal-service:8443
    client_certificate:
      cert: /etc/kong/certs/client.crt
      key: /etc/kong/certs/client.key
    tls_verify: true
    tls_verify_depth: 2

Políticas de CORS e validação de esquemas

Controle de acesso baseado em origem e validação de payloads com JSON Schema:

# CORS no Kong Gateway
plugins:
  - name: cors
    config:
      origins:
        - https://app.example.com
      methods:
        - GET
        - POST
        - PUT
      headers:
        - Authorization
        - Content-Type
      credentials: true
      max_age: 3600

7. Exemplos Práticos de Configuração

Roteamento dinâmico com Kong Gateway (YAML)

_format_version: "3.0"
services:
  - name: orders-api
    host: orders.internal
    port: 3000
    protocol: http
    routes:
      - name: orders-route
        paths:
          - /api/orders
        methods:
          - GET
          - POST
        strip_path: false
    plugins:
      - name: rate-limiting
        config:
          minute: 60
          policy: local

Rate limiting em NGINX Plus / OpenResty (Lua)

-- Configuração Lua no OpenResty
local ratelimit = require "resty.limit.req"
local limiter = ratelimit.new("my_limiter", 10, 5)

local key = ngx.var.binary_remote_addr
local delay, err = limiter:incoming(key, true)
if not delay then
    if err == "rejected" then
        ngx.exit(429)
    end
    ngx.log(ngx.ERR, "failed to limit req: ", err)
    return ngx.exit(500)
end

if delay >= 0.001 then
    ngx.sleep(delay)
end

Autenticação JWT com Express Gateway (JSON)

{
  "apiEndpoints": {
    "api": {
      "host": "localhost",
      "paths": "/api/*"
    }
  },
  "serviceEndpoints": {
    "backend": {
      "url": "http://backend-service:8080"
    }
  },
  "policies": ["jwt", "proxy"],
  "pipelines": {
    "secure-pipeline": {
      "apiEndpoints": ["api"],
      "policies": {
        "jwt": [{
          "action": {
            "secretOrPublicKey": "minha-chave-secreta-aqui",
            "checkCredentialExistence": false
          }
        }],
        "proxy": [{
          "action": {
            "serviceEndpoint": "backend"
          }
        }]
      }
    }
  }
}

8. Considerações Finais e Boas Práticas

Quando evitar o API Gateway

  • Aplicações simples: para sistemas com poucos serviços e baixa complexidade, um gateway adiciona latência e complexidade desnecessárias.
  • Latência crítica: cada hop no gateway adiciona milissegundos de latência. Em sistemas de alta frequência (trading, jogos), pode ser contraproducente.
  • Equipes pequenas: manter um gateway requer conhecimento especializado. Times reduzidos podem se beneficiar mais de soluções gerenciadas (AWS API Gateway, Azure API Management).

Estratégias de evolução

Comece com um gateway monolítico e evolua para um service mesh (como Istio ou Linkerd) quando a complexidade de gerenciar múltiplos gateways superar os benefícios. O service mesh move as responsabilidades do gateway para sidecars, oferecendo maior granularidade.

Relação com temas vizinhos

  • BFF (Backend for Frontend): o API Gateway pode ser especializado por tipo de cliente (mobile, web, IoT), cada um com seu próprio gateway.
  • Saga Pattern: o gateway pode orquestrar transações distribuídas, chamando serviços em sequência e compensando falhas.
  • Message Brokers: para comunicação assíncrona, o gateway pode publicar eventos em filas (Kafka, RabbitMQ) em vez de fazer chamadas síncronas.

O API Gateway é uma peça central em arquiteturas modernas de microsserviços, mas deve ser adotado com consciência de seus trade-offs. Quando bem implementado, simplifica a segurança, melhora a observabilidade e protege os serviços internos contra abusos externos.

Referências