HAProxy vs Envoy: какой прокси выбрать для микросервисов

Когда мы работали в компании «ПлатёжСервис», у нас было целых 50 микросервисов, и на пике они обрабатывали до 15,000 RPS. Наш тогдашний стек выглядел так: мы использовали Nginx как reverse proxy, а upstream’ы прописывали, что называется, 'руками'. Честно говоря, нас не устраивало многое: никакого тебе dynamic service discovery, health checks были до смешного примитивными, да и с observability 'из коробки' тоже была беда.

На замену рассматривали двоих:

HAProxy — проверенный временем L4/L7 балансировщик. 25 лет в production у крупнейших компаний. Конфигурация простая и предсказуемая — без сюрпризов.

# /etc/haproxy/haproxy.cfg
global
    maxconn 50000
    log /dev/log local0
    stats socket /var/run/haproxy.sock mode 660 level admin
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384
    ssl-default-bind-options ssl-min-ver TLSv1.2

defaults
    mode http
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    option httplog
    option forwardfor
    option http-server-close

# Frontend: приём трафика
frontend api_gateway
    bind *:443 ssl crt /etc/ssl/certs/api.pem
    # Маршрутизация по path
    acl is_orders path_beg /api/orders
    acl is_payments path_beg /api/payments
    acl is_users path_beg /api/users
    use_backend orders_backend if is_orders
    use_backend payments_backend if is_payments
    use_backend users_backend if is_users
    default_backend fallback

# Backend с health checks
backend orders_backend
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    server orders-1 10.0.1.10:8080 check inter 5s fall 3 rise 2
    server orders-2 10.0.1.11:8080 check inter 5s fall 3 rise 2
    server orders-3 10.0.1.12:8080 check inter 5s fall 3 rise 2

# Rate limiting
frontend rate_limited
    bind *:80
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }

Envoy — прокси, созданный для микросервисов. Главное отличие: конфигурация обновляется динамически через xDS API без перезагрузки.

# envoy.yaml — базовая конфигурация
static_resources:
  listeners:
  - name: api_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 8443 }
    filter_chains:
    - transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
          common_tls_context:
            tls_certificates:
            - certificate_chain: { filename: /etc/ssl/cert.pem }
              private_key: { filename: /etc/ssl/key.pem }
      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
          route_config:
            virtual_hosts:
            - name: api
              domains: ["*"]
              routes:
              - match: { prefix: "/api/orders" }
                route: { cluster: orders_service }
              - match: { prefix: "/api/payments" }
                route:
                  cluster: payments_service
                  retry_policy:
                    retry_on: "5xx,connect-failure"
                    num_retries: 3

  clusters:
  - name: orders_service
    type: STRICT_DNS
    load_assignment:
      cluster_name: orders_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: orders.svc, port_value: 8080 }
    health_checks:
    - timeout: 2s
      interval: 10s
      http_health_check: { path: "/health" }
    circuit_breakers:
      thresholds:
      - max_connections: 1000
        max_requests: 2000
        max_retries: 3

Envoy предоставляет детальные метрики из коробки: latency per route, retry count, circuit breaker trips, upstream health.

Тестовый стенд: 8 CPU Xeon, 32 GB RAM, прогон wrk -t8 -c1000 -d60s, прокси к бэкенду (nginx, отдаёт статику 1KB).

HAProxy оказался на 25-30% быстрее и втрое экономнее по ресурсам. Но у Envoy есть то, чего у HAProxy из коробки нет:

• Distributed tracing — автоматическое добавление trace headers
• Circuit breakers — встроенные, per-cluster
• Dynamic config via xDS — без reload, без потери соединений
• WASM extensions — кастомные фильтры на любом языке

В итоге «ПлатёжСервис» взял HAProxy на edge (API gateway), а Envoy поставил как sidecar (через Istio) для общения сервисов между собой.

HAProxy — когда нужна максимальная производительность на edge, статическая конфигурация, минимальное потребление ресурсов. Envoy — когда нужна динамическая конфигурация, service mesh, distributed tracing.