GRPC: פרוטוקולים בינאריים וביצועים

TL; DR

GRPC = HTTP/2 + Protobuf + חוזים קפדניים + הזרמה. זה נותן איחור נמוך, תנועה יעילה וחוזים יציבים בין שירותים. אידיאלי לשיחות פנימיות צפון-דרום/מזרח-מערב, ערוצי realtime (זרימת שרת/לקוח/בידי), כמו גם חזית ניידת באמצעות gRPC-Web. הצלחה מסופקת על ידי: חוזים פרוטו קטנים, מועדים וביטולים, מגשים אקספוננציאליים עם אידמפוטנטיות, איסוף קשרים, שליח בקצה, MTLS, הצפנת מפתח ותצפית מלאה.

1) מתי לבחור gRPC ומתי לא

• API פנימי בין מיקרו-רווחים (איזון, גבולות, חישוב, אנטי-הונאה).
• שאילתות בתדר גבוה עם SLOS קפדני על ידי p95/p99.
• זרמים ארוכי חיים (שולחנות/טורנירים, אירועים חיים, מצבי תשלום).
• לקוחות ניידים (באמצעות GRPC-Web או BFF).

• אינטגרציה ציבורית, פתקי אינטרנט, צוותי תשלום עם אידמפוטנטיות קשה ומטבעות CDN.
• Admin UIs עם דגימת צבירה עשירה (GraphQL-BFF מעל gRPC).

2) חוזים ואבולוציה (פרוטובוף)

עקרונות התוכנית: אנחנו רק מוסיפים שדות, לא משתמשים מחדש במספרים; חובה - באמצעות אימות, לא ”נדרש”.
Versioning: חבילות/namespace ("תשלומים. v1 ',' תשלומים. v2 '); פחת דרך 'מנותק = נכון' וחלונות נדידה.
סמנטיקה: מסרים ”דקים” ללא מערך של מאות KB; דגימות גדולות, זרם או עבודת אלילים.

proto syntax = "proto3";
package payments.v1;

service Payouts {
rpc Create (CreatePayoutRequest) returns (CreatePayoutResponse) {}
rpc GetStatus (GetStatusRequest) returns (GetStatusResponse) {}
rpc StreamStatuses (StreamStatusesRequest) returns (stream StatusEvent) {}
}

message CreatePayoutRequest {
string idempotency_key = 1;
string user_id = 2;
string currency = 3;
int64 amount_minor = 4; // cents
}

message CreatePayoutResponse { string payout_id = 1; }
message GetStatusRequest { string payout_id = 1; }
message GetStatusResponse { string state = 1; string reason = 2; }
message StreamStatusesRequest { repeated string payout_ids = 1; }
message StatusEvent { string payout_id = 1; string state = 2; int64 ts_ms = 3; }

3) תחבורה וחיבורים

HTTP/2 מולטיפלקסים רבים של RPCs לתוך חיבור TCP אחד: לשמור על ערוצים ארוכי חיים עם איגום חיבור (על לקוח, 2-4 ערוצים/יעד במעלה הזרם הוא בדרך כלל מספיק).
Keepalive: שלח pings לעתים קרובות פחות מאשר balancer timeout (לדוגמה, כל 30 שניות), הגבל את ”max _ pings _ without _ data”.
בקרת זרימה/תרמיל גב: HTTP/2 הגדרות חלון + גבולות תור לקוח/שרת.

4) ביצועים: מה באמת משפיע

מידות הודעה: המטרה - שמור 64-128 KB; אפשר gzip/brootli לתשובות גדולות עבור מטען ענק - זרם.
Protobuf serialization הוא 5-10 × יותר קומפקטי מאשר JSON; הימנע 'מיתר' עבור מספרים ו 'map <string, string> "איפה שאפשר.
CPU/הקצאה: קוד פרופיל והחלטיות; השתמש ”אפס עותק” חוצצים להקצאה מראש.
שלשות: שרתי gRPC רגישים למנעולים - הביאו את ה-I/O ל-async, שימו דד-ליין על מסדי נתונים חיצוניים.
Nagle/עיכב ACK: בדרך כלל לעזוב כברירת מחדל; ניסוי בזהירות.

