Jeg er sikker på, at overskriften vakte en sund reaktion - "jamen, det er begyndt igen..." Men lad mig fange din opmærksomhed i 5-10 minutter, og jeg vil forsøge ikke at skuffe dine forventninger.
Artiklens struktur vil være som følger: en stereotyp udtalelse tages, og "naturen" af fremkomsten af denne stereotype afsløres. Jeg håber, at dette vil give dig mulighed for at se på valget af dataudvekslingsparadigme i dine projekter fra en ny vinkel.
For at være klar over, hvad RPC er, foreslår jeg at overveje standarden . Med REST er der ingen klarhed. Og det burde det ikke være. Alt hvad du behøver at vide om REST - det kan ikke skelnes fra .
RPC-anmodninger er hurtigere og mere effektive, fordi de giver dig mulighed for at lave batch-anmodninger.
Pointen er, at du i RPC kan kalde flere procedurer på én gang i en anmodning. Opret f.eks. en bruger, tilføj en avatar til ham og abonner ham på nogle emner i samme anmodning. Kun én anmodning, og hvor meget gavn!
Faktisk, hvis du kun har én backend-node, vil det virke hurtigere med en batch-anmodning. Fordi tre REST-anmodninger vil kræve tre gange flere ressourcer fra én node for at etablere forbindelser.
Bemærk, at den første anmodning i tilfælde af REST skal returnere bruger-id'et, for at efterfølgende anmodninger kan foretages. Hvilket også påvirker det samlede resultat negativt.
Men sådanne infrastrukturer kan kun findes i interne løsninger og Enterprise. Som en sidste udvej i små WEB-projekter. Men fuldgyldige WEB-løsninger, og selv dem, der kaldes HighLoad, er ikke værd at bygge. Deres infrastruktur skal opfylde kriterierne om høj tilgængelighed og belastning. Og billedet ændrer sig.
Infrastrukturaktivitetskanaler under samme scenarie er markeret med grønt. Læg mærke til, hvordan RPC opfører sig nu. Anmodningen bruger kun infrastrukturen på det ene ben fra balanceren til backend. Mens REST stadig taber i den første anmodning, kompenserer det for tabt tid ved at bruge hele infrastrukturen.
Det er nok at indtaste ikke to anmodninger om berigelse i manuskriptet, men for eksempel fem eller ti ... og svaret på spørgsmålet "hvem vinder nu?" bliver uklart.
Jeg foreslår at se på problemet endnu bredere. Diagrammet viser, hvordan infrastrukturkanaler bruges, men infrastruktur er ikke begrænset til kanaler. En vigtig komponent i en højbelastningsinfrastruktur er caches. Lad os nu få en slags brugerartefakt. Gentagne gange. Lad os sige 32 gange.
Se, hvordan RPC-infrastrukturen er blevet væsentligt forbedret for at opfylde kravene til høj belastning. Sagen er, at REST bruger den fulde kraft af HTTP-protokollen, i modsætning til RPC. I diagrammet ovenfor realiseres denne effekt gennem anmodningsmetoden - GET.
HTTP-metoder har blandt andet caching-strategier. Du kan finde dem i dokumentationen på . Til RPC bruges POST-anmodninger, som ikke betragtes som idempotente, det vil sige, at gentagne gentagelser af de samme POST-anmodninger kan returnere forskellige resultater (f.eks. efter hver kommentar er sendt, vil en anden kopi af denne kommentar vises) ().
RPC er derfor ikke i stand til effektivt at bruge infrastrukturcaches. Dette fører til behovet for at "importere" software-caches. Diagrammet viser Redis i denne rolle. Softwarecachen kræver til gengæld, at udvikleren tilføjer et ekstra lag kode og mærkbare ændringer i arkitekturen.
Lad os nu tælle, hvor mange anmodninger REST og RPC "affødte" i den undersøgte infrastruktur?
anmodninger
indbakke
til backend
til DBMS
til blød cache (Redis)
ALT
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
I forhold til den første ordning er forskellen slående. Nu bliver fordelen ved REST tydelig. Men jeg foreslår, at du ikke stopper der. Den udviklede infrastruktur inkluderer et CDN. Ofte løser det også problemet med at imødegå DDoS- og DoS-angreb. Vi får:
Det er her, tingene bliver rigtig dårlige for RPC. RPC er simpelthen ikke i stand til at uddelegere arbejdsbyrden til et CDN. Vi kan kun stole på systemer til at imødegå angreb.
Er det muligt at slutte her? Og igen, nej. HTTP-metoder, som nævnt ovenfor, har deres egen "magi". Og det er ikke uden grund, at GET-metoden er meget udbredt på internettet. Bemærk, at denne metode er i stand til at få adgang til et stykke indhold, er i stand til at indstille betingelser, som infrastrukturelementer kan fortolke, før kontrol overføres til din kode, og så videre. Alt dette giver dig mulighed for at skabe fleksible, håndterbare infrastrukturer, der kan håndtere virkelig store strømme af anmodninger. Men i RPC ignoreres denne metode...
Så hvorfor er myten om, at batch requests (RPC) er hurtigere, så vedvarende? Personligt forekommer det mig, at de fleste projekter simpelthen ikke når et udviklingsniveau, hvor REST er i stand til at vise sin styrke. Desuden er han i små projekter mere villig til at vise sine svagheder.
Valget af REST eller RPC er ikke et frivilligt valg af en person i et projekt. Dette valg skal opfylde projektets krav. Hvis et projekt er i stand til at presse alt, hvad det virkelig kan ud af REST, og det virkelig har brug for det, så vil REST være et glimrende valg.
Men hvis du, for at få alle fordelene ved REST, skal ansætte devops-specialister til projektet for hurtigt at skalere infrastrukturen, administratorer til at administrere infrastrukturen, en arkitekt til at designe alle lag af WEB-tjenesten... og projektet , sælger samtidig tre pakker margarine om dagen... Jeg ville holde mig til RPC, fordi... denne protokol er mere utilitaristisk. Det vil ikke kræve dyb viden om, hvordan caches og infrastruktur fungerer, men vil fokusere udvikleren på enkle og forståelige opkald til de procedurer, han har brug for. Virksomheden vil være glad.
RPC-anmodninger er mere pålidelige, fordi de kan udføre batch-anmodninger inden for en enkelt transaktion
Denne egenskab ved RPC er en klar fordel, fordi Det er nemt at holde databasen konsistent. Men med REST bliver det mere og mere kompliceret. Anmodninger kan ankomme inkonsekvent til forskellige backend-noder.
Denne "ulempe" ved REST er bagsiden af dens fordel beskrevet ovenfor - evnen til effektivt at bruge alle infrastrukturressourcer. Hvis infrastrukturen er dårligt designet, og endnu mere hvis arkitekturen af projektet og databasen i særdeleshed er dårligt designet, så er det virkelig en stor smerte.
Men er batch-anmodninger så pålidelige, som de ser ud til? Lad os se på en sag: vi opretter en bruger, beriger hans profil med en beskrivelse og sender ham en sms med en hemmelighed for at fuldføre registreringen. De der. tre opkald i én batch-anmodning.
Lad os se på diagrammet. Det præsenterer en infrastruktur med høje tilgængelighedselementer. Der er to uafhængige kommunikationskanaler med SMS-gateways. Men... hvad ser vi? Når du sender en SMS, opstår der en fejl 503 - tjenesten er midlertidigt utilgængelig. Fordi SMS-afsendelse er pakket i en batch-anmodning, så skal hele anmodningen rulles tilbage. Handlinger i DBMS annulleres. Klienten modtager en fejl.
Næste forsøg er lotteriet. Enten vil anmodningen ramme den samme node igen og igen returnere en fejl, eller også vil du være heldig, og den vil blive udført. Men det vigtigste er, at mindst én gang vores infrastruktur allerede har fungeret forgæves. Der var et læs, men ingen fortjeneste.
Okay, lad os forestille os, at vi anstrengte os (!) og gennemtænkte muligheden, hvornår anmodningen delvist kunne gennemføres med succes. Og vi vil forsøge at fuldføre resten igen efter noget tidsinterval (Hvilken? Bestemmer fronten?). Men lotteriet forblev det samme. Anmodningen om at sende SMS har en 50/50 chance for at mislykkes igen.
Enig, fra klientens side virker tjenesten ikke så pålidelig, som vi gerne ville... hvad med REST?
REST bruger magien ved HTTP igen, men nu med svarkoder. Når en fejl 503 opstår på SMS-gatewayen, udsender backend denne fejl til balanceren. Balanceren modtager denne fejl og uden at afbryde forbindelsen med klienten sender anmodningen til en anden node, som behandler anmodningen med succes. De der. kunden modtager det forventede resultat, og infrastrukturen bekræfter sin høje titel "højt tilgængelig". Brugeren er glad.
Og igen er det ikke alt. Balanceren modtog ikke bare en svarkode på 503. Når du svarer, er det ifølge standarden tilrådeligt at give denne kode med "Retry-After"-headeren. Headeren gør det klart for balanceren, at det ikke er værd at forstyrre denne node på denne rute i et bestemt tidsrum. Og de næste anmodninger om at sende SMS vil blive sendt direkte til en node, der ikke har problemer med SMS-gatewayen.
Som vi kan se, er pålideligheden af JSON-RPC overvurderet. Det er faktisk nemmere at organisere konsistens i databasen. Men ofret vil i dette tilfælde være pålideligheden af systemet som helhed.
Konklusionen ligner stort set den foregående. Når infrastrukturen er enkel, er selvfølgeligheden af JSON-RPC bestemt et plus. Hvis projektet involverer høj tilgængelighed med høj belastning, ser REST ud som en mere korrekt, men mere kompleks løsning.
Indgangstærsklen til REST er lavere
Jeg tror, at ovenstående analyse, der afslørede de etablerede stereotyper om RPC, klart viste, at tærsklen for adgang til REST utvivlsomt er højere end til RPC. Dette skyldes behovet for en dyb forståelse af, hvordan HTTP fungerer, samt behovet for at have tilstrækkelig viden om eksisterende infrastrukturelementer, der kan og bør bruges i WEB-projekter.
Så hvorfor tror mange mennesker, at REST vil være enklere? Min personlige mening er, at denne tilsyneladende enkelhed kommer fra REST manifesterer sig selv. De der. REST er ikke en protokol, men et koncept... REST har ikke en standard, der er nogle retningslinjer... REST er ikke mere kompliceret end HTTP. Tilsyneladende frihed og anarki tiltrækker "frie kunstnere".
Selvfølgelig er REST ikke mere kompliceret end HTTP. Men HTTP i sig selv er en veldesignet protokol, der har bevist sit værd gennem årtier. Hvis der ikke er nogen dyb forståelse af HTTP i sig selv, kan REST ikke bedømmes.
Men om RPC - det kan du. Det er nok at tage dens specifikation. Så har du brug for ? Eller er det stadig svært REST? Du bestemmer.
Jeg håber inderligt, at jeg ikke har spildt din tid.
Kilde: www.habr.com