gRPC: پروتکل های باینری و عملکرد

TL ؛ دکتر متخصص

gRPC = HTTP/2 + Protobuf + قراردادهای سختگیرانه + جریان. این تاخیر کم، ترافیک کارآمد و قراردادهای پایدار بین خدمات را فراهم می کند. ایده آل برای تماس های داخلی شمال-جنوب/شرق-غرب، کانال های زمان واقعی (جریان سرور/مشتری/بیدی)، و همچنین یک جبهه تلفن همراه از طریق gRPC-وب. موفقیت توسط: پیش قراردادهای کوچک، مهلت و لغو، retrays نمایی با idempointency، اتصال pooling، نماینده در لبه، mTLS، رمزگذاری کلید و مشاهده کامل ارائه شده است.

1) هنگامی که gRPC را انتخاب کنید و زمانی که نه

• API های داخلی بین سرویس های میکرو (تعادل، محدودیت ها، محاسبه، ضد تقلب).
• نمایش داده شد با فرکانس بالا با SLO ها سخت توسط p95/p99.
• جریانهای طولانی مدت (جداول/مسابقات، رویدادهای زنده، وضعیت پرداخت).
• مشتریان تلفن همراه (از طریق gRPC-Web یا BFF).

• یکپارچگی عمومی، وب سایت ها، تیم های پرداخت با idemotency سخت و ذخیره سازی CDN.
• رابط کاربری مدیریت با نمونه برداری تجمع غنی (GraphQL-BFF بیش از gRPC).

2) قراردادها و تکامل (Protobuf)

اصول طرح: ما فقط فیلدها را اضافه می کنیم، اعداد را دوباره استفاده نمی کنیم ؛ اجباری - از طریق اعتبار، نه «مورد نیاز».
نسخه بندی: بسته ها/فضای نام ('پرداخت. v1، پرداخت ها. v2 ') ؛ defrecate از طریق پنجره های مهاجرت و «deprecated = true».
معناشناسی: پیامهای «نازک» بدون آرایههای صدها کیلوبایت ؛ نمونه های بزرگ - جریان یا صفحه بندی.

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 بسیاری از RPC ها را به یک اتصال TCP متصل می کند: کانال های طولانی مدت با اتصال به شبکه (در یک مشتری، 2-4 کانال/هدف بالادست معمولا کافی است).
Keepalive: ارسال پینگ کمتر از زمان های متعادل کننده (به عنوان مثال، هر 30 ثانیه)، محدود کردن 'max _ pings _ without _ data'.
کنترل جریان/فشار پشتی: HTTP/2 تنظیمات پنجره + مرزهای صف مشتری/سرور.

4) عملکرد: آنچه واقعا تاثیر می گذارد

اندازه پیام: هدف - ≤ 64-128 کیلوبایت ؛ فعال کردن gzip/brotli برای پاسخ های بزرگ برای بارگیری بزرگ - جریان.
سریال سازی Protobuf 5-10 × فشرده تر از JSON است. از «string» برای اعداد و «map <string, string>» در صورت امکان اجتناب کنید.
CPU/تخصیص: کدک مشخصات و resolvers ؛ استفاده از بافر «صفر کپی» و قبل از تخصیص.
Threading: سرورهای gRPC به قفل حساس هستند - I/O را به async بیاورید، مهلت را در پایگاه داده های خارجی قرار دهید.
ناگل/ACK تاخیر: معمولا به طور پیش فرض ترک ؛ آزمایش را با دقت انجام دهید.

5) مهلت، لغو، عقب نشینی، idempointence

همیشه «خط تعریف» را روی مشتری تنظیم کنید (× 2 بالادست p95)، زمینه را در سرویس ها/پایگاه داده پرتاب کنید.
اگر در سرویس گیرنده لغو شود، سرور باید منابع را قطع و آزاد کند.
Retrai: فقط برای عملیات idempotent (GET آنالوگ، وضعیت، خواندن جریان). برای تغییر، از کلید 'idempotency _ key' استفاده کنید و نتیجه را ذخیره کنید.
سیاست برگشت با لرزش نمایی است. محدودیت تلاش و «بافر retray» در مشتری.
کدهای وضعیت gRPC: استفاده از «DEADLINE _ EXCEEDED»، «UNAVAILABLE» (retracted)، «FAILED _ PRECONDITION»، «ALREADY _ EXISTED»، «ABORTED» و غیره - معانی باریک موجب صرفه جویی در اعصاب می شود.

6) جریان: سرور، مشتری، بیدی

جریان سرور برای پاسخ های طولانی و تغذیه (بررسی برای نشت حافظه زمانی که مشتری کند است).
جریان مشتری - بارگیری/دسته.
دو طرفه - تعاملی (جداول زنده، رویدادهای داخلی).
اضافه کردن دنباله/افست در پیام ها برای سفارش و ادامه در سطح برنامه (gRPC به تنهایی پخش پس از اتصال مجدد را فراهم نمی کند).

7) تعادل و توپولوژی

xDS/Envoy به عنوان داده های هواپیما: 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 بین تمام هاپ (دروازه ↔ خدمات) ؛ گواهینامه TTL کوتاه، چرخش اتوماتیک (ACME/مش).
AuthZ: JWT/OIDC در لبه، تخمگذار ادعا به خدمات ؛ ABAC/RBAC در سطح دروازه/مش.
PII/PCI: فیلتر کردن فیلدها، غیرفعال کردن ورود اطلاعات حساس ؛ رمزگذاری نشانه در حمل و نقل/در حالت استراحت.
gRPC-Web: همان اصول auth، اما پوسته از طریق HTTP/1. 1 (نماینده پروکسی).

