Remote Procedure Call (RPC) protokol i distribueret system

⚡ Smart opsummering

Remote Procedure Call (RPC) er en kommunikationsprotokol mellem processer, der lader et program udføre en procedure i et andet adresserum eller på en anden maskine, og skjuler netværksdetaljer bag et almindeligt lokalt funktionskald i distribuerede klient-server-systemer.

  • 📞 Definition: RPC lader en klient kalde en procedure på en fjernserver, som om det var et lokalt kald.
  • 🗂️ typer: Callback-, Broadcast- og Batch-mode RPC adskiller sig i, hvordan anmodninger dirigeres og sættes i kø.
  • 🏗️ Archilære: Fem dele samarbejder på hvert kald: klient, klientstub, RPC-kørselstid, serverstub og server.
  • 🔄 Sådan Fungerer Det: Samler marshal-parametre i en besked og afmarshaler resultatet, der returneres til den, der ringer.
  • ⚖️ Afvejninger: RPC forenkler distribueret kode, men tilføjer netværksoverhead og fejlpunkter i forhold til lokale kald.
  • 🤖 AI-vinkel: gRPC leverer maskinlæringsmodeller mellem mikrotjenester, og Copilot fremskynder skrivning af RPC-stubs.

Fjernprocedurekald (RPC) i distribueret system

Hvad er RPC?

Remote Procedure Call (RPC) er en kommunikation mellem processer Teknik, der bruges til klient-server-applikationer. Den fulde form for RPC er Remote Procedure Call. RPC-mekanismer bruges, når et computerprogram får en procedure eller subrutine til at udføres i et andet adresserum, kodet som et normalt procedurekald, uden at programmøren eksplicit koder detaljerne for den eksterne interaktion.

Dette procedurekald administrerer også lavniveau-transportprotokoller, såsom UDP og TCP/IP, for at overføre meddelelsesdata mellem programmer.

Typer af RPC

Tre typer RPC er:

  • Callback RPC
  • Udsend RPC
  • Batch-mode RPC

Callback RPC

Denne type RPC muliggør et peer-to-peer (P2P) paradigme mellem deltagende processer. Det hjælper en proces med at fungere som både en klient og en server.

Funktioner af Callback RPC:

  • Håndterer fjernbehandlede, interaktive applikationsproblemer.
  • Giver serveren klientens handle.
  • Tilbagekald får klientprocessen til at vente.
  • Håndterer tilbagekaldslåsninger.
  • Det fremmer et peer-to-peer-paradigme mellem deltagende processer.

Udsend RPC

En broadcast-RPC er en klientanmodning, der udsendes på netværket og behandles af alle servere, der har metoden til at behandle den pågældende anmodning.

Funktioner af Broadcast RPC:

  • Giver dig mulighed for at angive, at klientens anmodningsbesked skal udsendes.
  • Du kan erklære broadcast-porte.
  • Det hjælper med at reducere belastningen på det fysiske netværk.

Batch-mode RPC

Batch-mode RPC hjælper med at placere separate RPC-anmodninger i kø i en transmissionsbuffer på klientsiden og derefter sende dem over et netværk i én batch til serveren.

Funktioner i batch-tilstand RPC:

  • Det minimerer den overhead, der er involveret i at sende en anmodning, da det sender anmodninger over netværket i én batch til serveren.
  • Denne type RPC-protokol er kun effektiv til applikationer, der kræver lavere opkaldsrater.
  • Den har brug for en pålidelig transmissionsprotokol.

RPC Architecture

RPC-arkitektur har hovedsageligt fem komponenter i programmet:

  1. Klient
  2. Klient Stub
  3. RPC Runtime
  4. Server Stub
  5. Server

RPC Architecture

RPC Architecture

Hvordan fungerer RPC?

Følgende trin finder sted under RPC-processen:

Trin 1) Klienten, klient-stub'en og én instans af RPC-kørselstiden udføres på klientmaskinen.

Trin 2) Klienten starter en klient-stub-proces ved at overføre parametre på den sædvanlige måde. Klient-stubben gemmes i klientens eget adresseområde. Den beder også den lokale RPC Runtime om at sende anmodningen til server-stubben.

Trin 3) I denne fase tilgår brugeren RPC ved at foretage et almindeligt lokalt procedurekald. RPC Runtime administrerer transmissionen af ​​meddelelser mellem klienten og serveren på tværs af netværket. Den udfører også opgaverne med retransmission, bekræftelse, routing og kryptering.

Trin 4) Efter serverproceduren er afsluttet, vender udførelsen tilbage til server-stubben, som pakker (marshalerer) returværdierne i en besked. Server-stubben sender derefter beskeden tilbage til transportlaget.