5) מועדים, ביטולים, נסיגות, אידמפוטנטיות

תמיד להגדיר את 'deadline' על הלקוח (p95 upstream x2), לזרוק את ההקשר לתוך השירותים/מסד נתונים.
אם בוטל הלקוח, השרת חייב להפריע למשאבים חופשיים.
רטריי: רק לפעולות אידמפוטנטיות (GET analogs, סטטוס, קריאת זרם). עבור החלפנים, השתמשו במפתח idempotency _ key ואחסנו את התוצאה.
מדיניות הגיבוי היא אקספוננציאלית עם ג 'יטר; הגבול של ניסיונות ו ”חוצץ מגש מחדש” על הלקוח.
קוד מצב GRPC: השתמש ב ”דדליין”, ”לא זמין” (חזר), ”נכשל _ PRECONDITION”, ”כבר _ קיים”, ”בוטל” וכו '- סמנטיקה קלושה חוסכת עצבים.

6) זרמים: שרת, לקוח, בידי

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

7) איזון וטופולוגיה

XDS/שליח כמידע-מטוס: L7-balancing, שבירת מעגל, פליטה יוצאת.
חשיש עקבי (על ידי ”user _ id'/” table _ id') - שומר מפתחות חמים על אחד במעלה הזרם, מפחית מנעולי צומת.
גידור/שיקוף: זהירות; עוזר לזנבות p99 אבל מגביר את העומס.
רב-אזור: נקודות קצה מקומיות עם ניתוב גיאו; פין-נינג ”אזור הבית” על ידי מושב.

yaml load_assignment:
endpoints:
- lb_endpoints:
- endpoint: { address: { socket_address: { address: svc-a-1, port_value: 8080 } } }
- endpoint: { address: { socket_address: { address: svc-a-2, port_value: 8080 } } }
outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s circuit_breakers:
thresholds:
max_connections: 1024 max_requests: 10000

8) בטיחות

MTLS בין כל אופס (שער ↔ שירותים); תעודות TL קצרות, סיבוב אוטומטי (ACME/mesh).
AuthZ: JWT/OIDC על הקצה, הנחת תביעות לשירותים; ABAC/RBAC ברמת שער/רשת.
PII/PCI: סינון שדות, ביטול רישום נתונים רגישים; הצפנת אסימון במעבר/במנוחה.
GRPC-Web: אותם עקרונות אוטומטיים, אבל פגזים דרך HTTP/1. 1 (שליח פרוקסי).

9) יכולת תצפית

Metrics: RPS, p50/p95/p999 latency לכל שיטה, שיעור שגיאה לפי קוד, זרמים פעילים, גודל הודעה, רווית אשכול/בריכה.
איתור: W3C/tracepart' in metadata; תוחלת הלקוח והשרת מפרישים את הקשר לבסיס הנתונים/מטמון.
יומנים: מתאם על ידי "trace _ id', דגימה, תחפושת קפדנית.
הלשקס: שירות נפרד "בריאות" ("grpc. בריאות. V1. בריאות/בדיקה) ו ”Watch” לבריאות הזרם.

10) דחיסה, גבולות והגנה

הפעל דחיסת מסרים (per-call), הגבל את ”max _ explete _ message _ long ”/” max _ sension _ message _ long”.
קצב/מכסה ברמת השער; מעגל חשמלי על ידי שגיאה/לאטנטיות.
תקציב המועד האחרון: אל תיאחזו במועדים ארוכים לאין שיעור בין קופצים - כל קישור מקצץ בתקציבו.
הגנה מפני בקשות ”יקרות”: להגביל את הגודל/מספר האלמנטים בהודעה, להפריע זרמים ארוכים.

11) שערים ואינטרפרטציה

GRPC-Gateway/Transcoding: ייצוא חלק מהשיטות בתור REST (לשותפים/מנהלים).
GRPC-Web: חזית ישירות לשליח, אשר מקודד.
GraphQL-BFF: רזולוציה יכולה ללכת ב-gRPC; עבור מוטציות תשלום, מנוחה עם אידמפוטנטיות מועדפת.

