Ziur nago titularrak erreakzio osasuntsua eragin zuela - "beno, berriro hasi da..." Baina utzi zure arreta harrapatzen 5-10 minutuz, eta zure itxaropenak ez zapuzten saiatuko naiz.
Artikuluaren egitura honakoa izango da: adierazpen estereotipatu bat hartzen da eta estereotipo horren sorreraren βizaeraβ agerian uzten da. Espero dut horrek aukera emango dizula zure proiektuetan datu-trukearen paradigma aukeratzea ikuspegi berri batetik aztertzea.
RPC zer den argi izateko, estandarra kontuan hartzea proposatzen dut . REST-ekin ez dago argitasunik. Eta ez luke izan behar. REST-i buruz jakin behar duzun guztia, ezin da bereizten .
RPC eskaerak azkarragoak eta eraginkorragoak dira, batch eskaerak egiteko aukera ematen baitute.
Kontua da RPCn hainbat prozedura aldi berean dei ditzakezula eskaera batean. Adibidez, sortu erabiltzaile bat, gehitu avatar bat eta, eskaera berean, harpidetu gai batzuetara. Eskaera bakarra, eta zenbat onura!
Izan ere, backend nodo bakarra baduzu, batch eskaera batekin azkarragoa dirudi. Hiru REST eskaerak hiru aldiz baliabide gehiago beharko baitituzte nodo batetik konexioak ezartzeko.
Kontuan izan REST kasuan lehen eskaerak erabiltzailearen IDa itzuli behar duela ondorengo eskaerak egin ahal izateko. Horrek ere negatiboki eragiten dio emaitza orokorrari.
Baina horrelako azpiegiturak barneko soluzioetan eta Enterprisen bakarrik aurki daitezke. Azken aukera gisa, WEB proiektu txikietan. Baina WEB soluzio osoak, eta baita HighLoad izenekoak ere, ez dute eraikitzeko balio. Haien azpiegiturek erabilgarritasun eta karga handiko irizpideak bete behar dituzte. Eta argazkia aldatzen ari da.
Eszenatoki bereko azpiegituren jarduera-kanalak berdez markatuta daude. Kontuan izan RPC nola jokatzen duen orain. Eskaerak azpiegitura hanka bakarrean erabiltzen du orekatzailetik backendera. Lehen eskaeran REST oraindik galtzen den arren, galdutako denbora konpontzen du azpiegitura osoa erabiliz.
Nahikoa da gidoian ez bi aberasteko eskaera sartzea, baizik eta, demagun, bost edo hamar... eta βnork irabazten du orain?β galderaren erantzuna. argi geratzen da.
Arazoari are ikuspegi zabalago bat ematea proposatzen dut. Diagramak azpiegitura-kanalak nola erabiltzen diren erakusten du, baina azpiegitura ez da kanaletara mugatzen. Karga handiko azpiegitura baten osagai garrantzitsu bat cacheak dira. Lor dezagun orain erabiltzailearen artefakturen bat. Behin eta berriz. Demagun 32 aldiz.
Ikusi nola hobetu den RPC azpiegitura nabarmen karga handiko eskaerei erantzuteko. Gauza da REST-ek HTTP protokoloaren botere osoa erabiltzen duela, RPC ez bezala. Goiko diagraman, botere hori eskaera metodoaren bidez gauzatzen da - GET.
HTTP metodoek, besteak beste, caching estrategiak dituzte. Dokumentazioan aurki ditzakezue . RPCrako, POST eskaerak erabiltzen dira, idempotentetzat hartzen ez direnak, hau da, POST eskaera beraren errepikapenek emaitza desberdinak eman ditzakete (adibidez, iruzkin bakoitza bidali ondoren, iruzkin honen beste kopia bat agertuko da) ().
Ondorioz, RPC-k ezin du modu eraginkorrean erabili azpiegitura-cacheak. Horrek software cacheak "inportatu" beharra dakar. Diagramak Redis erakusten du rol honetan. Softwarearen cacheak, berriz, garatzaileak kode-geruza gehigarri bat eta arkitekturan aldaketa nabariak gehitzea eskatzen du.
Konta ditzagun orain zenbat eskaerak βerdituβ dituzten REST eta RPC kontuan hartutako azpiegituran?
Eskaerak
Sarrera-ontzia
backend egiteko
DBMSra
cache bigunera (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Lehenengo eskemarekin alderatuta, aldea nabarmena da. Orain REST-en onura argi geratzen da. Baina hor ez gelditzea proposatzen dut. Garatutako azpiegiturak CDN bat dauka. Askotan DDoS eta DoS erasoei aurre egiteko arazoa ere konpontzen du. Lortzen dugu:
Hemen gauzak oso txarrak dira RPCrentzat. RPC ez da gai lan-karga CDN bati delegatzeko. Erasoei aurre egiteko sistemetan soilik fidatu gaitezke.
Posible al da hemen amaitzea? Eta berriro, ez. HTTP metodoek, goian aipatu bezala, bere "magia" dute. Eta ez da arrazoirik gabe GET metodoa oso erabilia Interneten. Kontuan izan metodo hau eduki bat atzitzeko gai dela, azpiegitura elementuek interpretatu ditzaketen baldintzak ezar ditzakeela kontrola zure kodeara transferitu aurretik, etab. Horri guztiari esker, eskaera-fluxu benetan handiak kudeatu ditzaketen azpiegitura malguak eta kudeagarriak sortzeko aukera ematen du. Baina RPCn metodo hau... ez da aintzat hartzen.
Beraz, zergatik da hain iraunkorra batch eskaerak (RPC) azkarragoak direla dioen mitoa? Pertsonalki, iruditzen zait proiektu gehienek ez dutela REST bere indarra erakusteko gai den garapen maila batera iristen. Gainera, proiektu txikietan, bere ahuleziak erakusteko gogo handiagoa du.
REST edo RPC aukeratzea ez da proiektu bateko pertsona baten borondatezko aukera. Aukera honek proiektuaren baldintzak bete behar ditu. Proiektu bat REST-tik benetan ahal duen guztia ateratzeko gai bada eta benetan behar badu, REST aukera bikaina izango da.
Baina, REST-en onura guztiak lortzeko, proiekturako devops espezialistak kontratatu behar badituzu, azpiegitura azkar eskalatzeko, administratzaileak azpiegitura kudeatzeko, arkitekto bat WEB zerbitzuaren geruza guztiak diseinatzeko... eta proiektua. , aldi berean, egunean hiru pakete margarina saltzen ditu... Nik RPCrekin jarraituko nuke, zeren... protokolo hau erabilgarriagoa da. Ez du ezagutza sakonik beharko cache-ak eta azpiegiturak nola funtzionatzen duten, baina behar dituen prozeduretara dei erraz eta ulergarrietara bideratuko du garatzailea. Negozioak pozik egongo dira.
RPC eskaerak fidagarriagoak dira, lote-eskaerak transakzio bakar batean exekutatu ditzaketelako
RPCren propietate hau abantaila zehatza da, zeren Erraza da datu-basea koherentea mantentzea. Baina RESTarekin gero eta konplikatuagoa da. Baliteke eskaerak koherentziarik gabe iristea backend nodo desberdinetara.
REST-en "desabantaila" hau goian deskribatutako abantailaren alde bat da: azpiegitura baliabide guztiak eraginkortasunez erabiltzeko gaitasuna. Azpiegitura gaizki diseinatuta badago, eta are gehiago proiektuaren arkitektura eta datu-basea bereziki gaizki diseinatuta badaude, orduan min handia da hori.
Baina loteen eskaerak diruditen bezain fidagarriak al dira? Ikus dezagun kasu bat: erabiltzaile bat sortzen dugu, bere profila deskribapen batekin aberasten dugu eta sekretu batekin SMS bat bidaltzen diogu erregistroa osatzeko. Horiek. hiru dei eskaera sorta batean.
Ikus dezagun diagrama. Eskuragarritasun handiko elementuak dituen azpiegitura bat aurkezten du. Bi komunikazio-kanal independente daude SMS pasabideekin. Baina... zer ikusten dugu? SMS bat bidaltzean, 503 errore bat gertatzen da - zerbitzua ez dago aldi baterako erabilgarri. Zeren SMSak bidaltzea lote-eskaera batean biltzen da, ondoren eskaera osoa atzera egin behar da. DBMSko ekintzak bertan behera uzten dira. Bezeroak errore bat jasotzen du.
Hurrengo saiakera loteria da. Edo eskaerak nodo berean joko du behin eta berriz errore bat itzuliko du, edo zortea izango duzu eta exekutatu egingo da. Baina gauza nagusia da behinik behin gure azpiegiturak dagoeneko alferrik funtzionatu duela. Karga bat zegoen, baina irabazirik ez.
Ados, pentsa dezagun esfortzua egin dugula (!) eta aukeran pentsatu dugula eskaera partzialki arrakastaz bete daitekeenean. Eta denbora tarte baten ondoren gainerakoak berriro osatzen saiatuko gara (Zein? Fronteak erabakitzen al du?). Baina loteria berdin jarraitu zuen. SMSak bidaltzeko eskaerak 50/50eko aukera du berriro huts egiteko.
Ados, bezeroaren aldetik, zerbitzuak ez dirudi nahiko genukeen bezain fidagarria... zer gertatzen da REST?
REST-ek HTTPren magia erabiltzen du berriro, baina orain erantzun-kodeekin. SMS atebidean 503 errore bat gertatzen denean, backend-ak errore hori igortzen dio orekatzaileari. Balantzaileak errore hau jasotzen du eta bezeroarekin konexioa eten gabe, eskaera beste nodo batera bidaltzen du, eta horrek eskaera behar bezala prozesatzen du. Horiek. bezeroak espero den emaitza jasotzen du, eta azpiegiturak βoso irisgarriaβ duen titulu handia berresten du. Erabiltzailea pozik dago.
Eta berriro ere ez da hori guztia. Balantzaileak ez zuen 503ko erantzun-kodea besterik jaso. Erantzutean, estandarraren arabera, komeni da kode hori "Berri saiatu-Ondoren" goiburuarekin ematea. Goiburuak argi uzten dio orekatzaileari ez duela merezi ibilbide honetako nodo hau denbora zehatz batean asaldatzeak. Eta SMSak bidaltzeko hurrengo eskaerak SMS atebidearekin arazorik ez duen nodo batera bidaliko dira zuzenean.
Ikus dezakegunez, JSON-RPC-ren fidagarritasuna gainbaloratua dago. Izan ere, errazagoa da datu-basean koherentzia antolatzea. Baina sakrifizioa, kasu honetan, sistema osoaren fidagarritasuna izango da.
Ondorioa aurrekoaren antzekoa da neurri handi batean. Azpiegitura sinplea denean, JSON-RPC-ren agerikoa abantaila da zalantzarik gabe. Proiektuak karga handiko erabilgarritasun handia badakar, REST irtenbide zuzenagoa dirudi, nahiz eta konplexuagoa den.
RESTrako sarrera atalasea txikiagoa da
Uste dut goiko analisiak, RPCri buruz ezarritako estereotipoak gaitzetsiz, argi eta garbi erakutsi zuela REST-en sartzeko atalasea RPCn baino handiagoa dela, zalantzarik gabe. Hau HTTP nola funtzionatzen duen sakon ulertzeko beharra dagoelako da, baita WEB proiektuetan erabili daitezkeen eta erabili behar diren dauden azpiegitura-elementuei buruzko ezagutza nahikoa eduki beharra ere.
Beraz, zergatik uste du jende askok REST sinpleagoa izango dela? Nire iritzi pertsonala da itxurazko sinpletasun hori REST manifestuetatik datorrela. Horiek. REST ez da protokolo bat, kontzeptu bat baizik... REST ez du estandarrik, jarraibide batzuk daude... REST ez da HTTP baino konplikatuagoa. Itxurazko askatasunak eta anarkiak βartista libreakβ erakartzen dituzte.
Jakina, REST ez da HTTP baino konplexuagoa. Baina HTTP bera ondo diseinatutako protokoloa da, hamarkadatan zehar bere balioa frogatu duena. HTTP berari buruzko ulermen sakonik ez badago, REST ezin da epaitu.
Baina RPCri buruz - dezakezu. Nahikoa da bere zehaztapena hartzea. Beraz, behar duzu ? Edo oraindik zaila da ATSEDENERA? Zuk erabaki.
Zinez espero dut zure denbora ez galdu izana.
Iturria: www.habr.com