Trin 5) I dette trin sender transportlaget resultatmeddelelsen tilbage til klientens transportlag, som returnerer meddelelsen til klientstubben.

Trin 6) I denne fase demarshalerer (udpakker) klienten returparametrene i den resulterende pakke, og udførelsen vender tilbage til den, der kalder pakken.

Karakteristika for RPC

Her er de væsentlige egenskaber ved RPC:

  • Den kaldte procedure er i en anden proces, som sandsynligvis befinder sig på en anden maskine.
  • Processerne deler ikke adresseplads.
  • Parametre sendes kun af værdier.
  • RPC udføres i miljøet af serverprocessen.
  • Den giver ikke adgang til den kaldende procedures miljø.

Funktioner af RPC

Her er de vigtige funktioner i RPC:

  • Simpel opkaldssyntaks.
  • Tilbyder kendt semantik.
  • Giver en veldefineret grænseflade.
  • Den kan kommunikere mellem processer på den samme eller forskellige maskiner.

Fordele ved RPC

Her er fordelene/fordelene ved RPC:

  • RPC hjælper klienter med at kommunikere med servere gennem den konventionelle brug af procedurekald i sprog på højt niveau.
  • RPC er modelleret efter det lokale procedurekald, men den kaldte procedure udføres højst sandsynligt i en anden proces og normalt på en anden computer.
  • RPC understøtter procesorienterede og trådorienterede modeller.
  • RPC skjuler den interne mekanisme til videregivelse af beskeder for brugeren.
  • Det forpligter mange af protokollagene til at forbedre ydeevnen.
  • RPC leverer mavemusklertraction; for eksempel forbliver netværkskommunikationens beskedvideregivende karakter skjult for brugeren.
  • RPC kan bruges i både distribuerede og lokale miljøer.
  • Den nødvendige indsats for at omskrive og genudvikle koden er minimal.

Ulemper ved RPC

Her er ulemperne/ulemperne ved at bruge RPC:

  • Remote Procedure Call sender kun parametre via værdier; pointer- (reference-) værdier er ikke tilladt.
  • Tiden for fjernopkald (og returnering) af procedurer – overhead – er betydeligt højere end for en lokal procedure.
  • Denne mekanisme er meget sårbar overfor fejl, da den involverer et kommunikationssystem, en anden maskine og en anden proces.
  • RPC-konceptet kan implementeres på forskellige måder, så der findes ingen enkelt standard.
  • Det tilbyder ikke fleksibilitet til hardwarearkitektur, da den for det meste er interaktionsbaseret.
  • Omkostningerne ved processen stiger på grund af det eksterne procedurekald.

Ofte Stillede Spørgsmål

RPC eksponerer handlinger som eksterne procedurer, mens REST eksponerer data som ressourcer, der tilgås via HTTP-verber. RPC føles som at kalde en lokal funktion, mens REST fokuserer på ressourcer og tilstand.

gRPC er Google's moderne, højtydende RPC-framework. Det bruger HTTP/2 og protokol Buffers, og understøtter tovejsstreaming, hvilket gør den populær til mikroservicekommunikation.

RPC kan være begge dele. Et synkront kald blokerer, indtil serveren returnerer et resultat, mens et asynkront kald returnerer med det samme og håndterer svaret senere. Frameworks som gRPC understøtter begge stilarter.

RPC er en form for IPC, der fungerer på tværs af separate maskiner. Mens mange IPC-metoder deler hukommelse på én vært, udveksler RPC beskeder over et netværk, så processer på forskellige computere kan samarbejde.

Almindelige RPC-implementeringer inkluderer gRPC, Apache Thrift, XML-RPC, JSON-RPC og Java RMI. De adskiller sig i dataformat og transport, men alle lader en klient kalde en procedure på en fjernserver.

RPC er ikke sikker som standard; sikkerheden afhænger af transporten. Implementeringer tilføjer TLS-kryptering, godkendelsestokens og adgangskontroller for at beskytte opkald.

Maskinlæringsplatforme bruger RPC, især gRPC, til at levere modelforudsigelser mellem mikrotjenester. En klient sender funktioner og modtager et inferensresultat, keeping AI-systemer er hurtige og løst koblede.

Ja. GitHub Copilot kan scaffolde .proto-servicedefinitioner, klientstubs og serverhandlere til gRPC. Udviklere bør stadig gennemgå genererede grænseflader, fejlhåndtering og versionsstyring, før de implementeres i produktion.

Opsummer dette indlæg med: