Jag är säker på att rubriken orsakade en hälsosam reaktion - "ja, det har börjat igen..." Men låt mig fånga din uppmärksamhet i 5-10 minuter, så ska jag försöka att inte svika dina förväntningar.
Strukturen för artikeln kommer att vara som följer: ett stereotypt uttalande tas och "naturen" av uppkomsten av denna stereotyp avslöjas. Jag hoppas att detta gör att du kan se valet av datautbyteparadigm i dina projekt från en ny vinkel.
För att vara tydlig med vad RPC är, föreslår jag att man överväger standarden . Med REST finns ingen klarhet. Och det borde det inte vara. Allt du behöver veta om REST - det går inte att skilja från .
RPC-förfrågningar är snabbare och effektivare eftersom de låter dig göra batchförfrågningar.
Poängen är att i RPC kan du anropa flera procedurer samtidigt i en begäran. Till exempel, skapa en användare, lägg till en avatar till honom och, i samma begäran, prenumerera på vissa ämnen. Bara en förfrågan, och vilken nytta!
Faktum är att om du bara har en backend-nod kommer det att verka snabbare med en batchbegäran. Eftersom 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 begäran i fallet med REST måste returnera användar-ID för att efterföljande förfrågningar ska kunna göras. Vilket också påverkar det totala resultatet negativt.
Men sådana infrastrukturer finns bara i interna lösningar och Enterprise. Som en sista utväg, i små WEB-projekt. Men fullfjädrade WEB-lösningar, och även de som kallas HighLoad, är inte värda att bygga. Deras infrastruktur måste uppfylla kriterierna för hög tillgänglighet och belastning. Och bilden förändras.
Infrastrukturaktivitetskanaler under samma scenario är markerade med grönt. Lägg märke till hur RPC beter sig nu. Begäran använder infrastrukturen på endast ett ben från balanseraren till backend. Medan REST fortfarande förlorar i den första begäran, kompenserar det för förlorad tid genom att använda hela infrastrukturen.
Det räcker att inte skriva in två förfrågningar om berikning i manuset, utan, säg, fem eller tio ... och svaret på frågan "vem vinner nu?" blir oklart.
Jag föreslår att vi tar en ännu bredare titt på problemet. Diagrammet visar hur infrastrukturkanaler används, men infrastrukturen är inte begränsad till kanaler. En viktig komponent i en högbelastningsinfrastruktur är cacher. Låt oss nu få någon form av användarartefakt. Upprepat. Låt oss säga 32 gånger.
Se hur RPC-infrastrukturen har förbättrats avsevärt för att möta kraven på hög belastning. Saken är att REST använder full kraft av HTTP-protokollet, till skillnad från RPC. I diagrammet ovan realiseras denna kraft genom begäranmetoden - GET.
HTTP-metoder har bland annat cachningsstrategier. Du hittar dem i dokumentationen på . För RPC används POST-förfrågningar, som inte anses vara idempotenta, det vill säga upprepade upprepningar av samma POST-förfrågningar kan ge olika resultat (till exempel efter att varje kommentar har skickats kommer en annan kopia av denna kommentar att visas) ().
Följaktligen kan RPC inte effektivt använda infrastrukturcachar. Detta leder till behovet av att "importera" mjukvarucachar. Diagrammet visar Redis i denna roll. Programvarucachen kräver i sin tur att utvecklaren lägger till ett extra lager med kod och märkbara förändringar i arkitekturen.
Låt oss nu räkna hur många förfrågningar REST och RPC "födde upp" i den infrastruktur som övervägs?
förfrågningar
inkorg
till backend
till DBMS
till mjuk cache (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Jämfört med det första schemat är skillnaden slående. Nu blir fördelen med REST tydlig. Men jag föreslår att du inte slutar där. Den utvecklade infrastrukturen inkluderar ett CDN. Ofta löser det också problemet med att motverka DDoS- och DoS-attacker. Vi får:
Det är här det blir riktigt dåligt för RPC. RPC kan helt enkelt inte delegera arbetsbelastningen till ett CDN. Vi kan bara lita på system för att motverka attacker.
Är det möjligt att sluta här? Och igen, nej. HTTP-metoder, som nämnts ovan, har sin egen "magi". Och det är inte utan anledning som GET-metoden används flitigt på Internet. Observera att den här metoden kan komma åt ett stycke innehåll, kan ställa in villkor som infrastrukturelement kan tolka innan kontrollen överförs till din kod, och så vidare. Allt detta gör att du kan skapa flexibla, hanterbara infrastrukturer som kan hantera riktigt stora flöden av förfrågningar. Men i RPC ignoreras denna metod...
Så varför är myten att batch requests (RPC) är snabbare så ihållande? Personligen verkar det som om de flesta projekt helt enkelt inte når en utvecklingsnivå där REST kan visa sin styrka. Dessutom, i små projekt, är han mer villig att visa sina svagheter.
Valet av REST eller RPC är inte ett frivilligt val av en individ i ett projekt. Detta val måste uppfylla projektets krav. Om ett projekt kan pressa ut allt det verkligen kan ur REST, och det verkligen behöver det, så kommer REST att vara ett utmärkt val.
Men om du, för att få alla fördelar med REST, behöver anställa devops-specialister för projektet för att snabbt skala infrastrukturen, administratörer för att hantera infrastrukturen, en arkitekt för att designa alla lager i WEB-tjänsten... och projektet säljer samtidigt tre förpackningar margarin om dagen... Jag skulle hålla mig till RPC, eftersom... detta protokoll är mer utilitaristiskt. Det kommer inte att kräva djup kunskap om hur cacher och infrastruktur fungerar, utan kommer att fokusera utvecklaren på enkla och begripliga anrop till de procedurer han behöver. Business kommer att vara glada.
RPC-förfrågningar är mer tillförlitliga eftersom de kan utföra batchförfrågningar inom en enda transaktion
Denna egenskap hos RPC är en klar fördel, eftersom Det är lätt att hålla databasen konsekvent. Men med REST blir det mer och mer komplicerat. Förfrågningar kan komma in inkonsekvent till olika backend-noder.
Denna "nackdel" med REST är baksidan av dess fördel som beskrivs ovan - förmågan att effektivt använda alla infrastrukturresurser. Om infrastrukturen är dåligt utformad, och ännu mer om projektets arkitektur och databasen i synnerhet är dåligt utformad, så är detta verkligen en stor smärta.
Men är batchförfrågningar så tillförlitliga som de verkar? Låt oss titta på ett fall: vi skapar en användare, berikar hans profil med någon beskrivning och skickar honom ett SMS med en hemlighet för att slutföra registreringen. De där. tre samtal i en batch-förfrågan.
Låt oss titta på diagrammet. Det presenterar en infrastruktur med hög tillgänglighetselement. Det finns två oberoende kommunikationskanaler med SMS-gateways. Men... vad ser vi? När du skickar ett SMS uppstår ett fel 503 - tjänsten är tillfälligt otillgänglig. Därför att SMS-sändning paketeras i en batchförfrågan, sedan måste hela förfrågan rullas tillbaka. Åtgärder i DBMS avbryts. Klienten får ett felmeddelande.
Nästa försök är lotteriet. Antingen kommer förfrågan att träffa samma nod om och om igen ett fel, eller så kommer du att ha tur och den kommer att exekveras. Men huvudsaken är att vår infrastruktur åtminstone en gång redan har fungerat förgäves. Det var en belastning, men ingen vinst.
Okej, låt oss föreställa oss att vi har ansträngt oss (!) och tänkt igenom alternativet när förfrågan delvis kan slutföras framgångsrikt. Och vi kommer att försöka slutföra resten igen efter ett visst tidsintervall (Vilken? Avgör fronten?). Men lotteriet förblev detsamma. Begäran om att skicka SMS har en 50/50 chans att misslyckas igen.
Håller med, från kundsidan verkar tjänsten inte så tillförlitlig som vi skulle vilja... hur är det med REST?
REST använder magin med HTTP igen, men nu med svarskoder. När ett fel 503 inträffar på SMS-gatewayen, sänder backend detta fel till balanseraren. Balanseraren tar emot detta fel och utan att bryta förbindelsen med klienten skickar den begäran till en annan nod, som framgångsrikt bearbetar begäran. De där. kunden får det förväntade resultatet och infrastrukturen bekräftar sin höga titel "högt tillgänglig". Användaren är nöjd.
Och återigen det är inte allt. Balanseraren fick inte bara en svarskod på 503. När du svarar, enligt standarden, är det lämpligt att ge denna kod med rubriken "Retry-After". Rubriken gör det klart för balansören att det inte är värt att störa denna nod på denna rutt under en viss tid. Och nästa begäran om att skicka SMS kommer att skickas direkt till en nod som inte har några problem med SMS-gatewayen.
Som vi kan se är tillförlitligheten hos JSON-RPC överskattad. Det är faktiskt lättare att organisera konsistens i databasen. Men uppoffringen, i det här fallet, kommer att vara tillförlitligheten hos systemet som helhet.
Slutsatsen liknar i stort sett den föregående. När infrastrukturen är enkel är självklarheten i JSON-RPC definitivt ett plus. Om projektet innebär hög tillgänglighet med hög belastning ser REST ut som en mer korrekt, om än mer komplex, lösning.
Ingångströskeln till REST är lägre
Jag tror att analysen ovan, som avslöjar de etablerade stereotyperna om RPC, tydligt visade att tröskeln för inträde i REST utan tvekan är högre än i RPC. Detta beror på behovet av en djup förståelse för hur HTTP fungerar, samt behovet av att ha tillräcklig kunskap om befintliga infrastrukturelement som kan och bör användas i WEB-projekt.
Så varför tror många att REST blir enklare? Min personliga åsikt är att denna skenbara enkelhet kommer från REST manifesterar sig själva. De där. REST är inte ett protokoll utan ett koncept... REST har ingen standard, det finns några riktlinjer... REST är inte mer komplicerat än HTTP. Uppenbar frihet och anarki lockar "fria artister".
Naturligtvis är REST inte mer komplicerat än HTTP. Men HTTP i sig är ett väldesignat protokoll som har bevisat sitt värde under decennier. Om det inte finns någon djup förståelse för själva HTTP kan REST inte bedömas.
Men om RPC - det kan du. Det räcker med att ta dess specifikation. Så behöver du ? Eller är det fortfarande knepigt VILA? Du bestämmer.
Jag hoppas innerligt att jag inte har slösat bort din tid.
Källa: will.com