Jeg er sikker på, at overskriften har givet en sund reaktion - "åh nej, ikke igen..." Men tillad mig at få din opmærksomhed i 5-10 minutter, og jeg vil prøve at leve op til forventningerne.
Strukturen af artiklen vil være som følger: et stereotypisk udsagn vil blive taget, og "natur" af dette stereotypes opståen vil blive udforsket. Jeg håber, det vil give et nyt perspektiv på valget af datadeling paradigmer i dine projekter.
For at der skal være klarhed om, hvad RPC er, foreslår jeg at betragte standarden . Der er ingen klarhed med REST. Og det skal der ikke være. Alt, hvad man behøver at vide om REST - det er, at det er uadskilleligt fra .
RPC-anmodninger er hurtigere og mere effektive, fordi de tillader batch-anmodninger.
Det handler om, at i RPC kan man i én anmodning kalde flere procedurer samtidig. For eksempel, oprette en bruger, tilføje et avatar til denne bruger og i samme anmodning tilmelde ham til nogle emner. Bare én anmodning, så meget nytte!
Faktisk, hvis du kun har én backend-node, vil det virke hurtigere ved batch-anmodningen. Fordi tre REST-anmodninger vil kræve tre gange så mange ressourcer fra én node for at etablere forbindelser.
Vær opmærksom på, at den første anmodning i tilfælde af REST skal returnere brugerens identifikator for at udføre de efterfølgende anmodninger. Dette har også en negativ indvirkning på det samlede resultat.
Men sådanne infrastrukturer kan kun findes i in-house løsninger og i Enterprise. I værste fald i små webprojekter. Men egentlige webløsninger, der kaldes HighLoad, bør ikke bygges på denne måde. Deres infrastruktur skal imødekomme kriterierne for høj tilgængelighed og belastning. Og billedet ændrer sig.
De grønne er aktivitetskanalerne i infrastrukturen under det samme scenarie. Bemærk, hvordan RPC opfører sig nu. Anmodningen bruger infrastrukturen kun gennem én forbindelse fra balanceringsapparatet til backend. Imens REST stadig taber i den første anmodning, men indhenter tabet ved at bruge hele infrastrukturen.
Bare introducer ikke to, men lad os sige fem eller ti anmodninger i scenariet for berigelse... og svaret på spørgsmålet “hvem vinder nu?” bliver ikke så åbenlyst.
Lad os se nærmere på problemet. Diagrammet viser, hvordan infrastrukturkanalerne anvendes, men infrastrukturen er ikke kun begrænset til kanalerne. En vigtig del af en højt belastet infrastruktur er caches. Lad os nu få et eller andet brugerartefakt. Flere gange. Lad os sige 32 gange.
Se hvordan infrastrukturen på RPC tydeligt er blevet "forbedret" for at imødekomme kravene til høj belastning. Det hele handler om, at REST udnytter hele styrken af HTTP-protokollen, i modsætning til RPC. I det vedlagte diagram realiseres denne styrke gennem anmodningsmetoden — GET.
HTTP-metoderne har, blandt andet, caching-strategier. Du kan finde information om dem i dokumentationen på . For RPC anvendes POST-anmodninger, som ikke betragtes som idempotente, hvilket betyder, at gentagne sendelser af de samme POST-anmodninger kan give forskellige resultater (for eksempel vil der efter hver indsendelse af en kommentar blive en ny kopi af den samme kommentar). ().
Derfor er RPC ikke i stand til at udnytte infrastrukturelle caches effektivt. Det fører til, at man er nødt til at "implementere" software-caches. I diagrammet vises Redis i denne rolle. Software-cachen kræver desuden et ekstra kodelag og betydelige ændringer i arkitekturen fra udviklerens side.
Lad os nu tælle, hvor mange anmodninger REST og RPC har genereret i den overvejede infrastruktur?
Anmodninger
Indbakke
til backend
til databasen
til software-cachen (Redis)
I ALT
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] i bedste fald (hvis lokal cache anvendes) 1 anmodning (én!), i værste fald 32 indgående anmodninger.
Sammenlignet med det første diagram er forskellen slående. Det bliver nu tydeligt, at REST har en fordel. Men lad os ikke stoppe her. En udviklet infrastruktur inkluderer CDN. Ofte adresserer det også problemer med at modarbejde DDoS og DoS-angreb. Lad os se:
Her bliver det helt trist for RPC. RPC er simpelthen ikke i stand til at delegere arbejdet med CDN-belastningen. Det står kun tilbage at håbe på systemer, der modarbejder angreb.
Kan vi afslutte med dette? Og igen, nej. HTTP-metoder har, som nævnt tidligere, deres egen "magiske" egenskab. Og det er ikke uden grund, at GET-metoden er den mest anvendte på internettet. Bemærk, at denne metode er i stand til at henvise til en del af indholdet og kan pålægge betingelser, som infrastrukturelle elementer kan fortolke, inden de overgiver kontrollen til din kode osv. Alt dette gør det muligt at skabe fleksible, administrerede infrastrukturer, der kan håndtere virkelig store mængder af forespørgsler. I RPC bliver denne metode... ignoreret.
Så hvorfor er myten om, at batch-forespørgsler (RPC) er hurtigere, så vedholdende? Personligt mener jeg, at de fleste projekter bare ikke når et udviklingsniveau, hvor REST kan vise sin styrke. Desuden viser det sig, at det i små projekter hellere viser sine svagheder.
Valget mellem REST eller RPC er ikke et vilkårligt valg fra en enkelt person i projektet. Dette valg skal opfylde projektets krav. Hvis projektet kan udnytte alt, hvad REST virkelig kan, og det rent faktisk er nødvendigt, så vil REST være et fremragende valg.
Men hvis det kræver, at man ansætter devops til hurtigt at skalere infrastrukturen, administratorer til at styre infrastrukturen, og en arkitekt til at designe alle lag i WEB-tjenesten... mens projektet, i øvrigt, sælger tre pakker margarine om dagen... ville jeg vælge RPC, da denne protokol er mere pragmatisk. Den kræver ikke dybdegående viden om cache-systemer og infrastruktur, men fokuserer udvikleren på enkle og forståelige opkald til de nødvendige procedurer. Virksomheden vil være tilfreds.
RPC-forespørgsler er mere pålidelige, fordi de kan udføre batch-forespørgsler inden for en enkelt transaktion.
Denne egenskab ved RPC er uden tvivl en fordel, da det er nemmere at holde databasen i en konsistent tilstand. Med REST kan det være mere kompliceret. Forespørgsler kan komme usammenhængende til forskellige backend-noder.
Denne "manglende" egenskab ved REST er den modsatte side af dens fordel beskrevet ovenfor - evnen til effektivt at udnytte alle ressourcer i infrastrukturen. Hvis infrastrukturen er dårligt designet, og især hvis projektets og databasen arkitektur er dårligt planlagt, er det virkelig en stor udfordring.
Men er batch-anmodninger så pålidelige, som de ser ud til? Lad os overveje et tilfælde: vi opretter en bruger, beriger hans profil med en beskrivelse og sender ham en SMS med en hemmelighed til at afslutte registreringen. Det vil sige tre kald i én batch-anmodning.
Lad os se på skemaet. Det viser en infrastruktur med elementer af høj tilgængelighed. Der er to uafhængige kommunikationskanaler med SMS-gateways. Men... hvad ser vi? Ved afsendelse af SMS opstår der en fejl 503 - tjenesten er midlertidigt utilgængelig. Da SMS-afsendelse er pakket i en batch-anmodning, skal hele anmodningen rulles tilbage. Handlingerne i databasen annulleres. Kunden modtager en fejl.
Næste forsøg er et lotteri. Enten rammer anmodningen igen den samme node og returnerer igen en fejl, eller også er der held, og den udføres. Men det vigtigste er, at vores infrastruktur mindst én gang har arbejdet forgæves. Belastningen var der, men der var ingen profit.
Godt, lad os forestille os, at vi gjorde en indsats (!) og overvejede en mulighed, hvor anmodningen kan udføres delvist med succes. Resten vil vi igen forsøge at udføre efter et vis tidsrum (Hvor meget? Det bestemmer frontend?). Men lotteriet forblev det samme. Anmodningen om at sende SMS har en sandsynlighed på 50/50 for at mislykkes igen.
Enig, set fra kundens side ser tjenesten ikke så pålidelig ud, som man kunne ønske sig... hvad med REST?
REST bruger igen "magien" fra HTTP, men nu med svarkoder. Når der opstår en fejl 503 på SMS-gatewayen, oversætter backend denne fejl til load balancer. Load balanceren, der modtager denne fejl, og ikke bryder forbindelsen til kunden, sender anmodningen til en anden node, som succesfuldt behandler anmodningen. Det vil sige, at kunden får det forventede resultat, mens infrastrukturen bekræfter sin høje status som "højtilgængelig". Brugeren er glad.
Og det er ikke alt. Load balanceren har ikke blot modtaget svarkode 503. Denne kode bør i svaret, i henhold til standarden, forsynes med overskriften "Retry-After". Overskriften signalerer til load balanceren, at den ikke skal mandsopdække denne node på denne rute i den angivne tid. De følgende anmodninger om at sende SMS vil blive sendt direkte til en node, der ikke har problemer med SMS-gatewayen.
Som vi ser, er pålideligheden af JSON-RPC overvurderet. Det er faktisk lettere at organisere konsistens i databasen. Men ofret bliver i så fald systemets pålidelighed som helhed.
Output is largely similar to the previous one. When the infrastructure is simple, the clarity of JSON-RPC is undoubtedly a plus. If a project requires high availability with high load, REST appears to be the more appropriate, albeit more complex solution.
The entry threshold for REST is lower.
I believe that the analysis presented above debunking established stereotypes about RPC clearly shows that the entry threshold for REST is undoubtedly higher than that for RPC. This is due to the need for a deep understanding of how HTTP works, as well as the necessity of possessing sufficient knowledge of existing infrastructural elements that can and should be applied in web projects.
So why do many think that REST will be easier? My personal opinion is that this apparent simplicity comes from the very manifestos of REST. That is, REST is not a protocol, but a concept… REST has no standard; there are some recommendations… REST is no more complex than HTTP. The perceived freedom and anarchy attract 'free artists'.
Undoubtedly, REST is no more complex than HTTP. But HTTP itself is a well-thought-out protocol that has proven its viability for decades. If there is no deep understanding of HTTP itself, then one cannot judge REST.
But concerning RPC, one can. It is enough to take its specification. So do you need a ? Или все же хитрый REST? Решать вам.
I sincerely hope that I did not waste your time.
Kilde: habr.com
