JSON-RPC? Ta en smart REST

Jeg er sikker på at overskriften har fått en god reaksjon – "nå begynner det igjen..." Men la meg ta over oppmerksomheten din i 5-10 minutter, og jeg skal prøve å ikke skuffe forventningene.

Artikkelen vil ha følgende struktur: et stereotypisk påstand blir tatt opp, og "natur" av oppkomsten av dette stereotypt blir utdypet. Jeg håper dette vil gi et nytt perspektiv på valget av datadeling paradigmer i prosjektene dine.

For å ha klarhet i hva som menes med RPC, foreslår jeg at vi ser på standarden JSON-RPC 2.0. Det er ingen klarhet med REST. Og det skal ikke være det. Alt du trenger å vite om REST – det er ikke forskjellig fra HTTP.

RPC forespørslene er raskere og mer effektive, fordi de tillater batch-forespørsel.

Det handler om at i RPC kan du i én forespørsel kalle flere prosedyrer samtidig. For eksempel opprette en bruker, legge til et avatarbildet for dem, og i samme forespørsel abonnere dem på noen emner. Bare én forespørsel, men så mye nytte!

Faktisk, hvis du bare har én backend-node, vil det virke raskere med en batch-forespørsel. Fordi tre REST-forespørsel vil kreve tre ganger mer ressurser fra én node for å opprette tilkoblinger.

Legg merke til at den første forespørselen i tilfelle med REST må returnere brukerens identifikator for å utføre de påfølgende forespørslene. Dette påvirker også den samlede ytelsen negativt.

Men slike infrastrukturer finner man bare i in-house løsninger og Enterprise. I verste fall i mindre WEB prosjekter. Men komplett WEB-løsninger, som også kalles HighLoad, bør ikke bygges på den måten. Deres infrastruktur må møte kriteriene for høy tilgjengelighet og belastning. Og bildet endres.

Grønne markerer aktivt kanaler av infrastrukturen med samme scenario. Legg merke til hvordan RPC nå oppfører seg. Forespørselen bruker infrastrukturen bare gjennom én arm fra lastbalansereren til backend. Mens REST fortsatt taper i den første forespørselen, men tar igjen det tapte ved å bruke hele infrastrukturen.

Bare introduksjon av ikke to forespørsel for berikelse, men si fem eller ti… og svaret på spørsmålet "hvem vinner nå?" blir ikke åpenbart.

La meg se nærmere på problemet. Diagrammet viser hvordan infrastrukturskanaler brukes, men infrastrukturen er ikke begrenset til kanalene. En viktig del av en høyytelses infrastruktur er hurtiglagring. La oss nå lage en brukerartefakt. Flere ganger. Si 32 ganger.

Se hvordan infrastrukturen for RPC tydelig har "ekspandert" for å møte kravene til høy belastning. Grunnen er at REST utnytter hele kraften til HTTP-protokollen, i motsetning til RPC. I diagrammet er denne kraften realisert gjennom forespørselmetoden — GET.

HTTP-metoder har, blant annet, cachingstrategier. Du kan bli kjent med dem i dokumentasjonen på HTTP. RPC bruker POST-forespørsel, som ikke anses som idempotente, det vil si at gjentatte sendinger av de samme POST-forespørslene kan gi forskjellige resultater (for eksempel vil hver gang en kommentar sendes, dukke opp en ny kopi av den kommentaren) (kilde).

Følgende betyr at RPC ikke kan bruke infrastrukturelle cacher effektivt. Dette fører til at det må "bringes inn" programvare-cacher. I diagrammet er Redis representert i denne rollen. Programvare-cachen krever på sin side et ekstra lag med kode fra utvikleren og betydelige endringer i arkitekturen.

La oss nå telle hvor mange forespørslene REST og RPC genererte i den aktuelle infrastrukturen?

Forespørsel
Inngående
til backend
til databasen
til programvare-cachen (Redis)
TOTAL

REST
1/32*
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] i beste fall (hvis lokal cache brukes) 1 forespørsel (én!), i verste fall 32 inngående forespørsel.

Sammenlignet med det første diagrammet er forskjellen slående. Nå blir det åpenbart hvordan REST vinner. Men jeg foreslår at vi ikke stopper her. En avansert infrastruktur inkluderer CDN. Ofte løser den også problemet med å motvirke DDoS- og DoS-angrep. La oss se:

Her blir situasjonen for RPC helt håpløs. RPC kan rett og slett ikke delegere belastningshåndteringen til CDN. Man må bare håpe på systemer for å motvirke angrep.

Kan vi avslutte med dette? Og igjen, nei. HTTP-metodene har som nevnt sin «magisk». Og ikke uten grunn er GET-metoden den mest brukte på Internett. Legg merke til at denne metoden kan få tilgang til deler av innhold, kan sette betingelser som kan tolkes av infrastrukturen før kontrollen overleveres til koden din, osv. Alt dette gjør det mulig å lage fleksible, administrerte infrastrukturer som kan håndtere ganske store strømmer av forespørsel. Og i RPC blir denne metoden... ignorert.

Så hvorfor er myten om at batch-forespørsel (RPC) er raskere så vedvarende? Personlig tror jeg at de fleste prosjekter bare ikke når et utviklingsnivå der REST kan vise sin styrke. Videre, i små prosjekter, viser det heller sin svakhet.

Valget mellom REST eller RPC er ikke en viljesbeslutning fra en enkeltperson i prosjektet. Dette valget bør imøtekomme prosjektets krav. Hvis prosjektet er i stand til å utnytte alt REST har å tilby, og det virkelig er nødvendig, så vil REST være et utmerket valg.

