Ik bin der wis fan dat de kop in sûne reaksje feroarsake - "goed, it is opnij begon ..." Mar lit my jo oandacht foar 5-10 minuten fange, en ik sil besykje jo ferwachtingen net teloar te meitsjen.
De struktuer fan it artikel sil as folgjend wêze: in stereotypyske ferklearring wurdt nommen en de "aard" fan it ûntstean fan dit stereotype wurdt iepenbiere. Ik hoopje dat dit sil tastean jo te sjen nei de kar fan gegevens útwikseling paradigma yn jo projekten út in nije hoeke.
Om dúdlik te wêzen oer wat RPC is, stel ik foar om de standert te beskôgjen . Mei REST is der gjin dúdlikens. En it moat net. Alles wat jo witte moatte oer REST - it is net te ûnderskieden fan .
RPC-oanfragen binne rapper en effisjinter, om't se jo batchfersiken kinne meitsje.
It punt is dat yn RPC kinne jo belje ferskate prosedueres tagelyk yn ien fersyk. Meitsje bygelyks in brûker, foegje in avatar ta oan him en, yn itselde fersyk, abonnemint him op guon ûnderwerpen. Krekt ien fersyk, en hoefolle foardiel!
Yndied, as jo mar ien backend node hawwe, sil it rapper lykje mei in batchfersyk. Om't trije REST-oanfragen trije kear mear boarnen fan ien knooppunt sille fereaskje om ferbiningen te meitsjen.
Tink derom dat it earste fersyk yn it gefal fan REST de brûkers-ID moat weromjaan om folgjende oanfragen te meitsjen. Wat ek negatyf beynfloedet op it totale resultaat.
Mar sokke ynfrastruktuer kin allinnich fûn wurde yn eigen oplossings en Enterprise. As lêste ynstânsje, yn lytse WEB-projekten. Mar folweardige WEB-oplossingen, en sels dyjingen neamd HighLoad, binne net wurdich te bouwen. Har ynfrastruktuer moat foldwaan oan de kritearia fan hege beskikberens en lading. En it byld feroaret.
Ynfrastruktueraktiviteitskanalen ûnder itselde senario binne grien markearre. Merk op hoe't RPC no gedraacht. It fersyk brûkt de ynfrastruktuer op mar ien skonk fan 'e balancer nei de efterkant. Wylst REST noch ferliest yn it earste fersyk, makket it de ferlerne tiid goed mei de heule ynfrastruktuer.
It is genôch om yn it skript net twa oanfragen foar ferriking yn te fieren, mar, sizze, fiif of tsien ... en it antwurd op 'e fraach "wa wint no?" wurdt ûndúdlik.
Ik stel foar om it probleem noch breder te sjen. It diagram lit sjen hoe't ynfrastruktuer kanalen wurde brûkt, mar ynfrastruktuer is net beheind ta kanalen. In wichtich ûnderdiel fan in ynfrastruktuer mei hege lading is caches. Litte wy no in soarte fan brûkersartefakt krije. Herhalend. Litte wy sizze 32 kear.
Sjoch hoe't de RPC-ynfrastruktuer signifikant is ferbettere om te foldwaan oan 'e easken fan hege lading. It ding is dat REST de folsleine krêft fan it HTTP-protokol brûkt, yn tsjinstelling ta RPC. Yn it boppesteande diagram wurdt dizze krêft realisearre troch de oanfraachmetoade - GET.
HTTP-metoaden hawwe ûnder oare cachingstrategyen. Jo kinne se fine yn 'e dokumintaasje op . Foar RPC wurde POST-oanfragen brûkt, dy't net as idempotint wurde beskôge, dat wol sizze, werhelle werhellingen fan deselde POST-oanfragen kinne ferskate resultaten weromjaan (bygelyks neidat elke opmerking is ferstjoerd, sil in oare kopy fan dizze opmerking ferskine) ().
Dêrtroch is RPC net yn steat om ynfrastruktuer-caches effektyf te brûken. Dit liedt ta de needsaak om software-caches te "ymportearjen". It diagram lit Redis yn dizze rol sjen. De software-cache fereasket op syn beurt de ûntwikkelder om in ekstra laach koade en merkbere feroaringen yn 'e arsjitektuer ta te foegjen.
Litte wy no telle hoefolle oanfragen REST en RPC "berne" hawwe yn 'e ynfrastruktuer dy't beskôge wurdt?
Fersiken
Postfak
oan backend
oan DBMS
nei sêfte cache (Redis)
TOTAL
RÊST
1 / 32 *
1
1
0
3 / 35
CPR
32
32
1
31
96
Yn ferliking mei it earste skema is it ferskil opfallend. No wurdt it foardiel fan REST dúdlik. Mar ik stel foar net stopje dêr. De ûntwikkele ynfrastruktuer omfettet in CDN. Faak lost it ek it probleem op fan it tsjingean fan DDoS- en DoS-oanfallen. Wy krije:
Dit is wêr't dingen echt min wurde foar RPC. RPC is gewoan net yn steat om de wurkdruk nei in CDN te delegearjen. Wy kinne allinich fertrouwe op systemen om oanfallen tsjin te gean.
Is it mooglik om hjir te einigjen? En wer, nee. HTTP-metoaden, lykas hjirboppe neamd, hawwe har eigen "magy". En it is net sûnder reden dat de GET-metoade in soad brûkt wurdt op it ynternet. Tink derom dat dizze metoade tagong hat ta in stik ynhâld, by steat is om betingsten yn te stellen dy't ynfrastruktuer-eleminten kinne ynterpretearje foardat kontrôle wurdt oerdroegen oan jo koade, ensfh. Dit alles lit jo fleksibele, behearbere ynfrastruktuer meitsje dy't echt grutte streamen fan oanfragen kinne omgean. Mar yn RPC dizze metoade ... wurdt negearre.
Dus wêrom is de myte dat batch-oanfragen (RPC) rapper binne sa persistint? Persoanlik liket it my dat de measte projekten gewoan net in nivo fan ûntwikkeling berikke wêr't REST syn krêft kin sjen litte. Boppedat, yn lytse projekten, hy is mear ree om te sjen litte syn swakkens.
De kar fan REST of RPC is gjin frijwillige kar fan in yndividu yn in projekt. Dizze kar moat foldwaan oan de easken fan it projekt. As in projekt yn steat is om alles wat it wirklik kin út REST te squeeze, en it hat it wirklik nedich, dan sil REST in poerbêste kar wêze.
Mar as jo, om alle foardielen fan REST te krijen, devops-spesjalisten moatte ynhiere foar it projekt om de ynfrastruktuer fluch te skaaljen, behearders om de ynfrastruktuer te behearjen, in arsjitekt om alle lagen fan 'e WEB-tsjinst te ûntwerpen ... en it projekt , tagelyk, ferkeapet trije pakjes margarine deis ... Ik soe hâld mei RPC, omdat ... dit protokol is mear utilitaristyske. It sil gjin djippe kennis fereaskje hoe't caches en ynfrastruktuer wurkje, mar sil de ûntwikkelder rjochtsje op ienfâldige en begryplike oproppen nei de prosedueres dy't hy nedich is. Bedriuw sil bliid wêze.
RPC-oanfragen binne betrouberer, om't se batch-oanfragen kinne útfiere binnen ien transaksje
Dit eigendom fan RPC is in definityf foardiel, omdat It is maklik om de databank konsekwint te hâlden. Mar mei REST wurdt it hieltyd yngewikkelder. Fersiken kinne ynkonsekwint oankomme nei ferskate backend-knooppunten.
Dit "neideel" fan REST is de kearside fan it hjirboppe beskreaune foardiel - de mooglikheid om alle ynfrastruktuerboarnen effisjint te brûken. As de ynfrastruktuer min ûntwurpen is, en noch mear as de arsjitektuer fan it projekt en de databank yn it bysûnder min binne ûntwurpen, dan is dit echt in grutte pine.
Mar binne batch-oanfragen sa betrouber as se lykje? Litte wy nei in saak sjen: wy meitsje in brûker, ferrykje syn profyl mei wat beskriuwing en stjoere him in sms mei in geheim om registraasje te foltôgjen. Dy. trije oproppen yn ien batch fersyk.
Litte wy nei it diagram sjen. It presintearret in ynfrastruktuer mei eleminten mei hege beskikberens. D'r binne twa ûnôfhinklike kommunikaasjekanalen mei SMS-gateways. Mar... wat sjogge wy? By it ferstjoeren fan in SMS komt in flater 503 foar - de tsjinst is tydlik net beskikber. Omdat SMS-ferstjoeren wurdt ferpakt yn in batchfersyk, dan moat it folsleine fersyk weromdraaid wurde. Aksjes yn 'e DBMS wurde annulearre. De klant krijt in flater.
De folgjende poging is de lotterij. Of it fersyk sil reitsje deselde knooppunt wer en wer in flater, of do silst wêze gelok en it sil wurde útfierd. Mar it wichtichste ding is dat op syn minst ien kear ús ynfrastruktuer hat al wurke om 'e nocht. Der wie in lading, mar gjin winst.
Okee, lit ús yntinke dat wy ússels ynspannen (!) en trochtocht hawwe oer de opsje wannear't it fersyk foar in part mei súkses foltôge wurde kin. En wy sille besykje te foltôgjen de rest wer nei wat tiid ynterfal (Hokker ien? Beslút de foarkant?). Mar de lotting bleau itselde. It fersyk om SMS te ferstjoeren hat in 50/50 kâns om wer te mislearjen.
Iens, fan 'e kant fan' e kliïnt liket de tsjinst net sa betrouber as wy wolle ... hoe sit it mei REST?
REST brûkt de magy fan HTTP wer, mar no mei antwurdkoades. As in flater 503 optreedt op 'e SMS-gateway, stjoert de backend dizze flater út nei de balancer. De balancer ûntfangt dizze flater en sûnder de ferbining mei de kliïnt te brekken, stjoert it fersyk nei in oare knooppunt, dy't it fersyk mei súkses ferwurket. Dy. de klant krijt it ferwachte resultaat, en de ynfrastruktuer befêstiget syn hege titel fan "heech tagonklik". De brûker is bliid.
En wer dat is net alles. De balancer krige net allinich in antwurdkoade fan 503. By it reagearjen, neffens de standert, is it oan te rieden om dizze koade te foarsjen mei de koptekst "Retry-After". De koptekst makket de balancer dúdlik dat it net wurdich is om dizze knooppunt op dizze rûte foar in bepaalde tiid te fersteuren. En de folgjende fersiken om SMS te ferstjoeren wurde direkt stjoerd nei in knooppunt dat gjin problemen hat mei de SMS-gateway.
As wy kinne sjen, is de betrouberens fan JSON-RPC oerskatte. Yndied is it makliker om konsistinsje yn 'e database te organisearjen. Mar it offer, yn dit gefal, sil wêze de betrouberens fan it systeem as gehiel.
De konklúzje is foar in grut part gelyk oan de foarige. As de ynfrastruktuer ienfâldich is, is de fanselssprekkend fan JSON-RPC perfoarst in plus. As it projekt in hege beskikberens mei in hege lading omfettet, liket REST in krekter, hoewol komplekser, oplossing.
Yngongsdrompel foar REST is leger
Ik tink dat de boppesteande analyze, debunking fan de fêststelde stereotypen oer RPC, dúdlik toande dat de drompel foar yngong yn REST is sûnder mis heger as yn RPC. Dit komt troch de needsaak foar in djip begryp fan hoe't HTTP wurket, en ek de needsaak om genôch kennis te hawwen oer besteande ynfrastruktuer-eleminten dy't kinne en moatte wurde brûkt yn WEB-projekten.
Dus wêrom tinke in protte minsken dat REST ienfâldiger sil wêze? Myn persoanlike miening is dat dizze skynbere ienfâld komt fan 'e REST manifestearret harsels. Dy. REST is gjin protokol mar in konsept... REST hat gjin standert, der binne guon rjochtlinen... REST is net komplisearre as HTTP. Blykbere frijheid en anargy lûke "frije keunstners".
Fansels is REST net komplisearre as HTTP. Mar HTTP sels is in goed ûntworpen protokol dat syn wearde hat bewiisd oer desennia. As d'r gjin djip begryp is fan HTTP sels, dan kin REST net beoardiele wurde.
Mar oer RPC - jo kinne. It is genôch om syn spesifikaasje te nimmen. Sa hawwe jo nedich ? Of is it noch lestich REST? Do beslútst.
Ik hoopje fan herten dat ik jo tiid net fergriemd haw.
Boarne: www.habr.com