Echilibrarea sarcinii

1) De ce și unde este în arhitectură

• disponibilitatea (fără un singur punct de eșec), latența (p95 în jos), scala (orizontală), securitatea (TLS/WAF), gestionarea eliberării (canar/albastru-verde).

• Edge/Global: Anycast, GSLB/GeoDNS, CDN/Edge-LB, DDoS.
• L4 (TCP/UDP): NLB, maglev, proxy fără reziliere.
• L7 (HTTP/2, gRPC, WebSocket, QUIC): traseu de rutare/anteturi/timbre, cache/compresie/retray.
• Data-tier: DB- прокси (PgBouncer/ProxySQL), Redis Cluster/Consistent Hash, partiționarea Kafka.

2) Modele de echilibrare și algoritmi

Round-Robin (RR): uniformă simplă.
Cele mai puține conexiuni (LC): Bun pentru conexiuni lungi (WS, gRPC).
Cea mai mică cerere/putere-de-două (P2C): Compararea două aleatoare este un echilibru bun viteză/calitate.
RR/LC ponderat: greutăți pentru nodurile canare/fierbinți.
Consistent Hashing (CH): stickiness sesiune fără o masă (coș, Redis).
Maglev/Flow-hash: distribuție rapidă a L3/L4 cu rezistență la clapare.
Conștient de latență: Selecție prin alunecare p50/p95.
EWMA: Ia în considerare istoricul întârzierilor.

Recomandare: în mod implicit P2C (cea mai mică solicitare) pe L7; pentru statuete/cache-uri - hash consistent; для WS/gRPC - cele mai puține conexiuni.

3) Sănătatea în amonte: controale și „evacuări”

Controale de sănătate: TCP, HTTP 200/匹配 тела, starea gRPC; intervale/termene/pragul de eroare.
Outlier Ejection: excluderea automată a instanțelor „zgomotoase” (secvențial-5xx, ejecție de succes-rată).
Slow-start & warmup: intrare moale de noi instanțe (creștere treptată în greutate).
Drenare conexiune: atunci când off/reset - „topping up” de conexiuni active, fără întrerupere.

4) Sesiuni și lipiciozitate (lipiciozitate)

Cookie-stickiness (L7): 'Set-Cookie: lb = <id>; SameSite; Secure ".
CH după cheie: 'hash (userId' sessionId' ID' cartId) '.
IP-hash - numai în rețele închise (pauze NAT).
TTL stickiness + rezervă în evacuare nodală.
Important: minimiza nevoia de lipiciozitate → stoca starea în afara instanței (Redis/DB/JWT).

5) Echilibrare globală (GTM/GSLB)

Anycast + sondă de sănătate: un IP, trafic către cel mai apropiat PoP; feilover automat.
GeoDNS/Latency-DNS: Geo/Latency Response.
Clustere regionale: „datele rezidente” rămân în regiune (GDPR); eșec interregional cu replicare.
Politicieni: geo-blocuri, „stickeregion” pe cont/token.

6) Protocoale și caracteristici

HTTP/2: multiplex, priorități; nevoie de o conexiune competentă-pool pentru amonte.
gRPC: fluxuri cu durată lungă de viață → conexiuni reduse, controale agresive ale sănătății.
WebSocket/SSE: stickiness pe conexiune, timeout-uri mari inactive, TCP păstrează-în viață.
QUIC/HTTP/3: pornire rapidă, rezistență la pierdere; monitor MTU/patch-MTU.
TLS-reziliere/mTLS: termina pe edge/L7-LB; oral mTLS/identitate (SPIFFE).

7) Controlul supraîncărcării

Rate-limit: per-IP, per-cheie, per-rută; explozie + susținere.
Concurrency Adaptive (Envoy) - limita dinamică a cererilor simultane.
Coadă/supratampă: dimensiune limitată a cozii cu refuz corect 503.
Hedging/Parallel racing: duplicarea interogărilor lente (numai idempotent).
Buget Timeout: conectare separată/citire/scriere.
Backpressure: '503 + Retry-After', retragerea exponențială a clientului jitter.
Protecție lentă: timp de citire/scriere, viteză minimă.

