עומס איזון

1) למה ואיפה זה בארכיטקטורה

• זמינות (ללא נקודת כשל אחת), latency (p95 down), scale (אופקי), security (TLS/WAF), latency (canary/blue-green).

• Edge/Global: Anycast, GSLB/GeoDNS, CDN/Edge-LB, DDOS.
• L4 (TCP/UDP): NLB, מגלב, פרוקסי ללא סיום.
• L7 (HTTP/2, gRPC, WebSocket, QUIC): ניתוב/כותרות/חותמות, מטמון/דחיסה/מגשים.
• DB-Data-tier: DB-dizatolaticulative Hash/ProxySQL, Redis Cluster/Stability Hash, Kafka.

2) איזון מודלים ואלגוריתמים

סיבוב-רובין (RR): מדים פשוטים.
חיבורים לפחות (LC): טובים לחיבורים ארוכים (WS, gRPC).
לפחות בקשה/כוח-משניים (P2C): השוואת שני אקראיים היא איזון מהירות/איכות טוב.
RR/LC משוקלל: משקולות לקנריות/צמתים חמים.
האשינג עקבי (CH): דביקות הפעלה ללא שולחן (עגלה, רדיס).
Maglev/Flow-hash: התפלגות L3/L4 מהירה עם התנגדות מתנפנפת.
מודעת ללב: בחירה על ידי הזזה p50/p95.
לוקח בחשבון את ההיסטוריה של העיכובים.

המלצה: כברירת מחדל P2C (הכי פחות בקשה) ב ־ L7; עבור חשיש סטלילי/כס - עקבי; BiterWS/gRPC - הכי פחות קשרים.

3) בריאות במעלה הזרם: בדיקות ופינויים

בדיקות בריאות: TCP, HTTP 200/匹配 status, gRPC; מרווחים/פסק זמן/סף שגיאה.
Outlier Ejection: הדרה אוטומטית של מקרים ”רועשים” (sequential-5xx, success-rate-ejection).
התחלה איטית והתחממות: כניסה רכה של מקרים חדשים (צמיחה הדרגתית במשקל).
ניקוז החיבור: כאשר כבויים/מאופסים - ”תוספות” של קשרים פעילים ללא הפרעה.

4) מפגשים ודביקות (דביקות)

דביקות-עוגיות (L7): 'סט-קוקי: lb = <id> אתר חיסול; מאובטח ".
CH על ידי מפתח: 'חשיש (' Id' ID 'Cartid).
IP-hash - רק ברשתות סגורות (NAT נשבר).
דביקות TL + נפילה בפינוי נודאל.
חשוב: למזער את הצורך בדביקות * לאחסן את המצב מחוץ למקרה (Redis/DB/JWT).

5) איזון גלובלי (GTM/GSLB)

כל גשוש בריאות +: IP אחד, תנועה אל PoP הקרוב; פילובר אוטומטי.
GeoDNS/Latency-DNS: Geo/Latency Response.
אשכולות אזוריים: ”מידע תושב” נשאר באזור (GDPR); כשל בין-זמני עם שכפול.
פוליטיקאים: Geo-blocks, ”stickeregion” על ידי חשבון/אסימון.

6) פרוטוקולים ותכונות

HTTP/2: מולטיפלקס, סדר עדיפויות; צריך חיבור-מאגר מוסמך במעלה הזרם.
GRPC: זרמים ארוכי חיים = חיבורים מעטים ביותר, בדיקות בריאות אגרסיביות.
שקע רשת/SSE: דביקות על החיבור, פסקי זמן סרק גדולים, שמירת TCP.
QUIC/HTTP/3: התחלה מהירה, התנגדות לאובדן; צג MTU/טלאי-MTU.
TLS-סיום/mTLS: לסיים על edge/L7-LB; אוראלי mTLS/זהות (SPIFFE).

7) בקרת עומס יתר

