Jag Ă€r sĂ€ker pĂ„ att rubriken vĂ€ckte en sund reaktion â "nej, inte igen..." Men lĂ„t mig fĂ„nga din uppmĂ€rksamhet i 5-10 minuter, sĂ„ ska jag försöka leva upp till dina förvĂ€ntningar.
Strukturen i artikeln kommer att vara följande: en stereotypisk pÄstÄende tas upp och "naturen" av denna stereotypes ursprung förklaras. Jag hoppas att detta ger en ny synvinkel pÄ valet av paradigmet för datadelning i dina projekt.
För att det ska vara klart vad RPC Àr, föreslÄr jag att vi betraktar standarden . Det finns ingen tydlighet med REST. Och det ska det inte finnas. Allt du behöver veta om REST Àr att den Àr omöjlig att sÀrskilja frÄn .
RPC-förfrÄgningar Àr snabbare och mer effektiva eftersom de möjliggör batch-förfrÄgningar.
Det handlar om att i RPC kan flera procedurer anropas i samma förfrÄgan. Till exempel kan du skapa en anvÀndare, lÀgga till en avatar och i samma förfrÄgan prenumerera pÄ nÄgra Àmnen. Endast en förfrÄgan, men vilken nytta!
Verkligen, om du har bara en backendnod, kommer det att verka snabbare med en batch-förfrÄgan. För tre REST-förfrÄgningar kommer att krÀva tre gÄnger mer resurser frÄn en nod för att upprÀtta anslutningar.
Observera att den första förfrÄgan i REST-fallet mÄste returnera anvÀndarens ID för att möjliggöra efterföljande förfrÄgningar. Detta pÄverkar ocksÄ det totala resultatet negativt.
Men sÄdana infrastrukturer kan man hitta nÀstan bara i in-house-lösningar och företag. I bÀsta fall i smÄ WEB-projekt. FullstÀndiga WEB-lösningar, sÀrskilt de som kallas HighLoad, bör inte byggas pÄ det sÀttet. Deras infrastruktur mÄste uppfylla kriterierna för hög tillgÀnglighet och belastning. Och bilden förÀndras.
De gröna markerar kanaler för aktivitet i infrastrukturen vid samma scenario. Observera hur RPC fungerar nu. FörfrÄgan anvÀnder infrastrukturen endast genom en axel frÄn lastbalanseraren till backend. Samtidigt som REST fortfarande förlorar i den första förfrÄgan, men kompenserar för det genom att anvÀnda hela infrastrukturen.
Om vi introducerar inte tvÄ förfrÄgningar för berikning i scenariot, utan sÀg fem eller tio... sÄ blir svaret pÄ frÄgan "vem vinner nu?" inte sÄ uppenbart.
LÄt oss ta en djupare titt pÄ problemet. I diagrammet syns hur infrastrukturkanaler anvÀnds, men infrastrukturen begrÀnsas inte av kanaler. En viktig del av en högbelastningsinfrastruktur Àr cacheminnet. LÄt oss nu fÄ en anvÀndarartefakt. Flera gÄnger. LÄt oss sÀga 32 gÄnger.
Se hur infrastrukturen för RPC har "förbÀttrats" avsevÀrt för att möta kraven pÄ hög belastning. Anledningen Àr att REST utnyttjar hela kraften i HTTP-protokollet till skillnad frÄn RPC. I det medföljande diagrammet realiseras denna kraft genom begÀrningsmetoden - GET.
HTTP-metoder har strategies för cachning. Du kan bekanta dig med dem i dokumentationen pÄ . För RPC anvÀnds POST-förfrÄgningar, som inte betraktas som idempotenta, vilket innebÀr att upprepade POST-begÀrningar kan returnera olika resultat (till exempel, efter varje kommentarssÀndning kommer en ny kopia av den kommentaren att dyka upp) ().
DÀrför Àr RPC inte i stÄnd att effektivt utnyttja infrastrukturella cachar. Detta leder till att man mÄste "införa" mjukvarucachar. I diagrammet representeras detta av Redis. Mjukvarucachen krÀver i sin tur en extra kodlager frÄn utvecklarens sida samt tydliga förÀndringar i arkitekturen.
LÄt oss nu rÀkna hur mÄnga begÀrningar REST och RPC har genererat i den granskade infrastrukturen?
FörfrÄgningar
Inkommande
till backend
till DBMS
till mjukvarucachen (Redis)
OTAL
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] i bÀsta fall (om lokal cache anvÀnds) 1 begÀran (en!), i vÀrsta fall 32 inkommande begÀrningar.
JÀmfört med det första diagrammet Àr skillnaden slÄende. Det blir nu uppenbart att REST har fördelen. Men jag föreslÄr att vi inte stannar hÀr. En utvecklad infrastruktur inkluderar CDN. Ofta löser detta ocksÄ problemet mot DDoS- och DoS-attacker. Vi fÄr:
HÀr blir det riktigt dystert för RPC. RPC kan helt enkelt inte delegera arbetet med belastning till CDN. Endast system för att motverka attacker kan hoppas pÄ.
Kan vi avsluta hĂ€r? Och igen, nej. HTTP-metoder har, som nĂ€mnts ovan, sin âmagikâ. Det Ă€r inte utan anledning som metoden GET Ă€r den mest anvĂ€nda pĂ„ Internet. Observera att denna metod kan nĂ„ delar av innehĂ„llet och kan stĂ€lla villkor som kan tolkas av infrastrukturella element innan kontrollen överlĂ€mnas till din kod, och sĂ„ vidare. Detta möjliggör skapande av flexibla, hanterbara infrastrukturer som kan hantera verkligt stora flöden av förfrĂ„gningar. Och i RPC ignoreras denna metodâŠ
Men varför Àr myten om att batch-förfrÄgningar (RPC) Àr snabbare sÄ hÄllfast? Jag tycker personligen att de flesta projekt helt enkelt inte nÄr en utvecklingsnivÄ dÀr REST kan visa sin styrka. Dessutom, i smÄ projekt, visar det hellre sina svagheter.
Valet mellan REST och RPC Àr inte ett viljemÀssigt val av en enskild person i projektet. Detta val bör svara mot projektets krav. Om projektet kan pressa ut allt som REST verkligen kan, och detta verkligen Àr nödvÀndigt, dÄ kommer REST att vara ett utmÀrkt val.
Men om det krÀvs att anstÀlla devops för att snabbt skala infrastrukturen, administratörer för att hantera infrastrukturen, och en arkitekt för att designa alla lager av WEB-tjÀnsten⊠och projektet sÀljer tre paket smör per dag⊠skulle jag stanna vid RPC, eftersom detta protokoll Àr mer utilitaristiskt. Det krÀver inte djup kunskap om cache och infrastruktur, utan fokuserar utvecklaren pÄ enkla och tydliga anrop av de nödvÀndiga procedurerna. AffÀren kommer att vara nöjd.
RPC-förfrÄgningar Àr mer tillförlitliga eftersom de kan utföra batch-förfrÄgningar inom en och samma transaktion.
Denna egenskap hos RPC Àr onekligen en fördel, eftersom det gör det lÀtt att hÄlla databasen i ett konsekvent tillstÄnd. Men med REST Àr det mer komplicerat. FörfrÄgningar kan komma oregelbundet till olika noder i backend.
Denna "nackdel" med REST Ă€r den motsatta sidan av dess fördel som beskrivits ovan â förmĂ„gan att effektivt utnyttja alla resurser i infrastrukturen. Om infrastrukturen Ă€r dĂ„ligt designad, Ă€nnu vĂ€rre om projektets arkitektur och databasen i synnerhet Ă€r dĂ„ligt designade, sĂ„ Ă€r det verkligen en stor smĂ€rta.
Men hur pÄlitliga Àr batch-förfrÄgningar egentligen? LÄt oss titta pÄ ett exempel: vi skapar en anvÀndare, berikar hennes profil med en beskrivning och skickar ett SMS med en hemlighet för att slutföra registreringen. Det vill sÀga tre anrop i en batch-förfrÄgan.
LĂ„t oss granska schemat. DĂ€r visas infrastrukturen med högt tillgĂ€ngliga element. Det finns tvĂ„ oberoende kommunikationskanaler med SMS-gateways. Men... vad ser vi? NĂ€r vi skickar SMS uppstĂ„r ett fel 503 â tjĂ€nsten Ă€r tillfĂ€lligt otillgĂ€nglig. Eftersom SMS-sĂ€ndningen Ă€r packad i en batch-förfrĂ„gan, mĂ„ste hela förfrĂ„gan rullas tillbaka. Ă tgĂ€rderna i databasen annulleras. Klienten fĂ„r ett felmeddelande.
NÀsta försök Àr som en lottovinst. Antingen hamnar förfrÄgan Äterigen pÄ samma nod och ger samma fel, eller sÄ har vi tur och den lyckas. Men det viktigaste Àr att vÄr infrastruktur redan har arbetat förgÀves Ätminstone en gÄng. Det har varit belastning, men ingen vinst.
Okej, lÄt oss förestÀlla oss att vi anstrÀnger oss (!) och har tÀnkt igenom ett alternativ dÀr förfrÄgan kan lyckas delvis. Resten kommer vi Äterigen att försöka utföra efter ett visst tidsintervall (Vilket? Det avgör frontend?). Men lotteriet kvarstÄr. FörfrÄgan om att skicka SMS kommer med en 50/50 chans att misslyckas igen.
HÄller ni inte med om att tjÀnsten sett frÄn kundens perspektiv inte verkar sÄ pÄlitlig som man skulle önska⊠och hur Àr det med REST?
REST anvĂ€nder Ă„terigen "magin" i HTTP, men nu med svarskoder. NĂ€r ett fel 503 uppstĂ„r pĂ„ SMS-gatewayen översĂ€tter backend detta fel till lastbalanseraren. Lastbalanseraren, som fĂ„r detta fel och inte bryter förbindelsen med klienten, skickar förfrĂ„gan till en annan nod som framgĂ„ngsrikt hanterar förfrĂ„gan. Det vill sĂ€ga, klienten fĂ„r det förvĂ€ntade resultatet, och infrastrukturen bekrĂ€ftar sitt höga anseende som âhögt tillgĂ€ngligâ. AnvĂ€ndaren Ă€r nöjd.
Och detta Ă€r inte allt. Lastbalanseraren fick inte bara svarskoden 503. Enligt standard Ă€r det önskvĂ€rt att denna kod Ă„tföljs av en âRetry-Afterâ-header. Headern informerar lastbalanseraren om att inte störa denna nod för den hĂ€r rutten under den angivna tiden. SĂ„ nĂ€sta förfrĂ„gningar för att skicka SMS kommer direkt att skickas till en nod som inte har nĂ„gra problem med SMS-gatewayen.
Som vi ser Àr pÄlitligheten hos JSON-RPC överdriven. Faktiskt Àr det enklare att organisera konsistens i databasen. Men priset för detta blir systemets övergripande pÄlitlighet.
Utdata liknar mycket det föregÄende. NÀr infrastrukturen Àr enkel Àr tydligheten i JSON-RPC utan tvekan en fördel. Om projektet förvÀntar sig hög tillgÀnglighet med hög belastning, framstÄr REST som det mer korrekta, Àven om mer komplicerade, lösningen.
IngÄngströskeln för REST Àr lÀgre
Jag tror att den analys som gjorts ovan, som avfÀrdar etablerade myter om RPC, tydligt visar att ingÄngströskeln för REST utan tvekan Àr högre Àn för RPC. Detta beror pÄ behovet av en djup förstÄelse för hur HTTP fungerar, samt behovet av att ha tillrÀckliga kunskaper om de befintliga infrastrukturella elementen som kan och bör tillÀmpas i WEB-projekt.
SÄ varför tror mÄnga att REST skulle vara enklare? Enligt min mening beror denna till synes enkla natur pÄ sjÀlva REST-manifesten. Det vill sÀga, REST Àr inte ett protokoll, utan ett koncept... REST har ingen standard, det finns vissa rekommendationer... REST Àr inte svÄrare Àn HTTP. Den uppenbara friheten och anarkin lockar "fria konstnÀrer".
Utan tvekan Àr REST inte svÄrare Àn HTTP. Men sjÀlva HTTP Àr ett vÀlgenomtÀnkt protokoll som har bevisat sin vÀrdighet i Ärtionden. Om man inte har en djup förstÄelse för HTTP, kan man inte heller bedöma REST.
Men nĂ€r det kommer till RPC â kan man. Det rĂ€cker med att ta dess specifikation. SĂ„ behöver du ? ĐлО ĐČŃĐ” жД Ń ĐžŃŃŃĐč REST? Đ Đ”ŃĐ°ŃŃ ĐČĐ°ĐŒ.
Jag hoppas verkligen att jag inte har slösat bort din tid.
KĂ€lla: habr.com
