Envoy Proxy

O Envoy Proxy é um proxy de borda e de serviço open-source e de alto desempenho, projetado para aplicações cloud-native, atuando como um data plane universal para arquiteturas de microsserviços. Ele abstrai as complexidades de rede e fornece gerenciamento avançado de tráfego, observabilidade e recursos de segurança essenciais para sistemas distribuídos.

O Envoy funciona como um proxy transparente para todo o tráfego de rede entre serviços, permitindo que desenvolvedores e operadores foquem na lógica da aplicação em vez de questões de rede. Sua arquitetura foi construída para implantações modernas de microsserviços, oferecendo recursos que os proxies tradicionais frequentemente não possuem ou implementam de forma menos eficiente.

Princípios arquiteturais centrais

O design do Envoy prioriza desempenho, extensibilidade e configuração dinâmica. Ele opera como um servidor de processo único e multithread, usando I/O orientado a eventos para lidar com um alto volume de conexões e requisições simultâneas de forma eficiente.

Arquitetura de filtros L3/L4

O Envoy emprega uma arquitetura plugável de cadeia de filtros tanto na camada de rede (L3/L4) quanto na camada de aplicação (L7). Isso permite um processamento altamente customizável do tráfego de rede.
* Filtros de rede: operam sobre fluxos brutos de bytes. Exemplos incluem TCP proxy, terminação TLS e rate limiting no nível da conexão.
* Filtros HTTP: operam sobre requisições e respostas HTTP. Exemplos incluem compressão Gzip, injeção de request ID, autenticação JWT e roteamento avançado.

Essa modularidade viabiliza a aplicação sofisticada de políticas e a manipulação de tráfego em vários estágios do ciclo de vida da requisição.

Principais recursos para microsserviços

Suporte a HTTP/2 e gRPC

O Envoy oferece suporte de primeira classe a HTTP/2 e gRPC, protocolos essenciais em microsserviços modernos. Ele pode conectar clientes HTTP/1.1 a serviços HTTP/2, terminar conexões HTTP/2 e facilitar o proxy de gRPC, incluindo recursos avançados como balanceamento de carga e roteamento com reconhecimento de gRPC.

Balanceamento de carga avançado

O Envoy oferece um conjunto de algoritmos sofisticados de balanceamento de carga, além do simples round-robin:
* Least Request: roteia para o backend com o menor número de requisições ativas.
* Ring Hash: hashing consistente para melhor aproveitamento de cache e sessões sticky.
* Maglev (Power of Two Choices): escolhe dois hosts aleatórios e seleciona o que tiver menos requisições ativas, equilibrando simplicidade com uma distribuição quase ótima.
* Random: para distribuição simples e sem viés.
* Original Destination: roteia para o IP de destino pretendido sem descoberta de serviços.

Ele também suporta retentativas automáticas, circuit breaking, detecção de outliers e health checking para garantir que o tráfego seja enviado apenas para instâncias saudáveis, melhorando a resiliência.

Configuração dinâmica (API xDS)

Um pilar do design cloud-native do Envoy são seus recursos de configuração dinâmica através da API xDS (Discovery Service). Em vez de arquivos de configuração estáticos, o Envoy pode receber atualizações de diversos recursos dinamicamente:
* Listener Discovery Service (LDS): listeners (portas às quais o Envoy se vincula).
* Route Discovery Service (RDS): regras de roteamento HTTP.
* Cluster Discovery Service (CDS): clusters upstream (grupos de serviços de backend).
* Endpoint Discovery Service (EDS): endpoints (instâncias individuais) dentro dos clusters.
* Secret Discovery Service (SDS): certificados TLS e chaves privadas.
* Runtime Discovery Service (RTDS): valores de configuração de runtime dinâmicos.

Isso permite mudanças de configuração sem downtime, viabilizando entrega contínua e integração com control planes de service mesh (por exemplo, Istio, App Mesh) que gerenciam essas configurações.

Observabilidade

O Envoy foi projetado com a observabilidade como cidadã de primeira classe, fornecendo visibilidade profunda sobre o tráfego de rede:
* Estatísticas detalhadas: emite um grande número de estatísticas (mais de 100 por cluster upstream) cobrindo conexões, requisições, erros, latência e mais, que podem ser coletadas pelo Prometheus ou sistemas similares.
* Tracing distribuído: suporta sistemas populares de tracing como Jaeger, Zipkin e AWS X-Ray, propagando contextos de trace (por exemplo, B3, W3C Trace Context) e gerando spans para cada hop.
* Access logging: logs de acesso abrangentes e customizáveis, detalhando cada requisição, incluindo headers, códigos de resposta e informações de tempo.