מגבלת קצב: לכל IP, לכל מפתח, לכל מסלול; פרץ + לקיים.
קונקורנסי אדפטיבי (שליח) - גבול דינמי של בקשות בו-זמנית.
תור/חוצץ: גודל תור מוגבל עם סירוב הוגן 503.
מירוץ גידור/מקביל: שכפול שאילתות איטיות (idempotent בלבד).
תקציב פסק זמן: חיבור/קריאה/כתיבה נפרדת.
תרמיל גב: ”503 + Retry-After”, jitter לקוח נסיגה מעריכית.
הגנה איטית-לוריס: לקרוא/לכתוב פסק זמן, מינימום מהירות.

8) שחרור וניהול תנועה

קנרית (משוקללת): 1-5-10-25-50-100% מעקות בטיחות (p95, 5xx, פסק זמן).
כחול-ירוק: מתג מיידי, רולבק - DNS/LB.
Shadow/Mirror: העתק של בקשות מבלי להשפיע על התגובה; מיסוך מח "ש.
כותרת/ניתוב תביעה: ”X-Canary: 1” Hase 'ut JWT. תביעות. אזור/תפקיד ".

9) ניקוז וניקוז אוטומטי

HPA/ASG CPU + RPS + p95 + עומק תור.
חכה שהקשרים יושלמו.
בריכה חמה/שימוש חוזר: התחלות קור מקצרות.
תכנון קיבולת: ניצול יעד של 60-70% ב-p95 תקין.

10) יכולת תצפית ו ־ SLO

מטריות LB: RPS, p50/p95/p99, 4xx/5xx, חיבור פתוח, תור-LEN, פליטות, מטמון להיט-יחס.
איתור: ”trackepart/x-בקשה-id” באמצעות LB # services # מסדי נתונים.
יומנים: מבני, מסכות PII/PAN, מתאם עם מעלה הזרם.
כביש SLO: לדוגמה, 'latency p95 ms 300', 'זמינות' 99. 9%, '5xx all0. 5%`.
התראות: על ידי סטיות (צריבה בקצב SLO, נחשול פליטה, צמיחה של 5xx/timeout).

11) איזון נתונים ומטמונים

• קריאת/כתיבת פיצול (ProxySQL/pgpool) + קריאה-העתקים; דביק-txn.
• כשל: העתק סינכרוני עבור RPO = 0 (יקר יותר).

• רדיס אשכול + חשיש-חריץ; לפגישות - CH; פסקי זמן/טעויות הניתנות לניסוי.

• איזון באמצעות חלוקה וקבוצות צרכנים; לא להתבלבל עם HTTP-LB.
• אחסון אובייקטים (S3/MINIO): כשל רב-תחומי בשכר.

12) K8s וענן LBs

שירות (Clough IP/NodePort/LaulBalancer) - בסיס L4.
כניסה/שער API - ניתוב L7, משקולות קנרית, TLS.
AWS: NLB (L4, רוחב פס גבוה), ALB (L7, WAF, דביק, ניתוב כותרת).
GCP: Global LB (L7/HTTP (S) Anycast), TCP/UDP proxy LB.
Azure: דלת קדמית (גלובלית), Application Gateway (L7), Load Balancer (L4).

13) דוגמאות הגדרות

13. 1 NGINX (L7, least_conn, דביק, קנרית)

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, בריאות, איטיות, שולחן מקל)

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 שליח (P2C, חריג, חזרות, קונקורנסי הסתגלותי)

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 קוברנטס (שער API, כנרית משוקללת)

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) רשימות בדיקה

לפני שחרור LB/מסלול

אלגוריתם [ ] נבחר (P2C/LC/CH) לסוג התנועה.

[ ] בדיקות בריאות וסף פליטה מוגדרים.

[ התחלה איטית ], חימום, ניקוז החיבור מופעל.

[ ] TLS/mTLS, HSTS, צפנים מאובטחים; HTTP/2/3 במידת הצורך.

