Ek is seker dat die opskrif 'n gesonde reaksie veroorsaak het - "wel, dit het weer begin ..." Maar laat ek jou aandag vir 5-10 minute vang, en ek sal probeer om nie jou verwagtinge teleur te stel nie.
Die struktuur van die artikel sal soos volg wees: 'n stereotipiese stelling word geneem en die "aard" van die ontstaan van hierdie stereotipe word onthul. Ek hoop dit sal jou in staat stel om vanuit 'n nuwe hoek na die keuse van data-uitruilparadigma in jou projekte te kyk.
Om duidelik te wees oor wat RPC is, stel ek voor om die standaard te oorweeg . Met RUS is daar geen duidelikheid nie. En dit behoort nie te wees nie. Alles wat jy moet weet oor RUS - dit is nie te onderskei van .
RPC-versoeke is vinniger en doeltreffender omdat dit jou toelaat om bondelversoeke te maak.
Die punt is dat jy in RPC verskeie prosedures gelyktydig in een versoek kan oproep. Skep byvoorbeeld 'n gebruiker, voeg 'n avatar by hom en teken hom in dieselfde versoek op sommige onderwerpe in. Net een versoek, en hoeveel voordeel!
Inderdaad, as jy net een backend nodus het, sal dit vinniger lyk met 'n bondelversoek. Omdat drie REST-versoeke drie keer meer hulpbronne van een nodus sal vereis om verbindings te vestig.
Let daarop dat die eerste versoek in die geval van REST die gebruiker-ID moet terugstuur sodat daaropvolgende versoeke gemaak kan word. Wat ook die algehele resultaat negatief beïnvloed.
Maar sulke infrastruktuur kan slegs gevind word in interne oplossings en Enterprise. As 'n laaste uitweg, in klein WEB-projekte. Maar volwaardige WEB-oplossings, en selfs dié wat HighLoad genoem word, is nie die moeite werd om te bou nie. Hul infrastruktuur moet aan die kriteria van hoë beskikbaarheid en vrag voldoen. En die prentjie is besig om te verander.
Infrastruktuuraktiwiteitskanale onder dieselfde scenario is in groen gemerk. Let op hoe RPC nou optree. Die versoek gebruik die infrastruktuur op slegs een been van die balanseerder na die agterkant. Terwyl REST steeds verloor in die eerste versoek, maak dit op vir verlore tyd deur die hele infrastruktuur te gebruik.
Dit is genoeg om nie twee versoeke vir verryking in die skrif in te voer nie, maar, sê, vyf of tien ... en die antwoord op die vraag "wie wen nou?" word onduidelik.
Ek stel voor om nog breër na die probleem te kyk. Die diagram wys hoe infrastruktuurkanale gebruik word, maar infrastruktuur is nie beperk tot kanale nie. 'n Belangrike komponent van 'n hoë-lading infrastruktuur is kas. Kom ons kry nou 'n soort gebruiker artefak. Herhaaldelik. Kom ons sê 32 keer.
Kyk hoe die RPC-infrastruktuur aansienlik verbeter het om aan die eise van hoë las te voldoen. Die ding is dat REST die volle krag van die HTTP-protokol gebruik, anders as RPC. In die diagram hierbo word hierdie krag gerealiseer deur die versoekmetode - GET.
HTTP-metodes het onder meer kasstrategieë. U kan hulle in die dokumentasie vind by . Vir RPC word POST-versoeke gebruik, wat nie as idempotent beskou word nie, dit wil sê herhaalde herhalings van dieselfde POST-versoeke kan verskillende resultate lewer (byvoorbeeld, nadat elke kommentaar gestuur is, sal 'n ander kopie van hierdie opmerking verskyn) ().
Gevolglik is RPC nie in staat om infrastruktuurkas doeltreffend te gebruik nie. Dit lei tot die behoefte om sagteware-kas te "invoer". Die diagram wys Redis in hierdie rol. Die sagteware-kas, op sy beurt, vereis dat die ontwikkelaar 'n bykomende laag kode en merkbare veranderinge in die argitektuur byvoeg.
Kom ons tel nou hoeveel versoeke REST en RPC “gebaar” het in die infrastruktuur wat oorweeg word?
Versoeke
posbus
te backend
na die DBMS
na sagte kas (Redis)
TOTAAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
In vergelyking met die eerste skema is die verskil opvallend. Nou word die voordeel van RUS duidelik. Maar ek stel voor om nie daar te stop nie. Die ontwikkelde infrastruktuur sluit 'n CDN in. Dikwels los dit ook die kwessie op om DDoS- en DoS-aanvalle teë te werk. Ons kry:
Dit is waar dinge regtig sleg raak vir RPC. RPC is eenvoudig nie in staat om die werklading na 'n CDN te delegeer nie. Ons kan net op stelsels staatmaak om aanvalle teë te werk.
Is dit moontlik om hier te eindig? En weer, nee. HTTP-metodes, soos hierbo genoem, het hul eie "magie". En dit is nie sonder rede dat die GET-metode wyd op die internet gebruik word nie. Let daarop dat hierdie metode toegang tot 'n stuk inhoud het, voorwaardes kan stel wat infrastruktuurelemente kan interpreteer voordat beheer na jou kode oorgedra word, ensovoorts. Dit alles laat jou toe om buigsame, hanteerbare infrastruktuur te skep wat werklik groot vloei van versoeke kan hanteer. Maar in RPC word hierdie metode ... geïgnoreer.
So hoekom is die mite dat bondelversoeke (RPC) vinniger is so aanhoudend? Persoonlik lyk dit vir my dat die meeste projekte eenvoudig nie 'n vlak van ontwikkeling bereik waar REST sy krag kan wys nie. Boonop is hy in klein projekte meer gewillig om sy swakhede te wys.
Die keuse van REST of RPC is nie 'n vrywillige keuse van 'n individu in 'n projek nie. Hierdie keuse moet aan die vereistes van die projek voldoen. As 'n projek in staat is om alles wat dit regtig kan uit RUS te druk, en dit regtig nodig het, dan sal REST 'n uitstekende keuse wees.
Maar as jy, om al die voordele van REST te kry, devops-spesialiste vir die projek moet aanstel om die infrastruktuur vinnig te skaal, administrateurs om die infrastruktuur te bestuur, 'n argitek om alle lae van die WEB-diens te ontwerp ... en die projek , verkoop terselfdertyd drie pakke margarien per dag... Ek sal by RPC bly, want... hierdie protokol is meer utilitarist. Dit sal nie diepgaande kennis van hoe kas en infrastruktuur werk vereis nie, maar sal die ontwikkelaar fokus op eenvoudige en verstaanbare oproepe na die prosedures wat hy nodig het. Besigheid sal gelukkig wees.
RPC-versoeke is meer betroubaar omdat dit bondelversoeke binne 'n enkele transaksie kan uitvoer
Hierdie eienskap van RPC is 'n besliste voordeel, want Dit is maklik om die databasis konsekwent te hou. Maar met RUS raak dit al hoe meer ingewikkeld. Versoeke kan inkonsekwent na verskillende backend nodusse aankom.
Hierdie "nadeel" van REST is die keersy van die voordeel wat hierbo beskryf is - die vermoë om alle infrastruktuurhulpbronne doeltreffend te gebruik. As die infrastruktuur swak ontwerp is, en nog meer as die argitektuur van die projek en die databasis in die besonder swak ontwerp is, dan is dit regtig 'n groot pyn.
Maar is bondelversoeke so betroubaar as wat dit lyk? Kom ons kyk na 'n saak: ons skep 'n gebruiker, verryk sy profiel met 'n beskrywing en stuur vir hom 'n SMS met 'n geheim om registrasie te voltooi. Dié. drie oproepe in een bondel versoek.
Kom ons kyk na die diagram. Dit bied 'n infrastruktuur met hoë beskikbaarheid elemente. Daar is twee onafhanklike kommunikasiekanale met SMS-poorte. Maar ... wat sien ons? Wanneer 'n SMS gestuur word, vind 'n fout 503 plaas - die diens is tydelik onbeskikbaar. Omdat SMS-versending word in 'n bondelversoek verpak, dan moet die hele versoek teruggerol word. Aksies in die DBBS word gekanselleer. Die kliënt ontvang 'n fout.
Die volgende probeerslag is die lotery. Óf die versoek sal dieselfde nodus keer op keer 'n fout terugstuur, óf jy sal gelukkig wees en dit sal uitgevoer word. Maar die belangrikste ding is dat ons infrastruktuur ten minste een keer tevergeefs gewerk het. Daar was 'n vrag, maar geen wins nie.
Goed, kom ons verbeel ons dat ons onsself gespanne het (!) en die opsie deurdink het wanneer die versoek gedeeltelik suksesvol afgehandel kan word. En ons sal probeer om die res weer na 'n tydsinterval te voltooi (Watter een? Besluit die voorkant?). Maar die lotery het dieselfde gebly. Die versoek om SMS te stuur het 'n 50/50 kans om weer te misluk.
Stem saam, van die kliënt se kant af lyk die diens nie so betroubaar as wat ons sou wou hê nie... wat van RUS?
REST gebruik weer die magie van HTTP, maar nou met reaksiekodes. Wanneer 'n fout 503 op die SMS-poort voorkom, saai die agterkant hierdie fout na die balanseerder uit. Die balanseerder ontvang hierdie fout en sonder om die verbinding met die kliënt te verbreek, stuur die versoek na 'n ander nodus, wat die versoek suksesvol verwerk. Dié. die kliënt ontvang die verwagte resultaat, en die infrastruktuur bevestig sy hoë titel van “hoogs toeganklik”. Die gebruiker is gelukkig.
En weereens is dit nie al nie. Die balanseerder het nie net 'n reaksiekode van 503 ontvang nie. Wanneer daar geantwoord word, is dit volgens die standaard raadsaam om hierdie kode met die "Retry-After"-opskrif te verskaf. Die kopskrif maak dit duidelik aan die balanseerder dat dit nie die moeite werd is om hierdie nodus op hierdie roete vir 'n bepaalde tyd te versteur nie. En die volgende versoeke om SMS te stuur, sal direk na 'n nodus gestuur word wat geen probleme met die SMS-poort het nie.
Soos ons kan sien, is die betroubaarheid van JSON-RPC oorskat. Dit is inderdaad makliker om konsekwentheid in die databasis te organiseer. Maar die opoffering, in hierdie geval, sal die betroubaarheid van die stelsel as geheel wees.
Die gevolgtrekking stem grootliks ooreen met die vorige een. As die infrastruktuur eenvoudig is, is die duidelikheid van JSON-RPC beslis 'n pluspunt. As die projek hoë beskikbaarheid met 'n hoë las behels, lyk REST na 'n meer korrekte, hoewel meer komplekse, oplossing.
Toegangsdrempel tot REST is laer
Ek dink dat die bogenoemde analise, wat die gevestigde stereotipes oor RPC ontken het, duidelik getoon het dat die drempel vir toetrede tot REST ongetwyfeld hoër is as in RPC. Dit is as gevolg van die behoefte aan 'n diepgaande begrip van hoe HTTP werk, sowel as die behoefte om voldoende kennis te hê oor bestaande infrastruktuurelemente wat in WEB-projekte gebruik kan en behoort te word.
So hoekom dink baie mense dat RUS eenvoudiger sal wees? My persoonlike opinie is dat hierdie oënskynlike eenvoud afkomstig is van die RUS manifesteer hulself. Dié. REST is nie 'n protokol nie maar 'n konsep... REST het nie 'n standaard nie, daar is 'n paar riglyne... REST is nie meer ingewikkeld as HTTP nie. Skynbare vryheid en anargie lok “vrye kunstenaars”.
REST is natuurlik nie meer ingewikkeld as HTTP nie. Maar HTTP self is 'n goed ontwerpte protokol wat sy waarde oor dekades bewys het. As daar geen diepgaande begrip van HTTP self is nie, kan RUS nie beoordeel word nie.
Maar oor RPC - jy kan. Dit is genoeg om sy spesifikasie te neem. So het jy nodig ? Of is dit nog steeds moeilik RUS? Jy besluit.
Ek hoop van harte dat ek nie jou tyd gemors het nie.
Bron: will.com