Remote Procedure Call (RPC) Protocol i distribuert system

by: Nathaniel Brooks Nathaniel Brooks
Hours oppdatert

⚡ Smart oppsummering

Remote Procedure Call (RPC) er en kommunikasjonsprotokoll mellom prosesser som lar et program utføre en prosedyre i et annet adresserom eller på en annen maskin, og skjuler nettverksdetaljer bak et vanlig lokalt funksjonskall i distribuerte klient-server-systemer.

  • 📞 Definisjon: RPC lar en klient kalle en prosedyre på en ekstern server som om det var et lokalt kall.
  • 🗂️ typer: Tilbakekalls-, kringkastings- og batchmodus-RPC er forskjellige i hvordan forespørsler rutes og settes i kø.
  • 🏗️ Archilære: Fem deler samarbeider på hvert kall: klient, klientstub, RPC-kjøretid, serverstub og server.
  • 🔄 Slik fungerer det: Stubber marshal-parametere inn i en melding og avmarshaler resultatet som returneres til den som ringer.
  • 🇧🇷 Avveininger: RPC forenkler distribuert kode, men legger til nettverksoverhead og feilpunkter i motsetning til lokale anrop.
  • 🤖 AI-vinkel: gRPC serverer maskinlæringsmodeller mellom mikrotjenester, og Copilot fremskynder skriving av RPC-stubber.
Les mer

Ekstern prosedyrekall (RPC) i distribuert system

Hva er RPC?

Remote Procedure Call (RPC) er en kommunikasjon mellom prosesser teknikk som brukes for klient-server-applikasjoner. Den fulle formen for RPC er Remote Procedure Call. RPC-mekanismer brukes når et dataprogram får en prosedyre eller subrutine til å kjøre i et annet adresserom, kodet som et normalt prosedyrekall uten at programmereren eksplisitt koder detaljene for den eksterne interaksjonen.

Dette prosedyrekallet administrerer også lavnivåtransportprotokoller, som UDP og TCP/IP, for å frakte meldingsdata mellom programmer.

Typer RPC

Tre typer RPC er:

  • Tilbakeringing RPC
  • Kringkast RPC
  • Batch-modus RPC

Tilbakeringing RPC

Denne typen RPC muliggjør et peer-to-peer (P2P)-paradigme mellom deltakende prosesser. Det hjelper en prosess å fungere som både en klient og en server.

Funksjoner for tilbakeringings-RPC:

  • Håndterer eksternt behandlede, interaktive applikasjonsproblemer.
  • Gir serveren klientens handle.
  • Tilbakeringing får klientprosessen til å vente.
  • Håndterer vranglåser ved tilbakeringing.
  • Det legger til rette for et likemann-til-likemann-paradigme mellom deltakende prosesser.

Kringkast RPC

En kringkastet RPC er en klientforespørsel som kringkastes på nettverket og behandles av alle servere som har metoden for å behandle forespørselen.

Funksjoner til kringkastings-RPC:

  • Lar deg spesifisere at klientens forespørselsmelding må kringkastes.
  • Du kan deklarere kringkastingsporter.
  • Det bidrar til å redusere belastningen på det fysiske nettverket.

Batch-modus RPC

Batch-modus RPC hjelper med å legge separate RPC-forespørsler i kø i en overføringsbuffer på klientsiden, og deretter sende dem over et nettverk i én batch til serveren.

Funksjoner til batchmodus RPC:

  • Det minimerer administrasjonskostnadene forbundet med å sende en forespørsel, ettersom forespørsler sendes over nettverket i én batch til serveren.
  • Denne typen RPC-protokoll er bare effektiv for applikasjoner som trenger lavere samtalerater.
  • Den trenger en pålitelig overføringsprotokoll.

RPC Architecture

RPC-arkitektur har hovedsakelig fem komponenter i programmet:

  1. kunde
  2. Klientstubb
  3. RPC kjøretid
  4. Server Stubb
  5. Server

RPC Architecture

RPC Architecture

Hvordan fungerer RPC?

Følgende trinn finner sted under RPC-prosessen:

Trinn 1) Klienten, klientstubben og én forekomst av RPC-kjøretidsprogrammet kjøres på klientmaskinen.

Trinn 2) Klienten starter en klientstub-prosess ved å sende parametere på vanlig måte. Klientstubben lagres i klientens eget adresseområde. Den ber også den lokale RPC Runtime om å sende forespørselen til serverstubben.

Trinn 3) I denne fasen får brukeren tilgang til RPC ved å foreta et vanlig lokalt prosedyrekall. RPC Runtime administrerer overføringen av meldinger mellom klienten og serveren over nettverket. Den utfører også jobben med retransmisjon, bekreftelse, ruting og kryptering.