8) Versiuni și managementul traficului

Canar (ponderat): 1-5-10-25-50-100% parapete с (p95, 5xx, timeout).
Albastru-verde: comutator instant, rollback - DNS/LB.
Umbră/oglindă: copie a cererilor fără a afecta răspunsul; PII mascare.
Header/Claim-routing: 'X-Canary: 1' или 'JWT. revendicări. regiune/rol ".

9) Autoscalare și drenaj

HPA/ASG по CPU + RPS + p95 + adâncime de coadă.
PreStop cârlig: Așteptați pentru conexiuni pentru a finaliza.
piscină caldă/reutilizare instanță: scurtarea începe la rece.
Planificarea capacității: ținta „utilizarea de 60-70%” la p95 este normală.

10) Observabilitate și SLO

Măsurători LB: RPS, p50/p95/p99, 4xx/5xx, conexiuni deschise, coadă de așteptare, ejecții, retrieri, memorie cache hit-ratio.
Urmărire: 'traceparent/x-request-id' prin intermediul serviciilor → bazelor de date → LB.
Jurnale: structurale, măști PII/PAN, corelație cu amonte.
Route SLO: de exemplu, „latență p95 ≤ 300 ms',” disponibilitate ≥ 99. 9% ',' 5xx ≤ 0. 5%`.
Alerte: prin abateri (burn-rate SLO, ejection surge, 5xx/timeout growth).

11) Echilibrarea datelor și a cache-urilor

• Citire/Scriere split (ProxySQL/pgpool) + citire-replici; lipicios-txn.
• Failover: replica sincron pentru RPO = 0 (mai scump).

• Redis Cluster + hash-slot; pentru sesiuni - CH; timeouts/erori Retryable.

• Echilibrarea prin partiționare și grupuri de consumatori; a nu se confunda cu HTTP-LB.
• Stocare obiect (S3/MinIO): multi-regiune failover через GSLB/replicare.

12) K8s și cloud LBs

Service (ClusterIP/NodePort/LoadBalancer) - baza L4.
Intrare/Gateway API - rutare L7, greutăți canare, TLS.
AWS: NLB (L4, lățime mare de bandă), ALB (L7, WAF, lipicios, rutare antet).
GCP: Global LB (L7/HTTP (S) с Anycast), TCP/UDP proxy LB.
Azure: Ușă frontală (globală), Gateway de aplicare (L7), Balancer de încărcare (L4).

13) Exemple de configurare

13. 1 NGINX (L7, least_conn, lipicios, canar)

nginx upstream api_pool {
least_conn;
server api-1:8080 max_fails=3 fail_timeout=10s;
server api-2:8080 max_fails=3 fail_timeout=10s;
sticky cookie lb_id expires=30m path=/ secure httponly;
}

map $http_x_canary $dst {
default api_pool;
1    canary_pool;
}

upstream canary_pool {
least_conn;
server api-canary:8080 weight=1;
}

server {
listen 443 ssl http2;
location /api/ {
proxy_read_timeout 5s;
proxy_connect_timeout 1s;
proxy_set_header X-Request-Id $request_id;
proxy_pass http://$dst;
}
}

13. 2 HAProxy (P2C, sănătate, slowstart, stick-table)

haproxy backend api balance leastconn option httpchk GET /health default-server inter 3s fall 3 rise 2 slowstart 10s server s1 10. 0. 0. 11:8080 check server s2 10. 0. 0. 12:8080 check stick-table type ip size 100k expire 30m http-request track-sc0 src rate limit per IP http-request deny deny_status 429 if { sc_http_req_rate(0) gt 50 }

13. 3 Envoy (P2C, outlier, retries, concurență adaptivă)

yaml load_assignment: {... }
lb_policy: LEAST_REQUEST least_request_lb_config: { choice_count: 2 }
outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s typed_extension_protocol_options:
envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency:
gradient_controller_config:
sample_aggregate_percentile: PERCENTILE_50 retry_policy:
retry_on: "5xx,reset,connect-failure"
num_retries: 2 per_try_timeout: 1s