9) قابلیت مشاهده

معیارها: rps، p50/p95/p99 تاخیر در هر روش، میزان خطا توسط کد، جریان فعال، اندازه پیام، اشباع موضوع/استخر.
ردیابی: W3C/' traceparent 'در ابرداده ؛ دهانه در مشتری و سرور انتشار زمینه به پایگاه داده/کش.
سیاهههای مربوط: همبستگی با 'ردیابی _ id'، نمونه برداری، پنهان کردن دقیق.
Helschecks: خدمات جداگانه "بهداشت" ("grpc. سلامتی. V1 Health/Check ") و" Watch "برای سلامت جریان.

10) فشرده سازی، محدودیت ها و حفاظت

فعال کردن فشرده سازی پیام (در هر تماس)، محدود کردن 'max _ receive _ message _ length '/' max _ send _ message _ length'.
نرخ/سهمیه در سطح دروازه ؛ قطع کننده مدار با خطا/تاخیر.
بودجه مهلت: به مهلت های بی نهایت طولانی بین هاپ ها نچسبید - هر پیوند بودجه خود را کاهش می دهد.
حفاظت در برابر درخواست های «گران»: محدود کردن اندازه/تعداد عناصر در پیام، قطع جریان های طولانی.

11) دروازه ها و قابلیت همکاری

gRPC-Gateway/Transcoding: صادرات بخشی از روش ها به عنوان REST (برای شرکا/مدیران).
gRPC-Web: جلو به طور مستقیم به Envoy، که transcoded شده است.
GraphQL-BFF: حلال ها می توانند در gRPC راه بروند ؛ برای جهش دامنه پرداخت، REST با idempotency ترجیح داده می شود.

12) عدم توانایی در عملیات اصلاح

• مشتری «idempotency _ key» را تولید می کند.
• سرور نتیجه را با کلید TTL ذخیره می کند (به عنوان مثال، 24 ساعت).
• تکرار «Create» با همان کلید همان وضعیت «payout _ id »/را باز می گرداند.

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

13) خطاها و نقشه وضعیت

• 'INVALID _ ARGUMENT' (اعتبارسنجی)، 'NOT _ FOUND'، 'ALREADY _ EXISTS'،
• 'FAILED _ پیش شرط'، 'ABORTED'،
• 'تایید نشده '/' اجازه _ تکذیب شد'،
• 'RESOURCE _ EXPIRED' (سهمیه/محدودیت)،
• 'UNAVAILABLE' (شبکه/بالادست)، 'DEADLINE _ EXCESSED'.
• برای مشتری: فقط «UNAVAILABLE»، «DEADLINE _ EXCESSED» و موارد مشخص شده با idempotent را رد کنید.

14) تست و UAT

تست های قرارداد توسط «.proto» (فایل های طلایی).
بار: p50/p95/p99 تاخیر، توان، CPU، حافظه، GC.
جریان: تست فشار پشتی، وقفه، رزومه کاری.
شبکه ها: شبیه سازی از دست دادن/لرزش ؛ تست های زمانبندی/هجینگ.
امنیت: mutators از نشانه/serts، کلید های روتا در زمان اجرا.

• مهلت در هر تماس مشتری.

عقب نشيني ها فقط جاهايي هستن که شکست ناپذيرن

• محدودیت اندازه پیام.
• بهداشت/سازمان دیده بان و هشدار در p95/p99.
• mTLS و چرخش.
• ردیابی پایان به پایان.
• فرستاده مدار شکستن и outlier-تخلیه.
• gRPC-Web e2e برای مرورگر (در صورت نیاز).

15) ضد الگوهای

مهلت های بی پایان و بدون لغو

پیام های غول پیکر به جای جریان.
تکرارهای جهشهای ناایمن تکراری هستند.
بدون اتصال اتصال - طوفان اتصالات.
فقدان سلامت/ساعت - شکست «کور».
قرار دادن PII در مسیرها/سیاهههای مربوط.
یکپارچه یک استخر نقطه پایانی برای تمام جهان - بدون نزدیکی منطقه ای.

16) NFT/SLO (نشانه ها)

لبه → افزودنی خدمات: ≤ 10-30 ms p95 در منطقه.
تاخیر روش: p95 ≤ 150-250 ms (عملیات کسب و کار)، p99 ≤ 500 ms.

میزان خطا (5xx/' UNAVAILABLE '): ≤ 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 یک bus end-to-end برای میکروسرویس های iGaming است: پروتکل های باینری فشرده، قراردادهای سخت و جریان قدرتمند. به طوری که آن را به ارمغان می آورد مزایای واقعی، نگه داشتن قرارداد کوچک و پایدار، پیاده سازی مهلت/لغو/retrays با idempotency، بهره برداری Envoy/xDS و mTLS، اندازه گیری p95/p99 و آموزش سیستم تحت فشار پس زمینه زندگی می کنند. در رابطه با REST webhooks و GraphQL-BFF، شما یک لایه API سریع، مقرون به صرفه و امن دریافت می کنید که با محصول مقیاس می شود.