Trinn 4) Etter at serverprosedyren er fullført, går kjøringen tilbake til serverstubben, som pakker (marshalerer) returverdiene i en melding. Serverstubben sender deretter meldingen tilbake til transportlaget.

Trinn 5) I dette trinnet sender transportlaget resultatmeldingen tilbake til klientens transportlag, som returnerer meldingen til klientstubben.

Trinn 6) I denne fasen demarshaler klienten (pakker ut) returparametrene i den resulterende pakken, og kjøringen returnerer til den som kaller.

RELATERTE ARTIKLER

Kjennetegn ved RPC

Her er de viktigste egenskapene til RPC:

  • Den kalte prosedyren er i en annen prosess, som sannsynligvis befinner seg på en annen maskin.
  • Prosessene deler ikke adresseplass.
  • Parametre sendes kun av verdier.
  • RPC kjøres i miljøet til serverprosessen.
  • Den gir ikke tilgang til den kallende prosedyrens miljø.

Funksjoner av RPC

Her er de viktige funksjonene til RPC:

  • Enkel anropssyntaks.
  • Tilbyr kjent semantikk.
  • Gir et veldefinert grensesnitt.
  • Den kan kommunisere mellom prosesser på samme eller forskjellige maskiner.

Fordeler med RPC

Her er fordelene/fordelene med RPC:

  • RPC hjelper klienter med å kommunisere med servere gjennom konvensjonell bruk av prosedyrekall i høynivåspråk.
  • RPC er modellert etter det lokale prosedyrekallet, men den kalte prosedyren utføres mest sannsynlig i en annen prosess og vanligvis på en annen datamaskin.
  • RPC støtter prosessorienterte og trådorienterte modeller.
  • RPC gjør den interne meldingsoverføringsmekanismen skjult for brukeren.
  • Den forplikter mange av protokolllagene for å forbedre ytelsen.
  • RPC gir magemusklertracsjon; for eksempel forblir meldingsoverføringskarakteren til nettverkskommunikasjon skjult for brukeren.
  • RPC kan brukes i både distribuerte og lokale miljøer.
  • Innsatsen som kreves for å omskrive og utvikle koden på nytt er minimal.

Ulemper med RPC

Her er ulempene/ulempene ved å bruke RPC:

  • Remote Procedure Call sender kun parametere etter verdier; pekerverdier (referanseverdier) er ikke tillatt.
  • Tiden for fjernprosedyrekall (og retur) – overhead – er betydelig høyere enn for en lokal prosedyre.
  • Denne mekanismen er svært sårbar for feil, ettersom den involverer et kommunikasjonssystem, en annen maskin og en annen prosess.
  • RPC-konseptet kan implementeres på forskjellige måter, så det finnes ingen enkelt standard.
  • Den tilbyr ikke fleksibilitet for maskinvarearkitektur, ettersom den stort sett er interaksjonsbasert.
  • Kostnaden for prosessen øker på grunn av det eksterne prosedyrekallet.

Spørsmål og svar

RPC eksponerer handlinger som eksterne prosedyrer, mens REST eksponerer data som ressurser som nås via HTTP-verb. RPC føles som å kalle en lokal funksjon, mens REST fokuserer på ressurser og tilstand.

gRPC er Googles moderne, høytytende RPC-rammeverk. Det bruker HTTP/2 og protokoll Buffers, og støtter toveis strømming, noe som gjør den populær for mikrotjenestekommunikasjon.

RPC kan være begge deler. Et synkront kall blokkerer inntil serveren returnerer et resultat, mens et asynkront kall returnerer umiddelbart og håndterer svaret senere. Rammeverk som gRPC støtter begge stilene.

RPC er en form for IPC som fungerer på tvers av separate maskiner. Mens mange IPC-metoder deler minne på én vert, utveksler RPC meldinger over et nettverk slik at prosesser på forskjellige datamaskiner kan samarbeide.

Vanlige RPC-implementeringer inkluderer gRPC, Apache Thrift, XML-RPC, JSON-RPC og Java RMI. De varierer i dataformat og transport, men alle lar en klient kalle en prosedyre på en ekstern server.

RPC er ikke sikker som standard; sikkerheten avhenger av transporten. Implementeringer legger til TLS-kryptering, autentiseringstokener og tilgangskontroller for å beskytte anrop.

Maskinlæringsplattformer bruker RPC, spesielt gRPC, til å levere modellprediksjoner mellom mikrotjenester. En klient sender funksjoner og mottar et inferensresultat, keeping AI-systemer er raske og løst koblet.

Ja. GitHub Copilot kan sette opp .proto-tjenestedefinisjoner, klientstubber og serverhåndterere for gRPC. Utviklere bør fortsatt gjennomgå genererte grensesnitt, feilhåndtering og versjonering før de distribueres til produksjon.

Oppsummer dette innlegget med: