Реверс-прокси и маршрутизация

1) Роль реверс-прокси

Реверс-прокси — «фронтовая линия» платформы: принимает TLS, распределяет трафик между апстримами, применяет политики безопасности и производительности. Цель — минимальная латентность, предсказуемая маршрутизация и быстрая изоляция деградирующих инстансов/зон.

2) Слои и протоколы

L4: TCP/UDP proxy (SNI-based TLS passthrough, QUIC). Низкая цена, без понимания HTTP.
L7: HTTP/1.1–2–3, gRPC, WebSocket. Богатая маршрутизация (host, path, headers, cookies), трансформации и кэш.

TLS-модель: терминировать на периметре (NGINX/Envoy), внутри — mTLS/mesh. SNI позволяет виртуальные хосты на одном IP.

3) Стратегии маршрутизации (L7)

1. Host-based: по домену (`api.brand.com` → кластер `brand-api`).
2. Path-based: `/v1/payments` → `payments-svc`, `/v1/wallets` → `wallets-svc`.
3. Header-based: `X-Region: eu-central`, `X-Tenant: 42`, `User-Agent`/`Accept`.
4. Cookie-based: A/B-тесты, «липкие» сессии.
5. Weighted/Canary: процент трафика на новую версию (1–5% → 100%).
6. Geo/ASN: по стране/ASN направляем в ближайший POP/регион.
7. Consistent hashing: привязка ключа (user_id/tenant_id) к инстансу → кэш-локалитет/липкость.
8. Shadow/Mirroring: копируем трафик на «теневой» апстрим без влияния на ответ (для регресс-тестов).

4) Балансировка и отказоустойчивость

Алгоритмы: round-robin, least-request, random, ring-hash (consistent).
Health-checks: активные (HTTP/TCP) + пассивные (по кодам/таймаутам).
Outlier ejection: временно «выбивать» хост с повышенной ошибочностью/латентностью.
Retries: ограниченно, с per-try timeout и джиттером; не ретраить небезопасные методы без идемпотентности.
Connection pooling: держать warm-пулы к апстримам, ограничивать максимумы.

5) Производительность периметра

Кэширование: по ключу (method+host+path+Vary), условия `ETag/If-None-Match`, TTL и stale-while-revalidate.
Компрессия: brotli/ gzip для текстовых ответов.
HTTP/2/3: мультиплексирование, header-compression; убедиться в совместимости WAF/IDS.
Request coalescing: схлопывать параллельные запросы за один и тот же ключ кэша.

6) Безопасность на прокси

TLS: 1.2+ (лучше 1.3), OCSP stapling, HSTS.
WAF/бот-фильтры: до маршрутизации в апп.
CORS/CSP/Fetch-Metadata: согласно политикам.
Header-гигиена: `X-Forwarded-For/Proto`, `Forwarded`, `traceparent`; защита от header-injection и oversize.
Body/headers limits: ранние 413/431 для DoS-паттернов.
mTLS для партнерских интеграций и внутренних API.

7) Схемы деплоя: canary/blue-green/версии

Weighted routing на level-7 (1%, 5%, 25%, 50%, 100%).
Header-gate: включать фичу по флагу/заголовку (internal/testing).
Blue-green: переключение целиком DNS/route, быстрый rollback.
Shadow: параллельный прогон новой версии с записью метрик/логов.

8) Sticky-сессии и хеш-маршрутизация

Cookie-stickiness (`Set-Cookie: SRV=shard-a; Path=/; HttpOnly`) для stateful-нагрузок.
Ring-hash/consistent по `user_id/tenant_id` — уменьшение кросс-инвалидиций кэша.
Предостережение: избегать «вечной» липкости для write-нагрузок → hot-spot; используйте пер-тенант квоты.

9) Региональная и гео-маршрутизация

Anycast + гео-DNS для выбора ближайшего POP.
Header-override (например, `X-Region`) для тестов и отладки.
Согласовывать с законодательно требуемой локализацией данных (route по региону/юрисдикции).

10) Наблюдаемость и контроль

Метрики RED: RPS, error-rate (по классам), latency p95/p99 per-route/cluster.
Outlier/health: количество эджектов/повторных включений, slow-call-rate.
Логи: структурированные, без PII; кореляция `trace_id`/`span_id`.
Трейсинг (OTel): спаны ingress→router→upstream; exemplars на графиках p99.

11) Примеры конфигураций

11.1 NGINX: host/path/weighted + кэш

nginx map $http_x_canary $canary { default 0; "1" 1; }
upstream app_v1 { least_conn; server 10. 0. 0. 1:8080 max_fails=3 fail_timeout=10s; }
upstream app_v2 { least_conn; server 10. 0. 0. 2:8080; }

server {
listen 443 ssl http2;
server_name api. example. com;

Кэш proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=apicache:256m max_size=10g inactive=10m use_temp_path=off;

location /v1/ {
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Request-ID $request_id;
proxy_read_timeout 300ms; proxy_connect_timeout 100ms;

Weighted: 5% on v2 if canary = 1, otherwise 0%
set $backend app_v1;
if ($canary) { set $backend app_v2; }
proxy_pass http://$backend;
}

Static with cache location/assets/{
proxy_cache apicache;
proxy_cache_valid 200 10m;
add_header Cache-Control "public, max-age=600";
proxy_pass http://static_cluster;
}
}