13. 4 Kubernetes (Gateway API, canar ponderat)

yaml apiVersion: gateway. networking. k8s. io/v1 kind: HTTPRoute spec:
rules:
- matches: [{ path: { type: PathPrefix, value: /api }}]
backendRefs:
- name: api-v1 weight: 90 port: 8080
- name: api-v2-canary weight: 10 port: 8080

14) Liste de verificare

Înainte de eliberarea LB/traseu

• Algoritmul selectat (P2C/LC/CH) pentru tipul de trafic.
• Controalele de sănătate și pragurile de ejecție sunt configurate.
• Pornire lentă, încălzire, conectare-scurgere activată.
• TLS/mTLS, HSTS, cifruri sigure; HTTP/2/3 dacă este necesar.
• Lipicios/CH numai dacă este necesar; TTL и rezervă.
• Rate-limit/izbucnire, timeout-uri, reîncercați-buget, concurență adaptivă.
• Jurnale/trasee: "trace-id' este aruncat; PII mascare.
• SLO/alerte de p95/5xx/alegeri/coadă-len.
• Greutăți canare + plan rollback; umbră cu schimbări mari.

Pentru rute de plată/conformitate

• Idempotency-Key.
• Failover între PSP-uri; verificări ale aceleiaşi metode.
• Codurile de eroare sunt normalizate; ETA/motive pentru fiecare client.

Pentru DB/Caches

• RW-split/replici; timeout, re-încercare de rețea.
• CH/slot-hash pentru Redis; protecție împotriva „cheilor fierbinți”.
• Monitorizarea latenței și replicarea-lag.

15) Măsurători de calitate (minim)

Latență p50/p95/p99 după rută/metodă.
Rata de eroare 4xx/5xx, timeout/overflow.
Conexiuni deschise/active, adâncime coadă, încercați din nou conta.
Ejecții și cauze mai mari.
Hit-raportul lipicios/cache hit-raport.
GSLB: distribuție regională, faylovers, disponibilitate PoP.

16) Anti-modele

Un monolit neprotejat LB.
Sesiuni lipicioase „pentru orice”, în loc să scoată statul.
Cozi infinite globale (ascunde problema, cresc p99).
Retrai fără jitter/buget este o „furtună” de cereri.
Trust 'X-Forwarded-For' cu o listă de proxy-uri de încredere.
Lipsa scurgerii în timpul epuizării → pauzele WS/gRPC.
Eșecul de a lua în considerare conexiunile de lungă durată atunci când autoscale.

17) Specificitatea iGaming

Vârfuri și turnee: micro-cache pe directoare/listări (1-5 s), la rândul său, la scară automată.
Jocuri/fluxuri live: LC pentru conexiuni lungi, prioritatea celui mai apropiat PoP.
Plăți: rutare geo/valută/sumă/furnizor; timeouts stricte și idempotență.
Joc responsabil și conformitate: prioritate pentru a sări peste cererile de limite/încuietori chiar și cu degradare (eșec-deschis/închis de politică).

18) Procesul de implementare (4 sprinturi)

1. Harta traficului: protocoale, sarcini p95/p99, rute critice.
2. Configurare LB: algoritmi, sănătate/exterior, TLS, limite/timeout, observabilitate.
3. GSLB/Edge: Anycast/GeoDNS, suport PoP, politici regionale de date.
4. Strategia de lansare: canar/umbră, alerte SLO, autoscale + scurgere, analiză post-incident.

Foaie de trișat finală

Alegeți un algoritm pentru tipul de trafic (P2C/LC/CH) și durata conexiunii.
Păstrați-vă în amonte „sănătos”: controale de sănătate + outlier + lent-start + scurgere.
Gestionați sarcina maximă: limită de rată, concurență adaptivă, cozi cu eșec.
Utilizați GSLB/Anycast pentru disponibilitate globală și conformitate pe regiuni.
Observabilitatea și SLO sunt obligatorii; lansări - prin canar/umbră cu plan rollback.
Acolo unde este posibil, eliminați sesiunea din instanțe și stickiness din LB.