Men hvis det påkreves å ansette devops for å kunne skalere infrastrukturen effektivt, administratorer for å håndtere infrastrukturen, arkitekter for å designe alle lagene av WEB-tjenesten... mens prosjektet samtidig selger tre pakker margarin om dagen... ville jeg ha stoppet ved RPC, fordi denne protokollen er mer pragmatisk. Den krever ingen dype kunnskaper om cache-arbeid og infrastruktur, og lar utvikleren fokusere på enkle og forståelige anrop til de prosedyrene han trenger. Virksomheten vil være tilfreds.

RPC-forespørsler er mer pålitelige fordi de kan utføre batch-forespørsel innenfor en enkelt transaksjon.

Denne egenskapen ved RPC er en ubestridelig fordel, da det er lett å holde databasen i en konsistent tilstand. Men med REST blir dette mer komplisert. Forespørslene kan komme usammenhengende til forskjellige backend-noder.

Denne «ulempen» ved REST er den motsatte siden av dens fordel som beskrevet ovenfor - evnen til effektivt å bruke alle ressursene i infrastrukturen. Hvis infrastrukturen er dårlig designet, og spesielt hvis prosjektet og databasen er dårlig arkitekturerte, vil dette ofte være en stor utfordring.

Men er batch-forespørslene så pålitelige som de ser ut til? La oss se på et tilfelle: vi oppretter en bruker, beriker profilen med en beskrivelse og sender ham/SMS med en hemmelighet for å fullføre registreringen. Det vil si tre kall i én batch-forespørsel.

La oss se på skjemaet. Det viser infrastrukturen med elementer for høy tilgjengelighet. Det er to uavhengige kommunikasjonslinjer med SMS gatewayer. Men… hva ser vi? Når vi sender SMS oppstår det en 503-feil — tjenesten er midlertidig utilgjengelig. Siden sendingen av SMS er pakket inn i en batch-forespørsel, må hele forespørselen rulles tilbake. Handlingene i databasen blir annullert. Klienten får en feil.

Neste forsøk er et lotteri. Enten vil forespørselen igjen havne på den samme noden og returnere feilen, eller så kan det være flaks, og den vil bli gjennomført. Men viktigst av alt, minst én gang har infrastrukturen vår allerede jobbet forgjeves. Det var belastning, men ingen gevinst.

Bra, la oss forestille oss at vi har anstrengt oss (!) og tenkt på et alternativ der forespørselen kan bli vellykket utført delvis. Og resten vil vi igjen prøve å utføre etter en viss tids periode (Hvor lenge? Det bestemmer fronten?). Men lotteriet forblir. Forespørselen om å sende SMS vil med 50/50 sannsynlighet igjen mislykkes.

Enig, fra klientens side ser ikke tjenesten så pålitelig ut som man skulle ønsket... hvordan er det med REST?

REST bruker igjen "magien" av HTTP, men nå med svarkoder. Ved feil 503 på SMS-gatewayen, oversetter bakenden denne feilen til lastbalansereren. Lastbalansereren mottar denne feilen, og uten å bryte forbindelsen til klienten sender forespørselen til en annen node som vellykket behandler forespørselen. Klienten får med andre ord det forventede resultatet, og infrastrukturen bekrefter sin høye status som "høyt tilgjengelig". Brukeren er fornøyd.

Og igjen er ikke alt. Lastbalansereren mottok ikke bare svarkode 503. Denne koden skal ifølge standarden gjerne suppleres med headeren "Retry-After". Headeren gir lastbalansereren beskjed om at det ikke er lurt å forstyrre denne noden gjennom denne ruten i løpet av den angitte tiden. Og neste forespørsel om å sende SMS vil bli sendt direkte til noden som ikke har problemer med SMS-gatewayen.

Som vi ser, er påliteligheten til JSON-RPC overvurdert. Faktisk er det lettere å organisere konsistens i databasen. Men i så fall vil påliteligheten til systemet som helhet bli offer.

Utgang er i stor grad lik den forrige. Når infrastrukturen er enkel, er tydeligheten av JSON-RPC utvilsomt et pluss. Hvis prosjektet krever høy tilgjengelighet med høy belastning, ser REST ut til å være et mer korrekt, om enn mer komplisert, valg.

Inngangsbarrieren for REST er lavere

Jeg mener at analysen ovenfor, som avkrefter etablerte stereotyper om RPC, tydelig viser at inngangsbarrieren for REST uten tvil er høyere enn for RPC. Dette skyldes behovet for en dyp forståelse av hvordan HTTP fungerer, samt behovet for tilstrekkelig kunnskap om eksisterende infrastrukturelementer som kan og bør brukes i WEB-prosjekter.

Så hvorfor tror mange at REST vil være enklere? Personlig mener jeg at denne tilsynelatende enkelheten stammer fra selve manifestene til REST. Det vil si, REST er ikke et protokoll, men et konsept… REST har ingen standard, det finnes enkelte anbefalinger… REST er ikke mer komplisert enn HTTP. Den tilsynelatende friheten og anarkiet tiltrekker "frie kunstnere".

Utvilsomt er ikke REST mer komplisert enn HTTP. Men HTTP i seg selv er et godt gjennomtenkt protokoll som har bevist sin holdbarhet gjennom tiår. Hvis det ikke finnes en dyp forståelse av HTTP selv, kan man ikke dømme om REST.

Men for RPC — det kan man. Det er tilstrekkelig å ta spesifikasjonen hans. Så trenger du dum JSON-RPC? Или все же хитрый REST? Решать вам.

Jeg håper virkelig at jeg ikke har kastet bort tiden din.

Kilde: habr.com