Esses recursos são cruciais para depuração, análise de desempenho e monitoramento de microsserviços distribuídos.

Recursos de segurança

O Envoy fornece recursos robustos de segurança, frequentemente retirando essas preocupações do código da aplicação:
* Terminação e origination de TLS: cuida da criptografia/descriptografia TLS, permitindo que os serviços se comuniquem em texto puro internamente e mantendo a comunicação externa segura.
* Mutual TLS (mTLS): viabiliza comunicação segura e autenticada entre serviços dentro de uma mesh, validando certificados de cliente.
* Rate limiting: aplica limites de taxa de requisições para proteger serviços contra sobrecarga ou abuso.
* Autenticação e autorização: integra-se a serviços externos de autorização (por exemplo, OPA) através do filtro External Authorization, permitindo controle de acesso granular.

O papel do Envoy em arquiteturas de microsserviços

Sidecar proxy

O padrão de implantação mais comum do Envoy em um ambiente de microsserviços é como sidecar proxy. Nesse modelo, cada instância de serviço executa um proxy Envoy ao seu lado, tipicamente dentro do mesmo pod no Kubernetes. Todo o tráfego de rede de entrada e saída do serviço é interceptado e gerenciado de forma transparente pelo sidecar.

Essa abordagem oferece diversos benefícios:
* Abstração de rede: os desenvolvedores escrevem serviços que se comunicam com o localhost, e o sidecar Envoy cuida do roteamento, das retentativas e de outras questões de rede.
* Suporte poliglota: permite políticas e recursos de rede consistentes entre serviços escritos em diferentes linguagens e frameworks.
* Isolamento: as questões de rede ficam isoladas da lógica de negócio, simplificando o desenvolvimento e a implantação.

Data plane de service mesh

O Envoy serve como data plane de facto de muitas implementações populares de service mesh (por exemplo, Istio, Linkerd, AWS App Mesh). Em uma service mesh, um control plane gerencia e configura uma frota de proxies Envoy (o data plane). O control plane usa a API xDS para atualizar dinamicamente a configuração de todos os Envoys da mesh, aplicando políticas de tráfego, segurança e observabilidade em todo o ecossistema de microsserviços.

Edge proxy / API gateway

O Envoy também pode ser implantado na borda da rede como API gateway ou proxy reverso. Nesse papel, ele lida com o tráfego de ingresso, executa autenticação, rate limiting e terminação TLS, e roteia requisições para os serviços de backend apropriados dentro da arquitetura de microsserviços. Seus recursos avançados de roteamento L7 o tornam adequado para requisitos complexos de roteamento na borda.

Exemplo de configuração

Uma configuração básica do Envoy define listeners, cadeias de filtros e clusters. Este exemplo mostra um listener na porta 10000 que faz proxy de requisições HTTP para um cluster de serviço upstream chamado web_service.

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          codec_type: AUTO
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: web_service
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
  - name: web_service
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    # Comente a linha a seguir para testar em v6.
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: web_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: webserver.example.com # Substitua pelo hostname/IP real do seu serviço
                port_value: 80

Comparação com outros proxies

Considerações práticas

Ajuste de desempenho

O Envoy já é altamente performático por padrão, mas implantações específicas podem se beneficiar de ajustes. As áreas principais incluem:
* Configuração de threads: ajustar o número de worker threads para corresponder aos núcleos de CPU.
* Gerenciamento de buffers: otimizar os tamanhos dos buffers de leitura/escrita.
* Dimensionamento do pool de conexões: configurar o máximo de conexões e de requisições por conexão para os clusters upstream.

Consumo de recursos

Embora seja eficiente, executar um sidecar Envoy para cada instância de serviço aumenta o consumo geral de recursos (CPU, memória). Esse trade-off costuma ser aceitável diante dos benefícios operacionais proporcionados por uma service mesh. O monitoramento cuidadoso do uso de recursos é crucial em implantações grandes.

Depuração

O Envoy fornece uma interface de administração (tipicamente na porta 15000) que oferece endpoints valiosos para depuração:
* /stats: estatísticas atuais.
* /config_dump: despeja a configuração ativa atual.
* /clusters: status dos clusters upstream.
* /hot_restart: inicia um hot restart gracioso.

Esses endpoints são instrumentais para resolver problemas de configuração, monitorar a saúde do sistema e entender o fluxo de tráfego.