Jam i sigurt që titulli ka shkaktuar një reagim të shëndetshëm — “po përsëri filloi…” Por lejoni që të zgjatë vëmendjen tuaj për 5-10 minuta, dhe do mundohem të mos tradhëtoj pritjet.
Struktura e artikullit do të jetë si në vijim: do të merret një afirmatë stereotipe dhe do të zbulohet “natyra” e lindjes së këtij stereotipi. Shpresoj që kjo t'ju lejojë të shikoni zgjedhjen e paradigmes së shkëmbimit të të dhënave në projektet tuaja nga një këndvështrim të ri.
Për të pasur qartësi mbi atë që është RPC, propozoj të shqyrtojmë standardin . Me REST nuk ka qartësi. Dhe nuk duhet të ketë. Gjithçka që duhet të dini për REST — ai është i padallueshëm nga .
Kërkesat RPC janë më të shpejta dhe më efikase, sepse lejojnë kërkesa batch.
Këtu flitet për faktin se në RPC mund të ekzekutoni një thirrje të shumë procedurave në një kërkesë të vetme. Për shembull, krijoni një përdorues, shtoni një avatar dhe në të njëjtën kërkesë abononi atë në disa tema. Një kërkesë, dhe sa përfitim!
Vërtet, nëse keni vetëm një nod backend, kjo do të duket më e shpejtë gjatë kërkesave batch. Sepse tre kërkesa REST do të kërkonin tre herë më shumë burime nga një nod për vendosjen e lidhjeve.
Vini re se kërkesa e parë në rastin e REST duhet të kthejë identifikuesin e përdoruesit, për të realizuar kërkesat e mëpasshme. Kjo gjithashtu ndikon negativisht në rezultatin e përgjithshëm.
Por këto infrastrukturat mund të hasen, ndoshta, vetëm në zgjidhjet in-house dhe Enterprise. Në rastin më të keq, në projekte të vogla WEB. Por zgjidhjet e plota WEB, madje të quajtura HighLoad, nuk duhet ndërtuar kështu. Infrastrukturat e tyre duhet të përmbushin kriteret e disponueshmërisë dhe ngarkesës së lartë. Dhe pamja ndryshon.
Kanaleve të aktivitetit të infrastrukturës janë theksuar në gjelbër për të njëjtin skenar. Vini re se si sillet tani RPC. Kërkesa përdor infrastrukturen vetëm për një trung nga balancuesi i ngarkesës në backend. Ndërkohë, REST vazhdon të humbë në kërkesën e parë, por e merr prapë të humbur duke përdorur gjithë infrastrukturen.
Mjafton të futni në skenar më shumë se dy kërkesa për pasurimin, për shembull, pesë ose dhjetë… dhe përgjigjja në pyetjen “kush fiton tani?” bëhet e paqartë.
Le ofrojt një shikim më të gjerë mbi problemin. Në diagram është e qartë si përdoren kanalet e infrastrukturës, por infrastruktura nuk kufizohet vetëm në kanale. Një komponent i rëndësishëm i infrastrukturës me ngarkesë të lartë janë cache-t. Tani le të marrim ndonjë artefakt të përdoruesit. Disa herë. Le të themi 32 herë.
Shikoni se sa dukshëm është "përmirësuar" infrastruktura në RPC për të përmbushur kërkesat e ngarkesës së lartë. E gjithë çështja është se REST përdor të gjithë fuqinë e protokollit HTTP, në dallim nga RPC. Në diagramin e dhënë kjo fuqi realizohet përmes metodës së kërkesës - GET.
Metodat HTTP, përveç të tjerave, kanë strategji për caching. Mund të njiheni me to në dokumentacionin në . Për RPC përdoren kërkesa POST, të cilat nuk konsiderohen idempotente, do të thotë që përsëritja e disa kërkesave POST mund të kthejë rezultate të ndryshme (për shembull, pas çdo dërgimi të një komenti do të shfaqet një kopje tjetër e atij komenti) ().
Prandaj, RPC nuk është në gjendje të përdorë efektivisht cache-t infrastrukturorë. Kjo çon në nevojën për të "importuar" cache-softuerike. Në diagram, Redis paraqitet në këtë rol. Cache-i softuerik, nga ana e tij, kërkon nga zhvilluesi një shtresë të re koduese dhe ndryshime të dukshme në arkitekturë.
Tani le të llogarisim se sa kërkesa "ka prodhuar" REST dhe RPC në infrastrukturën në shqyrtim?
Kërkesat
Të ardhshme
në backend
në DBMS
në cache-in softuerik (Redis)
TOTAL
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] në rastin më të mirë (nëse përdoret cache-i lokal) 1 kërkesë (një!), në rastin më të keq 32 kërkesa të ardhshme.
Në krahasim me diagramin e parë, ndryshimi është i dukshëm. Tani bëhet e qartë fitimi i REST. Por le të mos ndalemi këtu. Një infrastrukturë e avancuar përfshin një CDN. Shpesh ajo zgjidh çështjen e përballimit të sulmeve DDoS dhe DoS. Të arrijmë:
Këtu për RPC gjithçka bëhet mjaft tragjike. RPC thjesht nuk është në gjendje të delegojë punën me ngarkesën te CDN. Mbetet të shpresosh vetëm në sistemet për të luftuar sulmet.
A mund të përfundojmë këtu? Po, sërish, jo. Metodat HTTP, siç u përmend më parë, kanë “magjinë” e tyre. Dhe nuk është rastësi që metoda GET është përdorur masivisht në Internet. Vini re se kjo metodë është në gjendje të adresojë pjesë të përmbajtjes, është në gjendje të vendosë kushte që mund të interpretohen nga elementët infrastrukturore para se t'i japin kontrollin kodit tuaj, etj. Të gjitha këto lejojnë krijimin e infrastrukturave fleksibile dhe të menaxhueshme, të cilat janë në gjendje të përballojnë flukse të mëdha kërkesash. Ndërsa në RPC, kjo metodë… injorohet.
Por, pse miti për shpejtësinë e kërkesave batch (RPC) vazhdon të ekzistojë? Personalish mendimi im është se shumica e projekteve thjesht nuk arrijnë të arrijnë atë nivel zhvillimi, kur REST mund të tregojë forcën e tij. Akoma më shumë, në projektet e vogla, ai shpesh tregon dobësitë e tij.
Zgjedhja mezi REST ose RPC është një zgjedhje që nuk ka të bëjë me dëshirat e një individi në projekt. Kjo zgjedhje duhet të përputhet me kërkesat e projektit. Nëse projekti është në gjendje të nxjerrë nga REST gjithçka që ai mundet, dhe kjo është me të vërtetë e nevojshme, atëherë REST do të ishte një zgjedhje e shkëlqyer.
Por nëse për të marrë të gjitha përfitimet e REST, nevojitet të punësohen devops në projekt për të shkallëzuar infrastrukturën në mënyrë operative, administratorë për menaxhimin e infrastrukturës, arkitektë për projektimin e të gjithë shtresave të shërbimit WEB… ndërsa projekti shkon vetëm tre paketa margarini në ditë… unë do të ndalesha te RPC, pasi ky protokoll është më utilitar. Ai nuk do të kërkojë njohuri të thella mbi funksionimin e cache-ve dhe infrastrukturës, por do të përqendrojë zhvilluesin në thirrje të thjeshta dhe të kuptueshme të procedurave që i nevojiten. Biznesi do të jetë i kënaqur.
Kërkesat RPC janë më të sigurta, sepse mund të kryejnë kërkesa batch brenda një transaksioni.
Ky atribut i RPC është padyshim një avantazh, pasi lehtëson mbajtjen e databazës në një gjendje konsistente. Ndërsa me REST, kjo bëhet më e komplikuar. Kërkesat mund të vijnë në mënyrë të pakontrolluar në node të ndryshme të backend.
Ky “disavantazh” i REST është ana e kundërt e avantazhit të saj, siç u përmend më parë — aftësia për të shfrytëzuar në mënyrë efikase të gjitha burimet e infrastrukturës. Nëse infrastruktura është projektuar keq, dhe për më tepër, nëse është projektuar keq ndërtimi i projektit dhe databaza në veçanti, atëherë kjo është një dhimbje e madhe.
Poros t'i besojmë se batch-requests janë aq të besueshme sa duken? Le të shqyrtojmë rastin: krijojmë një përdorues, pasurojmë profilin e tij me një përshkrim dhe dërgojmë një SMS me një kod sekret për të përfunduar regjistrimin. Pra, tre thirrje në një batch-request.
Le të shqyrtojmë diagramin. Në të është paraqitur infrastruktura me elemente të disponueshmërisë së lartë. Ka dy kanale të pavarura komunikimi me gateway-et SMS. Por... çfarë shohim? Kur dërgohet SMS, ndodh një gabim 503 — shërbimi është përkohësisht i paqartë. Duke qenë se dërgimi i SMS-it është i paketuar në një batch-request, të gjithë kërkesa duhet të rikthehet. Veprimet në DB anulohen. Klienti merr një gabim.
Përpjekja e ardhshme — është një lojë fati. Ose kërkesa përsëri do të kalojë në të njëjtin nod dhe përsëri do të kthejë një gabim, ose do të kemi fat dhe do të ekzekutohet. Por gjëja kryesore është se së paku një herë infrastruktura jonë ka punuar për diçka të kotë. Ngarkesa ishte, por përfitimi është zero.
Mirë, le të imagjinojmë që ne kemi menduar (!) një variant, ku kërkesa mund të ekzekutohet me sukses pjesërisht. Ndërsa pjesa tjetër, ne do të tentojmë ta ekzekutojmë përsëri pas një kohe (Cila? E vendos frontend-i?). Por loja e fatit mbetet e njëjtë. Kërkesa për dërgimin e SMS me një probabilitet 50/50 përsëri do dështojë.
Pajtohuni, nga ana e klientit, shërbimi nuk duket aq i besueshëm sa do të dëshironim... e çfarë për REST-in?
REST përsëri përdor "magjinë" e HTTP, por tani me kodet e përgjigjeve. Kur ndodh një gabim 503 në gateway-in e SMS, backend-i e transmeton këtë gabim te balancuesi. Balancuesi, duke marrë këtë gabim dhe pa ndërprerë lidhjen me klientin, e drejton kërkesën në një nod tjetër, e cila e ekzekuton me sukses kërkesën. Pra, klienti merr rezultatin e pritur, ndërsa infrastruktura e konfirmon titullin e saj të lartë "të lartë të disponueshëm". Përdoruesi është i lumtur.
Dhe nuk është gjithçka. Balancuesi nuk thjesht mori kodin e përgjigjes 503. Ky kod, sipas standardit, është e dëshirshe që në përgjigje të shoqërohet me header-in "Retry-After". Header-i tregon balancuesit se nuk duhet ta shqetësojë këtë nod për këtë rrugë për një kohë të caktuar. Dhe kërkesat e ardhshme për dërgimin e SMS do të dërgohen menjëherë te nodi, i cili nuk ka probleme me gateway-in e SMS.
Siç e shohim, besueshmëria e JSON-RPC është e tepruar. Në të vërtetë, është më e lehtë të organizohet koherenca në DB. Por, në këtë rast, do të jetë besueshmëria e sistemit në tërësi që do të dëmtohet.
Shfaqja është shumë e ngjashme me atë të mëparshme. Kur infrastruktura është e thjeshtë, qartësia e JSON-RPC padyshim është një avantazh. Nëse projekti parashikon akses të lartë me ngarkesë të lartë, atëherë REST duket si një zgjidhje më e saktë, megjithëse më komplekse.
Hapi i parë në REST është më i ulët
Mendoj se analiza më sipër, e cila sfidon stereotipat e jetoshëm rreth RPC, e tregon qartë se hapi i parë në REST padyshim është më i lartë se në RPC. Kjo lidhet me nevojën për një kuptim të thellë të funksionimit të HTTP dhe gjithashtu me nevojën për të pasur njohuri të mjaftueshme për elementet infrastrukturore ekzistuese që mund të aplikohen dhe duhen aplikuar në projektet WEB.
Pse mendon shumë njerëz se REST do të jetë më i thjeshtë? Mendimi im personal është se kjo dukuri e dukshme e thjeshtësisë rrjedh nga vetë manifestet e REST. Pra, REST nuk është një protokoll, por një koncept… REST nuk ka standard, ka disa rekomandime… REST nuk është më i komplikuar se HTTP. Dukuria e dukshme e lirisë dhe anarkisë tërheq "artizanët e lirë".
Padyshim, REST nuk është më i komplikuar se HTTP. Por vetë HTTP është një protokoll i menduar mirë, i cili ka provuar që është i besueshëm për dekada. Nëse nuk ka një kuptim të thellë të vetë HTTP, atëherë nuk mund të gjykohet për REST.
Por për RPC – mund të gjykohet. Mjafton të merret specifikimi i tij. A është nevoja për ? Или все же хитрый REST? Решать вам.
Shpresoj sinqerisht se nuk e kam humbur kohën tuaj kot.
Burimi: habr.com
