Ik ben er zeker van dat de kop een gezonde reactie veroorzaakte - "nou, het is weer begonnen..." Maar laat me 5-10 minuten uw aandacht trekken, en ik zal proberen uw verwachtingen niet teleur te stellen.
De structuur van het artikel zal als volgt zijn: er wordt een stereotiepe verklaring genomen en de ‘aard’ van de opkomst van dit stereotype wordt onthuld. Ik hoop dat dit u in staat zal stellen om vanuit een nieuwe invalshoek naar de keuze van het data-uitwisselingsparadigma in uw projecten te kijken.
Om duidelijk te maken wat RPC is, stel ik voor om de standaard te overwegen . Bij REST is er geen duidelijkheid. En dat zou niet zo moeten zijn. Alles wat je moet weten over REST – het is niet van elkaar te onderscheiden .
RPC-aanvragen zijn sneller en efficiënter omdat u hiermee batchaanvragen kunt doen.
Het punt is dat je in RPC meerdere procedures tegelijk in één verzoek kunt aanroepen. Maak bijvoorbeeld een gebruiker aan, voeg een avatar aan hem toe en abonneer hem in hetzelfde verzoek op een aantal onderwerpen. Slechts één verzoek, en hoeveel voordeel!
Als u slechts één backend-knooppunt heeft, lijkt het inderdaad sneller met een batchverzoek. Omdat voor drie REST-verzoeken drie keer meer bronnen van één knooppunt nodig zijn om verbindingen tot stand te brengen.
Houd er rekening mee dat het eerste verzoek in het geval van REST de gebruikers-ID moet retourneren voordat volgende verzoeken kunnen worden gedaan. Wat ook een negatief effect heeft op het totaalresultaat.
Maar dergelijke infrastructuren zijn alleen te vinden in interne oplossingen en Enterprise. Als laatste redmiddel, in kleine WEB-projecten. Maar volwaardige WEB-oplossingen, en zelfs die welke HighLoad worden genoemd, zijn het bouwen niet waard. Hun infrastructuur moet voldoen aan de criteria van hoge beschikbaarheid en belasting. En het beeld verandert.
Kanalen voor infrastructuuractiviteiten onder hetzelfde scenario zijn groen gemarkeerd. Merk op hoe RPC zich nu gedraagt. Het verzoek gebruikt de infrastructuur op slechts één been, van de balancer naar de backend. Hoewel REST nog steeds verliest bij het eerste verzoek, compenseert het de verloren tijd door gebruik te maken van de volledige infrastructuur.
Het is voldoende om niet twee verzoeken om verrijking in het script in te voeren, maar bijvoorbeeld vijf of tien... en het antwoord op de vraag "wie wint er nu?" wordt onduidelijk.
Ik stel voor om het probleem nog breder te bekijken. Het diagram laat zien hoe infrastructuurkanalen worden gebruikt, maar infrastructuur is niet beperkt tot kanalen. Een belangrijk onderdeel van een infrastructuur met hoge belasting zijn caches. Laten we nu een soort gebruikersartefact nemen. Herhaaldelijk. Laten we zeggen 32 keer.
Ontdek hoe de RPC-infrastructuur aanzienlijk is verbeterd om aan de eisen van hoge belasting te voldoen. Het punt is dat REST de volledige kracht van het HTTP-protocol gebruikt, in tegenstelling tot RPC. In het bovenstaande diagram wordt deze kracht gerealiseerd via de verzoekmethode - GET.
HTTP-methoden hebben onder andere cachingstrategieën. U kunt ze vinden in de documentatie op . Voor RPC worden POST-verzoeken gebruikt, die niet als idempotent worden beschouwd, dat wil zeggen dat herhaalde herhalingen van dezelfde POST-verzoeken verschillende resultaten kunnen opleveren (nadat elke opmerking is verzonden, verschijnt er bijvoorbeeld een andere kopie van deze opmerking) ().
Bijgevolg kan RPC infrastructuurcaches niet effectief gebruiken. Dit leidt tot de noodzaak om softwarecaches te “importeren”. Het diagram toont Redis in deze rol. De softwarecache vereist op zijn beurt dat de ontwikkelaar een extra codelaag en merkbare veranderingen in de architectuur toevoegt.
Laten we nu eens tellen hoeveel verzoeken REST en RPC hebben “gevonden” in de beschouwde infrastructuur?
verzoeken
inbox
naar backend
naar het DBMS
naar zachte cache (Redis)
TOTAAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Vergeleken met het eerste schema is het verschil opvallend. Nu wordt het voordeel van REST duidelijk. Maar ik stel voor om daar niet te stoppen. De ontwikkelde infrastructuur omvat een CDN. Vaak lost het ook het probleem van het tegengaan van DDoS- en DoS-aanvallen op. We krijgen:
Dit is waar het echt slecht wordt voor RPC. RPC is eenvoudigweg niet in staat de werklast naar een CDN te delegeren. We kunnen alleen vertrouwen op systemen om aanvallen tegen te gaan.
Is het mogelijk om hier te eindigen? En nogmaals, nee. HTTP-methoden hebben, zoals hierboven vermeld, hun eigen “magie”. En niet voor niets wordt de GET-methode veel gebruikt op internet. Merk op dat deze methode toegang heeft tot een stukje inhoud, voorwaarden kan stellen die infrastructuurelementen kunnen interpreteren voordat de controle wordt overgedragen naar uw code, enzovoort. Dit alles stelt u in staat flexibele, beheerbare infrastructuren te creëren die echt grote verzoekenstromen aankunnen. Maar in RPC wordt deze methode... genegeerd.
Dus waarom is de mythe dat batchverzoeken (RPC) sneller zijn zo hardnekkig? Persoonlijk lijkt het mij dat de meeste projecten simpelweg niet een ontwikkelingsniveau bereiken waarop REST zijn kracht kan tonen. Bovendien is hij bij kleine projecten meer bereid zijn zwakheden te tonen.
De keuze voor REST of RPC is geen vrijwillige keuze van een individu in een project. Deze keuze moet voldoen aan de eisen van het project. Als een project alles uit REST kan halen, en het ook echt nodig heeft, dan is REST een uitstekende keuze.
Maar als je, om alle voordelen van REST te kunnen benutten, devops-specialisten moet inhuren voor het project om de infrastructuur snel op te schalen, beheerders om de infrastructuur te beheren, een architect om alle lagen van de WEB-service te ontwerpen... en het project , verkoopt tegelijkertijd drie pakjes margarine per dag... Ik zou bij RPC blijven, omdat... dit protocol is meer utilitair. Het vereist geen diepgaande kennis van hoe caches en infrastructuur werken, maar zal de ontwikkelaar concentreren op eenvoudige en begrijpelijke oproepen naar de procedures die hij nodig heeft. Het bedrijfsleven zal blij zijn.
RPC-verzoeken zijn betrouwbaarder omdat ze batchverzoeken binnen één transactie kunnen uitvoeren
Deze eigenschap van RPC is een duidelijk voordeel, omdat Het is gemakkelijk om de database consistent te houden. Maar met REST wordt het steeds ingewikkelder. Verzoeken kunnen inconsistent aankomen bij verschillende back-endknooppunten.
Dit “nadeel” van REST is de keerzijde van het hierboven beschreven voordeel: het vermogen om alle infrastructuurbronnen efficiënt te gebruiken. Als de infrastructuur slecht ontworpen is, en nog meer als de architectuur van het project en de database in het bijzonder slecht ontworpen zijn, dan is dit echt een groot probleem.
Maar zijn batchverzoeken wel zo betrouwbaar als ze lijken? Laten we eens naar een geval kijken: we maken een gebruiker aan, verrijken zijn profiel met een beschrijving en sturen hem een sms met een geheim om de registratie te voltooien. Die. drie oproepen in één batchverzoek.
Laten we naar het diagram kijken. Het biedt een infrastructuur met elementen met hoge beschikbaarheid. Er zijn twee onafhankelijke communicatiekanalen met SMS-gateways. Maar... wat zien we? Bij het verzenden van een sms treedt fout 503 op: de dienst is tijdelijk niet beschikbaar. Omdat Het verzenden van sms-berichten wordt verpakt in een batchverzoek, waarna het gehele verzoek moet worden teruggedraaid. Acties in het DBMS worden geannuleerd. De client ontvangt een foutmelding.
De volgende poging is de loterij. Ofwel zal het verzoek steeds weer hetzelfde knooppunt raken en opnieuw een fout opleveren, ofwel heb je geluk en wordt het uitgevoerd. Maar het belangrijkste is dat onze infrastructuur in ieder geval al tevergeefs heeft gewerkt. Er was een lading, maar geen winst.
Oké, laten we ons voorstellen dat we onszelf hebben ingespannen (!) en hebben nagedacht over de optie wanneer het verzoek gedeeltelijk succesvol kan worden voltooid. En we zullen proberen de rest na enige tijd opnieuw af te ronden (welke? beslist het front?). Maar de loterij bleef hetzelfde. De kans dat het verzoek om een sms te versturen opnieuw mislukt, is 50/50.
Mee eens, vanaf de klantkant lijkt de service niet zo betrouwbaar als we zouden willen... hoe zit het met REST?
REST gebruikt opnieuw de magie van HTTP, maar nu met responscodes. Wanneer een fout 503 optreedt op de SMS-gateway, zendt de backend deze fout uit naar de balancer. De balancer ontvangt deze fout en stuurt, zonder de verbinding met de client te verbreken, het verzoek naar een ander knooppunt, dat het verzoek met succes verwerkt. Die. de klant krijgt het verwachte resultaat en de infrastructuur bevestigt zijn hoge titel ‘zeer toegankelijk’. De gebruiker is blij.
En nogmaals, dat is nog niet alles. De balancer heeft niet zomaar de responscode 503 ontvangen. Bij het reageren is het volgens de standaard raadzaam om deze code te voorzien van de header “Retry-After”. De header maakt de balancer duidelijk dat het niet de moeite waard is om dit knooppunt op deze route gedurende een bepaalde tijd te verstoren. En de volgende verzoeken om sms-berichten te verzenden, worden rechtstreeks naar een knooppunt verzonden dat geen problemen heeft met de sms-gateway.
Zoals we kunnen zien, wordt de betrouwbaarheid van JSON-RPC overschat. Het is inderdaad gemakkelijker om consistentie in de database te organiseren. Maar het offer zal in dit geval de betrouwbaarheid van het systeem als geheel zijn.
De conclusie komt grotendeels overeen met de vorige. Wanneer de infrastructuur eenvoudig is, is de vanzelfsprekendheid van JSON-RPC zeker een pluspunt. Als het project een hoge beschikbaarheid met een hoge belasting met zich meebrengt, lijkt REST een correctere, hoewel complexere oplossing.
De drempel voor REST is lager
Ik denk dat de bovenstaande analyse, die de gevestigde stereotypen over RPC ontkrachtte, duidelijk aantoonde dat de drempel voor deelname aan REST ongetwijfeld hoger is dan voor RPC. Dit komt door de behoefte aan een diepgaand begrip van hoe HTTP werkt, evenals de behoefte aan voldoende kennis over bestaande infrastructuurelementen die kunnen en moeten worden gebruikt in WEB-projecten.
Dus waarom denken veel mensen dat REST eenvoudiger zal zijn? Mijn persoonlijke mening is dat deze schijnbare eenvoud voortkomt uit de REST die zich manifesteert. Die. REST is geen protocol maar een concept... REST heeft geen standaard, er zijn enkele richtlijnen... REST is niet ingewikkelder dan HTTP. Schijnbare vrijheid en anarchie trekken ‘vrije kunstenaars’ aan.
Natuurlijk is REST niet ingewikkelder dan HTTP. Maar HTTP zelf is een goed ontworpen protocol dat zijn waarde al tientallen jaren heeft bewezen. Als er geen diepgaand begrip is van HTTP zelf, kan REST niet worden beoordeeld.
Maar over RPC - dat kan. Het is voldoende om de specificatie ervan te nemen. Dus heb je nodig ? Of is het nog steeds lastig REST? Jij beslist.
Ik hoop oprecht dat ik je tijd niet heb verspild.
Bron: www.habr.com