11.2 Envoy: header-routing, canary, outlier-ejection, mirroring

yaml static_resources:
clusters:
- name: svc_v1 type: STRICT_DNS lb_policy: LEAST_REQUEST outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50
- name: svc_v2 type: STRICT_DNS lb_policy: LEAST_REQUEST
- name: mirror_svc type: STRICT_DNS

listeners:
- name: https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
route_config:
virtual_hosts:
- name: api domains: ["api. example. com"]
routes:
- match:
prefix: "/v1"
headers:
- name: "X-Region"
exact_match: "eu"
route:
cluster: svc_v1 timeout: 350ms retry_policy:
retry_on: connect-failure,reset,5xx num_retries: 1 per_try_timeout: 200ms request_mirror_policies:
- cluster: mirror_svc runtime_key: mirror. enabled
- match: { prefix: "/v1" }
route:
weighted_clusters:
clusters:
- name: svc_v1 weight: 95
- name: svc_v2 weight: 5

11.3 Traefik: rules + middleware

yaml http:
routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1`)"
service: svc middlewares: [hsts, compress]
middlewares:
hsts:
headers:
stsSeconds: 31536000 stsIncludeSubdomains: true compress:
compress: {}
services:
svc:
weighted:
services:
- name: v1 weight: 95
- name: v2 weight: 5

11.4 Kubernetes: Ingress + манифест для canary (NGINX Ingress)

yaml apiVersion: networking. k8s. io/v1 kind: Ingress metadata:
name: api annotations:
nginx. ingress. kubernetes. io/canary: "true"
nginx. ingress. kubernetes. io/canary-weight: "5"
spec:
rules:
- host: api. example. com http:
paths:
- path: /v1 pathType: Prefix backend:
service:
name: svc-v1 port: { number: 8080 }

12) Трансформации и совместимость

Нормализация заголовков/путей, перепись `Location`, управление `Cache-Control`.
gRPC ↔ HTTP/JSON через трансляторы (grpc-json-transcoder).
WebSocket/HTTP2 upgrades: убедиться, что прокси пропускает `Upgrade`/`Connection`.

13) Тестирование и хаос-сценарии

Нагрузочные: бурсты, долгие плато, «длинные» тела (slow-POST).
Инъекция задержек/потерь к апстримам → проверка retries/timeout/outlier.
Canary-метрики: p95/p99, error-rate новой версии vs старой; автоматический rollback по SLO.
Shadow: сравнение ответов (семплирование) и side-by-side-логика.

14) Антипаттерны

Глобальные ретраи без учета идемпотентности и дедлайна → дубли и шторм.
Sticky-сессии без контроля «горячих» шардов → перекос нагрузки.
Отсутствие health-checks/outlier-ejection → «гнилые» инстансы в пуле.
Безлимитные заголовки/тела → простейший DoS.
Смешение трансформаций и безопасности без версии схем → неожиданные регрессы.
Единый глобальный кеш-ключ без `Vary` → неверные ответы.

15) Специфика iGaming/финансов

Региональность: маршрутизация по юрисдикции игрока/бренда; изоляция зон выплат.
Критичные маршруты (депозиты/выводы): короткие таймауты, один повтор, идемпотентность; отдельные кластера.
PSP/KYC: выделенные upstream-пулы, строгие политики retry/timeout, circuit-breaker, гео-пины.
AB-каналы: безопасные эксперименты с выплатами/лимитами только для read-пути; write — через флаги и малые проценты.

16) Чек-лист prod-готовности

• TLS 1.2+/1.3, OCSP stapling, HSTS; корректные `X-Forwarded-`.
• Четкие правила маршрутизации: host/path/header/cookie; документация.
• Health-checks, outlier-ejection, per-try timeout, ограниченные ретраи.
• Weighted/canary + shadow; авто-rollback по SLO/алертам.
• Кэш/компрессия/ETag; лимиты body/headers; request coalescing.
• Логи/трейсы с `trace_id`; метрики RED + outlier/health; дашборды per-route/cluster.
• WAF/бот-фильтры/CORS; защита от oversize и slow-POST.
• Sticky/consistent hashing там, где нужно; контроль hot-шардов.
• Конфиги версионируются, миграции безопасны, секреты в KMS/Vault.

17) TL;DR

Терминируйте TLS на периметре и маршрутизируйте на L7 по host/path/header/cookie. Для релизов — weighted canary и shadow; для устойчивости — health-checks, outlier-ejection, ограниченные retries с per-try timeout. Используйте кэш, компрессию и consistent hashing там, где это улучшает p95. Мерьте RED-сигналы и состояние кластеров, держите WAF и лимиты размеров. Для критичных платежных путей — отдельные кластера, короткие SLA и строгое управление ретраями/идемпотентностью.