Jeg er sikker på at overskriften forårsaket en sunn reaksjon - "vel, det har begynt igjen..." Men la meg fange oppmerksomheten din i 5-10 minutter, og jeg vil prøve å ikke skuffe forventningene dine.
Strukturen til artikkelen vil være som følger: en stereotyp uttalelse tas og "naturen" til fremveksten av denne stereotypen avsløres. Jeg håper dette vil tillate deg å se på valg av datautvekslingsparadigme i prosjektene dine fra en ny vinkel.
For å være tydelig på hva RPC er, foreslår jeg å vurdere standarden . Med REST er det ingen klarhet. Og det burde det ikke være. Alt du trenger å vite om REST - det er umulig å skille fra .
RPC-forespørsler er raskere og mer effektive fordi de lar deg lage batch-forespørsler.
Poenget er at i RPC kan du ringe flere prosedyrer samtidig i en forespørsel. For eksempel, opprett en bruker, legg til en avatar til ham og abonner ham på noen emner i samme forespørsel. Bare én forespørsel, og hvor mye nytte!
Faktisk, hvis du bare har én backend-node, vil det virke raskere med en batchforespørsel. Fordi tre REST-forespørsler vil kreve tre ganger mer ressurser fra én node for å etablere forbindelser.
Merk at den første forespørselen i tilfelle av REST må returnere bruker-IDen for at påfølgende forespørsler skal kunne gjøres. Noe som også påvirker det samlede resultatet negativt.
Men slike infrastrukturer finnes bare i interne løsninger og Enterprise. Som en siste utvei, i små WEB-prosjekter. Men fullverdige WEB-løsninger, og selv de som kalles HighLoad, er ikke verdt å bygge. Infrastrukturen deres må oppfylle kriteriene for høy tilgjengelighet og belastning. Og bildet er i endring.
Infrastrukturaktivitetskanaler under samme scenario er markert med grønt. Legg merke til hvordan RPC oppfører seg nå. Forespørselen bruker infrastrukturen på bare ett ben fra balanseringsenheten til bakenden. Mens REST fortsatt taper i den første forespørselen, tar det igjen tapt tid ved å bruke hele infrastrukturen.
Det er nok å skrive inn i manuset ikke to forespørsler om berikelse, men for eksempel fem eller ti ... og svaret på spørsmålet "hvem vinner nå?" blir uklart.
Jeg foreslår å se på problemet enda bredere. Diagrammet viser hvordan infrastrukturkanaler brukes, men infrastruktur er ikke begrenset til kanaler. En viktig komponent i en høybelastningsinfrastruktur er cacher. La oss nå få en slags brukerartefakt. Gjentatte ganger. La oss si 32 ganger.
Se hvordan RPC-infrastrukturen har forbedret seg betydelig for å møte kravene til høy belastning. Saken er at REST bruker full kraft til HTTP-protokollen, i motsetning til RPC. I diagrammet ovenfor realiseres denne kraften gjennom forespørselsmetoden - GET.
HTTP-metoder har blant annet caching-strategier. Du finner dem i dokumentasjonen på . For RPC brukes POST-forespørsler, som ikke anses som idempotente, det vil si at gjentatte repetisjoner av de samme POST-forespørslene kan gi forskjellige resultater (for eksempel, etter at hver kommentar er sendt, vil en annen kopi av denne kommentaren vises) ().
Følgelig er ikke RPC i stand til å effektivt bruke infrastrukturbuffere. Dette fører til behovet for å "importere" programvarecacher. Diagrammet viser Redis i denne rollen. Programvarebufferen krever på sin side at utvikleren legger til et ekstra lag med kode og merkbare endringer i arkitekturen.
La oss nå telle hvor mange forespørsler REST og RPC "fødte" i infrastrukturen under vurdering?
forespørsler
innboksen
til backend
til DBMS
til myk cache (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Sammenlignet med den første ordningen er forskjellen slående. Nå blir fordelen med REST tydelig. Men jeg foreslår at du ikke stopper der. Den utviklede infrastrukturen inkluderer en CDN. Ofte løser det også problemet med å motvirke DDoS- og DoS-angrep. Vi får:
Det er her ting blir veldig ille for RPC. RPC er rett og slett ikke i stand til å delegere arbeidsbelastningen til et CDN. Vi kan bare stole på systemer for å motvirke angrep.
Er det mulig å avslutte her? Og igjen, nei. HTTP-metoder, som nevnt ovenfor, har sin egen "magi". Og det er ikke uten grunn at GET-metoden er mye brukt på Internett. Merk at denne metoden er i stand til å få tilgang til et innhold, er i stand til å sette betingelser som infrastrukturelementer kan tolke før kontrollen overføres til koden din, og så videre. Alt dette lar deg lage fleksible, håndterbare infrastrukturer som kan håndtere virkelig store forespørsler. Men i RPC ignoreres denne metoden.
Så hvorfor er myten om at batchforespørsler (RPC) er raskere så vedvarende? Personlig ser det ut til at de fleste prosjekter rett og slett ikke når et utviklingsnivå hvor REST klarer å vise sin styrke. Dessuten, i små prosjekter, er han mer villig til å vise sine svakheter.
Valget av REST eller RPC er ikke et frivillig valg av en person i et prosjekt. Dette valget må oppfylle kravene til prosjektet. Hvis et prosjekt er i stand til å presse alt det virkelig kan ut av REST, og det virkelig trenger det, så vil REST være et utmerket valg.
Men hvis du, for å få alle fordelene med REST, trenger å ansette devops-spesialister for prosjektet for raskt å skalere infrastrukturen, administratorer for å administrere infrastrukturen, en arkitekt til å designe alle lagene i WEB-tjenesten... og prosjektet , selger samtidig tre pakker margarin om dagen... Jeg ville holdt meg til RPC, fordi... denne protokollen er mer utilitaristisk. Det vil ikke kreve dyp kunnskap om hvordan cacher og infrastruktur fungerer, men vil fokusere utvikleren på enkle og forståelige anrop til prosedyrene han trenger. Business vil være fornøyd.
RPC-forespørsler er mer pålitelige fordi de kan utføre batchforespørsler innenfor en enkelt transaksjon
Denne egenskapen til RPC er en klar fordel, fordi Det er enkelt å holde databasen konsistent. Men med REST blir det mer og mer komplisert. Forespørsler kan komme inkonsekvent til forskjellige backend-noder.
Denne "ulempen" med REST er baksiden av fordelen beskrevet ovenfor - muligheten til å effektivt bruke alle infrastrukturressurser. Hvis infrastrukturen er dårlig utformet, og enda mer hvis arkitekturen til prosjektet og databasen spesielt er dårlig utformet, så er dette virkelig en stor smerte.
Men er batchforespørsler så pålitelige som de virker? La oss se på en sak: vi oppretter en bruker, beriker profilen hans med en beskrivelse og sender ham en SMS med en hemmelighet for å fullføre registreringen. De. tre samtaler i en batch-forespørsel.
La oss se på diagrammet. Det presenterer en infrastruktur med høy tilgjengelighetselementer. Det er to uavhengige kommunikasjonskanaler med SMS-gatewayer. Men... hva ser vi? Ved sending av SMS oppstår en feil 503 - tjenesten er midlertidig utilgjengelig. Fordi SMS-sending pakkes i en batchforespørsel, da må hele forespørselen rulles tilbake. Handlinger i DBMS er kansellert. Klienten mottar en feil.
Neste forsøk er lotteriet. Enten vil forespørselen treffe den samme noden igjen og igjen returnere en feil, eller så vil du være heldig og den vil bli utført. Men det viktigste er at minst en gang har infrastrukturen vår allerede fungert forgjeves. Det ble en belastning, men ingen fortjeneste.
Ok, la oss forestille oss at vi har anstrengt oss (!) og tenkt gjennom alternativet når forespørselen delvis kan fullføres vellykket. Og vi vil prøve å fullføre resten igjen etter litt tidsintervall (Hvilken? Avgjør fronten?). Men lotteriet forble det samme. Forespørselen om å sende SMS har 50/50 sjanse for å mislykkes igjen.
Enig, fra klientsiden virker ikke tjenesten så pålitelig som vi ønsker... hva med REST?
REST bruker magien til HTTP igjen, men nå med svarkoder. Når en feil 503 oppstår på SMS-gatewayen, sender backend denne feilen til balanseringsenheten. Balanseren mottar denne feilen og sender forespørselen til en annen node uten å bryte forbindelsen med klienten, som behandler forespørselen. De. klienten får det forventede resultatet, og infrastrukturen bekrefter sin høye tittel "høyt tilgjengelig". Brukeren er fornøyd.
Og igjen er det ikke alt. Balanseren mottok ikke bare en svarkode på 503. Når du svarer, i henhold til standarden, er det lurt å gi denne koden med "Retry-After"-overskriften. Overskriften gjør det klart for balansereren at det ikke er verdt å forstyrre denne noden på denne ruten i et spesifisert tidsrom. Og de neste forespørslene om å sende SMS vil bli sendt direkte til en node som ikke har problemer med SMS-gatewayen.
Som vi kan se, er påliteligheten til JSON-RPC overvurdert. Det er faktisk lettere å organisere konsistens i databasen. Men offeret, i dette tilfellet, vil være påliteligheten til systemet som helhet.
Konklusjonen er stort sett lik den forrige. Når infrastrukturen er enkel, er åpenheten til JSON-RPC definitivt et pluss. Dersom prosjektet innebærer høy tilgjengelighet med høy belastning, ser REST ut som en mer korrekt, men mer kompleks, løsning.
Inngangsterskel til REST er lavere
Jeg tror at analysen ovenfor, som avslører de etablerte stereotypiene om RPC, klart viste at terskelen for å gå inn i REST utvilsomt er høyere enn i RPC. Dette skyldes behovet for en dyp forståelse av hvordan HTTP fungerer, samt behovet for å ha tilstrekkelig kunnskap om eksisterende infrastrukturelementer som kan og bør brukes i WEB-prosjekter.
Så hvorfor tror mange at REST vil være enklere? Min personlige mening er at denne tilsynelatende enkelheten kommer fra REST manifesterer seg. De. REST er ikke en protokoll, men et konsept... REST har ikke en standard, det er noen retningslinjer... REST er ikke mer komplisert enn HTTP. Tilsynelatende frihet og anarki tiltrekker seg "frie artister".
REST er selvfølgelig ikke mer komplisert enn HTTP. Men HTTP i seg selv er en godt designet protokoll som har bevist sin verdi over flere tiår. Hvis det ikke er noen dyp forståelse av HTTP i seg selv, kan ikke REST bedømmes.
Men om RPC - du kan. Det er nok å ta spesifikasjonen. Så trenger du ? Eller er det fortsatt vanskelig REST? Du bestemmer.
Jeg håper inderlig at jeg ikke har kastet bort tiden din.
Kilde: www.habr.com