Proxy-слои и reverse-маршрутизация
Краткое резюме
Прокси-слой — «фронтовая шина» платформы: он завершает TLS, удостоверяет клиентов, распределяет трафик, сглаживает пики и делает выпуск безопасным (канарейки, blue-green). Минимальный набор зрелости: четкая стратификация прокси-ролей, детерминированные правила маршрутизации, контроль таймаутов/ретраев, кеш + rate-limit, сквозная наблюдаемость и автоматизация.
Таксономия прокси
Forward proxy — исходящий трафик клиентов/сервисов наружу (egress), фильтры/зеркалирование, DLP.
Reverse proxy — принимает внешние запросы и маршрутизирует к бэкендам (наш основной фокус).
1. Edge/CDN/WAF (Anycast, бот-фильтры, кеш)
2. L7 Ingress / API-gateway (маршрутизация, аутентификация, политики)
3. Сервисный слой / Mesh (sidecar) для east-west, mTLS и ретраев
4. Egress-gateway для исходящих интеграций (PSP, партнеры)
Маршрутизация (L4/L7) и алгоритмы
L4 (TCP/UDP, passthrough TLS): минимальная задержка, без понимания HTTP.
L7 (HTTP/1.1, HTTP/2, HTTP/3/gRPC): правила по host/path/header/cookie, трансформация, WAF, кеш.
- Round-robin / Least-connections / EWMA — общие случаи.
- Consistent-hash (по cookie/идентификатору) — sticky-сессии и кэш-локальность.
- Header-/Geo-/Latency-based — таргетинг по регионам/провайдерам, быстрые PoP.
- Canary/Weighted — поэтапный rollout (5→25→50→100%).
- Shadow/Mirroring — копия трафика на новый сервис без влияния на ответы.
Трансформация запросов/ответов
URL rewrite/redirect: унификация путей, версионирование (`/v1/ → /svc/v1/`).
Заголовки: нормализуйте `X-Forwarded-For/Proto/Host`, добавляйте `traceparent`/`x-request-id`, фильтруйте лишнее.
CORS/CSRF: централизуйте в gateway, не плодите настройки в каждом сервисе.
Compression/Decompression: Brotli/gzip, контроль по типам.
Body-limits и защита от slowloris/oversized headers.
Аутентификация и безопасность
TLS 1.3 + OCSP stapling + HSTS на внешних фронтах.
mTLS: админки, операционные API, партнерские каналы.
OAuth2/OIDC: авторизация через gateway (token introspection/JWT-verify) → проброс к claims в upstream.
API-ключи/подписи (HMAC) для межсервисных и партнерских интеграций.
WAF/бот-фильтры: сигнатуры + поведенческие правила, greypass/капча.
CSP/X-Frame-Options/Referrer-Policy — security-заголовки на краю.
Надежность: ретраи/таймауты/CB
Таймауты: connect/read/write на L4/L7, единая политика (например, `connect 500ms`, `read 3–5s` для API).
Ретраи: только идемпотентные (`GET/HEAD`), лимит по времени/количеству, `retry-budget`.
Circuit-breaker: ограничения на одновременные запросы/ошибки, быстрый отказ и деградация.
Outlier detection: исключение «плохих» экземпляров из пула.
Backoff + jitter: чтобы не создать «стадный эффект».
Кеш и управление трафиком
Кеш L7: статика/полудинамика (каталоги, конфиги), `s-maxage` + `stale-while-revalidate`.
Rate-limit/Quota: по IP/ASN/device/cookie, распределенный счетчик (Redis/Rate-service).
Sticky-сессии: cookie/consistent-hash; учитывайте failover и «переклейку».
Request collapsing (dedupe): защита origin от «шторма» идентичных GET.
Протоколы и особенности
HTTP/2: мультиплексирование, приоритеты; держите `ALPN: h2`.
HTTP/3/QUIC: устойчивость к потере/джиттеру; откройте UDP/443, следите за MTU/PMTUD.
gRPC: health-checks, streaming, deadlines; прокси должны поддерживать `grpc-status`.
WebSocket/SSE: long-lived коннекты, грамотные idle-таймауты и лимиты.
Наблюдаемость и SLO
Метрики:- L4/L7: `p50/p95/p99`, ошибки (`4xx/5xx/Grpc-codes`), `open_conns`, `CPS/RPS`, `retry_rate`.
- TLS: версия/шифры, p95 handshake, resumption.
- Маршрутизация: доли по route/cluster, outlier-ejections.
- Rate-limit/WAF: срабатывания/FP-rate.
- Логи: доступ (без PII), причины маршрутизации, заголовки трассировки.
- Трейсы: `traceparent`/B3, сэмплирование.
- p95 TTFB API ≤ 250–300 мс; ошибка L7 ≤ 0.5%.
- Успех канареек (без деградации метрик) ≥ 99% запусков.
- FP-rate WAF ≤ 0.1%.
Типовые конфиги
Nginx (reverse proxy, HTTP/2, канарейка, сжатие)
nginx map $http_x_canary $upstream_pool {
default "stable";
~^1$ "canary";
}
upstream api_stable { zone zst 64k; server 10. 0. 1. 10:8443; server 10. 0. 1. 11:8443; keepalive 256; }
upstream api_canary { zone zcn 64k; server 10. 0. 2. 10:8443; keepalive 64; }
server {
listen 443 ssl http2 reuseport;
server_name api. example. com;
ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_stapling on; ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000" always;
basic limits/protection client_max_body_size 10m;
sendfile on; brotli on; gzip on;
location / {
proxy_http_version 1. 1;
proxy_set_header Host $host;
proxy_set_header X-Request-Id $request_id;
proxy_set_header X-Forwarded-Proto https;
proxy_connect_timeout 500ms;
proxy_read_timeout 5s;
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 1; # Retrays are limited to proxy_pass https://api_$upstream_pool;
}
}HAProxy (JWT-verify + mTLS к бэкенду + rate-limit)
haproxy frontend fe_https bind:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1. 1 http-request set-header X-Request-Id %[unique-id]
http-request lua. jwt_verify # external verification script JWT stick-table type ip size 1m expire 10m store http_req_rate (10s)
http-request deny if { src_http_req_rate(10s) gt 100 }
default_backend be_api
backend be_api balance roundrobin option httpchk GET /healthz server s1 10. 0. 1. 10:8443 check ssl verify required ca-file /etc/haproxy/ca. pem server s2 10. 0. 1. 11:8443 check ssl verify required ca-file /etc/haproxy/ca. pemEnvoy (JWT + weighted routes + outlier detection)
yaml static_resources:
listeners:
- name: https address: { socket_address: { address: 0. 0. 0. 0, port_value: 443 } }
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 route_config:
virtual_hosts:
- name: api domains: ["api. example. com"]
routes:
- match: { prefix: "/" }
route:
weighted_clusters:
clusters:
- { name: api-stable, weight: 95 }
- { name: api-canary, weight: 5 }
http_filters:
- name: envoy. filters. http. jwt_authn typed_config: { "@type": type. googleapis. com/envoy. extensions. filters. http. jwt_authn. v3. JwtAuthentication }
- name: envoy. filters. http. router clusters:
- name: api-stable connect_timeout: 0. 5s type: STRICT_DNS lb_policy: ROUND_ROBIN outlier_detection: { consecutive_5xx: 3, interval: 2s, base_ejection_time: 30s }
transport_socket:
name: envoy. transport_sockets. tls
- name: api-canary connect_timeout: 0. 5s type: STRICT_DNS lb_policy: ROUND_ROBIN transport_socket:
name: envoy. transport_sockets. tlsTraefik (rule-based маршруты, концепт)
yaml http:
routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1/`)"
service: api-svc tls: { certResolver: letsencrypt }
services:
api-svc:
loadBalancer:
servers:
- url: "https://10. 0. 1. 10:8443"
- url: "https://10. 0. 1. 11:8443"Производительность прокси
Connection pooling и keepalive к бэкендам, лимит коннектов на инстанс.
Reuseport, pin CPU/IRQ, достаточные буферы сокетов.
TLS: ECDSA + короткие цепочки, resumption ≥ 70%, HTTP/2/3 включены.
Кэш в прокси для «горячих» ответов (в т.ч. 304-валидации).
Warm-up: прогрев DNS/TLS/коннектов перед пиками.
DR и отказоустойчивость
Автовывод деградных узлов (`outlier-ejection`).
Health-checks L4/L7 (HTTP body-маркер версии).
Fail-open/Fail-closed — выбирайте осознанно для платежных/критичных путей.
Shadow-режим перед переключением трафика на новый сервис.
Runbooks: «обвал кластера», «петля редиректов», «утечки коннектов», «шторм ретраев».
Чек-лист внедрения
- Стратификация: Edge → Ingress/API-GW → Mesh/Egress, роли и границы ответственности.
- Политики маршрутизации: host/path/header/weight, canary/blue-green, shadow.
- Безопасность: TLS 1.3, mTLS для чувствительных путей, JWT/OAuth2, WAF.
- Таймауты/ретраи/CB: единые значения, идемпотентность, retry-budget.
- Кеш/Rate-limit/Request-collapsing там, где уместно.
- Наблюдаемость: метрики/логи/трейсы, correlation-идентификаторы.
- SLO: p95/ошибки/ресурсы; алерты на периметровые сбои.
- IaC/GitOps: конфиги прокси в репозитории, канареечные релизы, быстрый rollback.
- Тесты: e2e-маршруты, chaos-сценарии, нагрузочное перед ивентами.
Типичные ошибки
«Магический» прокси-комбайн без разделения ролей → сложный RCA и высокий blast-радиус.
Ретраи для неидемпотентных запросов → дубликаты транзакций.
Нет нормализации заголовков/URL → cache-poisoning и неверные ключи.
Sticky-сессии без планов failover → залипание на деградном инстансе.
Отсутствие `traceparent`/`x-request-id` → невозможно кореллировать проблемы.
Жесткие 301/302 на уровне прокси → «петли» и потеря контроля версий API.
Специфика для iGaming/финтех
Платежи/PSP: выделенный egress-gateway с mTLS, строгие таймауты, идемпотентные ключи, белые списки IP/ASN.
Пики (матчи/турниры): canary/weighted, серые маршруты для ботов, агрессивный кеш GET, защита origin от «шторма».
Регуляторика/логирование: фиксируйте версии политик и причины маршрута в аудит-логах; минимизируйте PII.
Провайдеры контента: consistent-hash по провайдерскому ключу для кэш-локальности и ровного распределения.
Мини-плейбуки
1) Канареечный релиз API
1. Включить 5% веса на `api-canary`; 2) мониторинг p95/ошибок; 3) расширять долю; 4) автооткат при деградации.
2) Экстренное снятие деградного узла
1. Outlier-ejection или ручной `drain`; 2) проверка пула и хита кеша; 3) пост-инцидентный RCA.
3) Зеркалирование функции
1. Включить shadow без влияния на ответы; 2) сравнить метрики/дифф ответов; 3) принять решение о переключении.
4) Шторм ретраев
1. Снизить retry-budget/временные лимиты; 2) включить request-collapsing; 3) локальные заглушки/кэш; 4) стабилизировать origin.
Итог
Хорошо спроектированный прокси-слой — это разделение ролей, детерминированная маршрутизация, надежные политики (таймауты/ретраи/CB), безопасность (mTLS/JWT/WAF) и наблюдаемость. Закрепите конфигурации в IaC, используйте канарейки и shadow, измеряйте SLO — и ваша платформа будет масштабируемой, предсказуемой и защищенной даже в самые горячие пиковые часы.