RPC

RPC — bir dasturdagi kodga boshqa process yoki tarmoqdagi service funksiyasini xuddi lokal procedure chaqirig‘iga o‘xshash usulda ishga tushirish imkonini beradigan aloqa modeli. To‘liq nomi Remote Procedure Call.

RPC client va server orasidagi message format, serialization, transport va error handlingni framework orqali yashirishi mumkin. Shunga qaramay remote chaqiriq lokal functiondan latency, failure va retry jihatidan keskin farq qiladi.

Asosiy model

Client ma’lum methodni chaqiradi:

getUser(15)

RPC tizimi:

1. method nomi va argumentlarni serialize qiladi;
2. requestni tarmoq orqali yuboradi;
3. server methodni bajaradi;
4. natijani serialize qiladi;
5. clientga qaytaradi.

Client ko‘pincha generated yoki hand-written stub orqali ishlaydi.

Client stub

Stub lokal proxy vazifasini bajaradi.

U:

• argumentlarni qabul qiladi;
• request message yaratadi;
• transportni chaqiradi;
• response’ni parse qiladi;
• xatoni client tiliga moslashtiradi.

Developer network protocol tafsilotlarini bevosita yozmasligi mumkin.

Server stub

Server tomonda dispatcher yoki skeleton requestni qabul qiladi.

U:

• methodni aniqlaydi;
• argumentlarni deserialize qiladi;
• implementationni chaqiradi;
• return qiymatni response’ga aylantiradi;
• exceptionni statusga map qiladi.

Generated code contract bilan implementation orasidagi bog‘lovchi qatlam bo‘lishi mumkin.

Interface definition

Ko‘p RPC frameworklar alohida interface definition language ishlatadi.

IDL:

• service;
• method;
• request;
• response;
• type;
• field ID;
• streamingga oid ma’lumot

ni belgilaydi.

Code generator turli dasturlash tillari uchun mos class va interface yaratadi.

Serialization

Argument va return qiymatlar tarmoq orqali yuborilishi uchun formatga aylantiriladi.

Formatlar:

• JSON;
• XML;
• Protocol Buffers;
• MessagePack;
• Avro;
• custom binary.

Format type, size, compatibility va performancega ta’sir qiladi.

Transport

RPC quyidagi transportlardan foydalanishi mumkin:

• TCP;
• HTTP;
• HTTP/2;
• WebSocket;
• message queue;
• Unix socket;
• custom protocol.

RPC transportdan mustaqil abstraction bo‘lishi mumkin, ammo framework aniq transportga tayanadi.

Synchronous RPC

Client request yuborib response tugashini kutadi.

Bu code oqimini sodda qiladi.

Kamchiligi — remote service sekin yoki unavailable bo‘lsa client thread yoki task kutadi.

Timeout majburiy hisoblanadi.

Asynchronous RPC

Client Promise, Future, callback yoki event orqali natijani keyin oladi.

Bu threadni bloklamaslikka yordam beradi.

Ammo timeout, cancellation va error propagation baribir boshqariladi.

Async API remote operationning o‘zini tezlashtirmaydi.

Fire-and-forget

Client response kutmasdan message yuborishi mumkin.

Bu notificationga o‘xshash behavior.

Delivery, retry va server xatosi clientga bevosita ma’lum bo‘lmasligi mumkin.

Critical operation uchun acknowledgement yoki status tracking kerak.

Lokal va remote call farqi

Lokal function odatda:

• juda tez;
• process memory’sida;
• parameter reference bilan;
• deterministik exceptionga yaqin.

Remote call esa:

• network latency;
• serialization;
• partial failure;
• timeout;
• duplicate;
• version mismatch;
• service unavailable

xususiyatlariga ega.

RPC abstraction bu farqlarni butunlay yashirmasligi kerak.

Timeout

Remote service cheksiz kutilmaydi.

Client operation uchun deadline beradi.

Server ham qolgan vaqtni bilishi va uzoq ishni to‘xtatishi mumkin.

Bir necha nested RPC umumiy deadline budgetini bo‘lishadi.

Retry

Network xatosidan keyin request serverga yetgan-yetmaganini bilish qiyin bo‘lishi mumkin.

Retry non-idempotent methodni ikki marta bajarishi ehtimoli bor.

Idempotency key, request ID va method semantikasi ishlatiladi.

At-most-once va at-least-once

RPC delivery kafolatlari implementationga bog‘liq.

• At-most-once — operation bir martadan ko‘p bajarilmaydi, ammo umuman bajarilmasligi mumkin.
• At-least-once — operation albatta qayta urinish bilan yetkaziladi, ammo duplicate bo‘lishi mumkin.

Mutlaq exactly-once distributed tizimda murakkab va ko‘pincha application-level state talab qiladi.

Error handling

Remote xatolar quyidagilarga ajratiladi:

• transport error;
• timeout;
• authentication;
• permission;
• invalid argument;
• not found;
• conflict;
• server internal error.

Server ichki stack trace’ni clientga yubormaydi.

Typed error yoki status code contractda belgilanadi.

Versioning

Client va server har doim bir vaqtda yangilanmasligi mumkin.

Schema evolyutsiyasi:

• optional field;
• field IDni qayta ishlatmaslik;
• backward-compatible method;
• yangi service versioni;
• capability negotiation

orqali boshqariladi.

Breaking change staged migration talab qiladi.

Service discovery

Client service manzilini config, DNS, registry yoki load balancer orqali topadi.

Dynamic instance’lar health va routing bilan boshqariladi.

RPC framework discovery va load balancingni ichiga olishi mumkin.

Security

Transport encryption va authentication:

• TLS;
• mTLS;
• token;
• signed metadata;
• service identity

orqali bajariladi.

Authorization har method va resource uchun tekshiriladi.

Client generated stubga ega bo‘lishi permissionni avtomatik bermaydi.

Chatty interface

Juda mayda remote methodlar ko‘p ketma-ket network round-trip yaratadi. Lokal object API’ni bevosita RPCga ko‘chirish chatty interface hosil qilishi mumkin. Service methodlari business operation yoki yetarli coarse-grained data bilan tuziladi.

Context propagation

Trace ID, deadline, authentication va locale remote boundary orqali metadata’da uzatiladi. Har service yangi correlation yaratib oldingi contextni yo‘qotmasligi kerak. Sensitive credential barcha downstream service’ga avtomatik tarqatilmaydi.

Partial failure

Client timeout olganda server methodni bajargan bo‘lishi mumkin. Bu “natija noma’lum” holatidir. Client status query yoki idempotency record orqali operationning yakuniy holatini aniqlaydi.

Bog‘liq tushunchalar

Remote Procedure Call, Client stub, Server stub, IDL, Serialization, gRPC, JSON-RPC, RMI, Timeout, Idempotency, Service discovery