12) אידמפוטנטיות בפעולות שינוי

• הלקוח יוצר 'idempotency _ key'.
• השרת שומר את התוצאה על ידי מפתח TTL (לדוגמה, 24 שעות).
• "צור" חוזר עם אותו מפתח מחזיר את אותו "payout _ id'/status.

go if exists(key) { return storedResult }
res:= doBusiness()
store(key, res)
return res

13) שגיאות ומיפוי מצב

• ”לא תקף _ ויכוח” (אימות), ”לא נמצא”, ”כבר _ קיים”,
• ”נכשל _ תנאי מוקדם”, ”בוטל”,
• ”לא מפתה ”/” רשות נדחתה”,
• 'משאב _ מותש' (מכסות/גבולות),
• ”לא זמין” (רשת/במעלה הזרם), ”דדליין _ חרג”.
• ללקוח: רק לחזור על 'לא זמין', 'דדליין _ חרג' ותיקים מסומנים עם אידמפוטנט.

14) בדיקות וכיו "ב

בדיקות חוזה על ידי 'proto' (קבצי זהב).
עומס: p50/p95/p99 latency, proft, CPU, memory, GC.
זרמים: בדיקות תרמיל גב, הפרעות, קורות חיים.
רשתות: emulation lost/jitter; פסקי זמן/מבחני גידור.
אבטחה: מוטטורים של אסימונים/סרטים, מפתחות רוטה בזמן ריצה.

[ ] דדליין על כל שיחת לקוח.

[ הנסיגות ] הן רק איפה שאיפות.

[ ] גבולות גודל הודעה.

[ ] בריאות/Watch והתראות על p95/p99.

[ ] MTLS וסבב.

[ ] איתור מקצה לקצה.

[ ] שליח שבירת מעגל פליטה.

[ ] gRPC-Web e2e לדפדפן (במקרה הצורך).

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

הודעות ענקיות במקום נחלים.
מועדים אינסופיים ואין ביטול.
מגשים מחדש של מוטציות לא בטוחות הם שכפולים.
ללא חיבור, סערה של קשרים.
היעדר כשלים בריאותיים/שעונים - ”עיוורים”.
הנחת מח "ש בשבילים/יומנים.
מאגר אחד מונוליטי לכל העולם ללא קרבה אזורית.

16) NFT/SLO (ציוני דרך)

תוסף שירות Edge = 10-30 ms p95 בתוך האזור.
Latency שיטה: p95 latency 150-250 ms (פעולות עסקיות), p99 latency 500 ms.
קצב שגיאה (5xx/” לא זמין ”): 0. 1% של RPS.
למעלה: ב-99. 95% עבור שירותים קריטיים.
זרמים: שימור חיבור 24 שעות, טיפת קצב <0. 01 %/שעה.

17) מיני ־ מפרט ותצורות מדגם

go ctx, cancel:= context.WithTimeout(ctx, 300time.Millisecond)
defer cancel()
resp, err:= cli.GetStatus(ctx, req, grpc.WaitForReady(true))

yaml methodConfig:
- name: [{service: payments.v1.Payouts, method: GetStatus}]
retryPolicy:
maxAttempts: 4 initialBackoff: 100ms maxBackoff: 1s backoffMultiplier: 2.0 retryableStatusCodes: [UNAVAILABLE, DEADLINE_EXCEEDED]

yaml paths:
/v1/payouts/{id}:
get:
x-grpc-service: payments.v1.Payouts x-grpc-method: GetStatus

המשך תקציר

GRPC (ראשי תיבות של: General to-end to-end) הוא אוטובוס מתוצרת חברת iGaming Microservices. כך שהוא מביא יתרונות אמיתיים, לשמור על חוזים קטנים ויציבים, ליישם מועדים/ביטולים/מגשים מחדש עם אידמפוטנטיות, לנצל את שליח/xDS ו-mTLS, למדוד p95/p99 וללמד את המערכת לחיות תחת תרגיל גב. בשיתוף עם ספרי רשת של REST ו-GRAPHQL-BFF, מקבלים שכבת API מהירה, חסכונית ומאובטחת המאזנת את המוצר.