[ ] דביק/CH רק אם נדרש; טי-טי-אל פלבק.

[ ] מגבלת קצב/פרץ, פסקי זמן, מחדש-תקציב, הסתגלות מקביל.

[ ] רישומים/שבילים: ”עקבות-זיהוי” נזרק; מיסוך מח "ש.

[ ] SLO/התראות על ידי p95/5xx/בחירות/תור לן.

[ ] Canary משקולות + rollback תוכנית; צל עם שינויים גדולים.

עבור נתיבי תשלום/ציות

[ ] מפתח אידמפוטנטיות.

[ ] כשל בין PSPs; בדיקות מאותה שיטה.

[ ] קודי שגיאה מנורמלים; זמן הגעה משוער/סיבות ללקוח.

עבור DB/Caches

[ ] RW-פיצול/העתקים; פסקי זמן, שידור חוזר של הרשת.

[ ] CH/חריץ-חשיש עבור רדיס; הגנה מפני ”מפתחות חמים”.

[ ] ניטור Latency ושכפול-לג.

15) מדדים איכותיים (מינימום)

latency p50/p95/p99 בדרך/שיטה.
שגיאה קצב 4xx/5xx, פסק זמן/עודף.
חיבורים פתוחים/פעילים, עומק התור, ספירה מחדש.
פליטות וגורמים חריגים יותר.
יחס להיט/מטמון דביק.
הפצה אזורית, מאהבים, זמינות פופ.

16) אנטי דפוסים

אחד מונוליטי לא מוגן.
מפגשים דביקים ”לכל דבר”, במקום להוציא את המדינה.
תורים גלובליים אינסופיים (להסתיר את הבעיה, לגדל p99).
רטריי ללא ג 'יטר/תקציב הוא ”סערה” של בקשות.
אמון 'X-העברה עבור' ללא רשימה של ייפוי כוח מהימן.
מחסור בניקוז בזמן התרוקנות * WS/gRPC נשבר.
כישלון לקחת בחשבון קשרים ארוכי חיים כאשר אוטוסקלה.

17) מפרט iGaming

פסגות וטורנירים: מיקרו-מטמון בספריות/רשימות (1-5 אס), קנה מידה אוטומטי בתורו.
משחקים/זרמים חיים: LC לקשרים ארוכים, עדיפות של PoP הקרוב.
תשלומים: ניתוב גיאו/מטבע/כמות/ספקית; פסקי זמן נוקשים ואידמפוטנטיות.
משחק וציות אחראיים: עדיפות לדלג על בקשות למגבלות/מנעולים אפילו עם הידרדרות (אל-כשל פתוח/קרוב על ידי מדיניות).

18) תהליך יישום (4 ספרינטים)

1. מפת תנועה: פרוטוקולים, p95/p99, מסלולים קריטיים.
2. הגדרות LB: אלגוריתמים, בריאות/חוץ, TLS, גבולות/פסקי זמן, יכולת תצפית.
3. GSLB/Edge: Anycast/GeoDNS, תמיכה ב-PoP, מדיניות מידע אזורית.
4. אסטרטגיית שחרור: קנרית/צל, התראות SLO, ניקוז אוטומטי, ניתוח לאחר תקרית.

גיליון רמאות סופי

בחר אלגוריתם לסוג התנועה (P2C/LC/CH) ולמשך החיבור.
שמור על ה ”בריא” שלך במעלה הזרם: בדיקות בריאות + חריגות יותר + התחלה איטית + ניקוז.
לנהל עומס שיא: קצב מוגבל, הסתגלות מקביל, תורים עם כישלון.
השתמש GSLB/Anycast עבור זמינות גלובלית ותאימות לפי אזור.
יכולת תצפית ו-SLO הם חובה; משחרר - באמצעות קנרית/צל עם תכנית rollback.
אם אפשר, הסרת הפעלה ממופעים ודביקות מלוס אנג 'לס.