Jam i sigurt që titulli shkaktoi një reagim të shëndetshëm - "mirë, filloi përsëri ..." Por më lejoni të tërheq vëmendjen tuaj për 5-10 minuta dhe do të përpiqem të mos zhgënjej pritshmëritë tuaja.
Struktura e artikullit do të jetë si më poshtë: merret një deklaratë stereotipike dhe zbulohet "natyra" e shfaqjes së këtij stereotipi. Shpresoj se kjo do t'ju lejojë të shikoni zgjedhjen e paradigmës së shkëmbimit të të dhënave në projektet tuaja nga një kënd i ri.
Për të qenë të qartë se çfarë është RPC, unë propozoj të marrim parasysh standardin . Me REST nuk ka qartësi. Dhe nuk duhet të jetë. Gjithçka që duhet të dini për REST - nuk dallohet nga ajo .
Kërkesat RPC janë më të shpejta dhe më efikase sepse ju lejojnë të bëni kërkesa grupore.
Çështja është se në RPC mund të telefononi disa procedura menjëherë në një kërkesë. Për shembull, krijoni një përdorues, shtoni një avatar tek ai dhe, në të njëjtën kërkesë, abononi atë në disa tema. Vetëm një kërkesë, dhe sa përfitim!
Në të vërtetë, nëse keni vetëm një nyje mbështetëse, do të duket më e shpejtë me një kërkesë grupi. Sepse tre kërkesa REST do të kërkojnë tre herë më shumë burime nga një nyje për të krijuar lidhje.
Vini re se kërkesa e parë në rastin e REST duhet të kthejë ID-në e përdoruesit në mënyrë që të bëhen kërkesat e mëvonshme. E cila gjithashtu ndikon negativisht në rezultatin e përgjithshëm.
Por infrastruktura të tilla mund të gjenden vetëm në zgjidhjet e brendshme dhe në Enterprise. Si mjet i fundit, në projekte të vogla WEB. Por zgjidhjet e plota WEB, madje edhe ato të quajtura HighLoad, nuk ia vlen të ndërtohen. Infrastruktura e tyre duhet të plotësojë kriteret e disponueshmërisë dhe ngarkesës së lartë. Dhe fotografia po ndryshon.
Kanalet e aktivitetit infrastrukturor sipas të njëjtit skenar janë shënuar me të gjelbër. Vini re se si sillet RPC tani. Kërkesa përdor infrastrukturën vetëm në njërën këmbë nga balancuesi në pjesën e pasme. Ndërsa REST ende humbet në kërkesën e parë, ai kompenson kohën e humbur duke përdorur të gjithë infrastrukturën.
Mjafton të futen në skenar jo dy kërkesa për pasurim, por, le të themi, pesë ose dhjetë ... dhe përgjigja e pyetjes "kush fiton tani?" bëhet e paqartë.
Unë propozoj t'i hedhim një vështrim edhe më të gjerë problemit. Diagrami tregon se si përdoren kanalet e infrastrukturës, por infrastruktura nuk kufizohet vetëm në kanale. Një komponent i rëndësishëm i një infrastrukture me ngarkesë të lartë janë cache. Le të marrim tani një lloj objekti të përdoruesit. Në mënyrë të përsëritur. Le të themi 32 herë.
Shihni se si infrastruktura RPC është përmirësuar ndjeshëm për të përmbushur kërkesat e ngarkesës së lartë. Gjë është se REST përdor fuqinë e plotë të protokollit HTTP, ndryshe nga RPC. Në diagramin e mësipërm, kjo fuqi realizohet përmes metodës së kërkesës - GET.
Metodat HTTP, ndër të tjera, kanë strategji të memorizimit. Mund t'i gjeni në dokumentacionin në . Për RPC, përdoren kërkesat POST, të cilat nuk konsiderohen idempotente, domethënë, përsëritjet e përsëritura të të njëjtave kërkesa POST mund të japin rezultate të ndryshme (për shembull, pasi të dërgohet çdo koment, do të shfaqet një kopje tjetër e këtij komenti) ().
Rrjedhimisht, RPC nuk është në gjendje të përdorë në mënyrë efektive cache infrastrukturore. Kjo çon në nevojën për të "importuar" memoriet e softuerit. Diagrami tregon Redis në këtë rol. Memoria e softuerit, nga ana tjetër, kërkon që zhvilluesi të shtojë një shtresë shtesë kodi dhe ndryshime të dukshme në arkitekturë.
Le të numërojmë tani sa kërkesa "lindën" REST dhe RPC në infrastrukturën në shqyrtim?
Kërkesat
inbox
për të mbështetur
në DBMS
në cache të butë (Redis)
TOTALI
Rest
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Krahasuar me skemën e parë, ndryshimi është i habitshëm. Tani përfitimi i REST bëhet i qartë. Por unë sugjeroj të mos ndalemi këtu. Infrastruktura e zhvilluar përfshin një CDN. Shpesh zgjidh edhe çështjen e kundërvënieve të sulmeve DDoS dhe DoS. Ne marrim:
Kjo është ajo ku gjërat bëhen vërtet të këqija për RPC. RPC thjesht nuk është në gjendje të delegojë ngarkesën e punës në një CDN. Ne mund të mbështetemi vetëm në sisteme për të luftuar sulmet.
A është e mundur të mbyllet këtu? Dhe përsëri, jo. Metodat HTTP, siç u përmend më lart, kanë "magjinë" e tyre. Dhe nuk është pa arsye që metoda GET përdoret gjerësisht në internet. Vini re se kjo metodë është në gjendje të aksesojë një pjesë të përmbajtjes, është në gjendje të vendosë kushte që elementët e infrastrukturës mund të interpretojnë përpara se kontrolli të transferohet në kodin tuaj, etj. E gjithë kjo ju lejon të krijoni infrastruktura fleksibël dhe të menaxhueshme që mund të trajtojnë flukse vërtet të mëdha kërkesash. Por në RPC kjo metodë... injorohet.
Pra, pse miti që kërkesat e grupit (RPC) janë më të shpejta është kaq këmbëngulës? Personalisht, më duket se shumica e projekteve thjesht nuk arrijnë një nivel zhvillimi ku REST është në gjendje të tregojë forcën e tij. Për më tepër, në projekte të vogla, ai është më i gatshëm të tregojë dobësitë e tij.
Zgjedhja e REST ose RPC nuk është një zgjedhje e vullnetshme e një individi në një projekt. Kjo zgjedhje duhet të plotësojë kërkesat e projektit. Nëse një projekt është në gjendje të shtrydhë gjithçka që mundet me të vërtetë nga REST, dhe ka vërtet nevojë për të, atëherë REST do të jetë një zgjedhje e shkëlqyer.
Por nëse, për të marrë të gjitha përfitimet e REST, ju duhet të punësoni specialistë devops për projektin për të shkallëzuar shpejt infrastrukturën, administratorë për të menaxhuar infrastrukturën, një arkitekt për të hartuar të gjitha shtresat e shërbimit WEB... dhe projektin , në të njëjtën kohë, shet tre pako margarinë në ditë... Unë do të rrija me RPC, sepse... ky protokoll është më utilitar. Nuk do të kërkojë njohuri të thella se si funksionojnë cache dhe infrastruktura, por do të fokusojë zhvilluesin në thirrje të thjeshta dhe të kuptueshme për procedurat që i nevojiten. Biznesi do të jetë i lumtur.
Kërkesat RPC janë më të besueshme sepse ato mund të ekzekutojnë kërkesat e grupit brenda një transaksioni të vetëm
Kjo veti e RPC është një avantazh i caktuar, sepse Është e lehtë për të mbajtur bazën e të dhënave të qëndrueshme. Por me REST bëhet gjithnjë e më e ndërlikuar. Kërkesat mund të mbërrijnë në mënyrë jokonsistente në nyje të ndryshme mbështetëse.
Ky "disvantazh" i REST është ana tjetër e avantazhit të tij të përshkruar më sipër - aftësia për të përdorur në mënyrë efikase të gjitha burimet e infrastrukturës. Nëse infrastruktura është projektuar keq, dhe aq më tepër nëse arkitektura e projektit dhe databaza në veçanti janë projektuar keq, atëherë kjo është me të vërtetë një dhimbje e madhe.
Por a janë kërkesat e grupit aq të besueshme sa duken? Le të shohim një rast: krijojmë një përdorues, pasurojmë profilin e tij me disa përshkrime dhe i dërgojmë një SMS me një sekret për të përfunduar regjistrimin. Ato. tre thirrje në një kërkesë grupi.
Le të shohim diagramin. Ai paraqet një infrastrukturë me elementë të disponueshmërisë së lartë. Ekzistojnë dy kanale të pavarura komunikimi me porta SMS. Por... çfarë shohim? Kur dërgoni një SMS, ndodh një gabim 503 - shërbimi është përkohësisht i padisponueshëm. Sepse Dërgimi i SMS është i paketuar në një kërkesë grupi, atëherë e gjithë kërkesa duhet të kthehet prapa. Veprimet në DBMS janë anuluar. Klienti merr një gabim.
Prova tjetër është lotaria. Ose kërkesa do të godasë të njëjtën nyje përsëri dhe përsëri do të kthejë një gabim, ose do të jeni me fat dhe do të ekzekutohet. Por gjëja kryesore është që të paktën një herë infrastruktura jonë ka funksionuar më kot. Kishte një ngarkesë, por pa fitim.
Mirë, le të imagjinojmë se jemi sforcuar (!) dhe kemi menduar opsionin kur kërkesa mund të përfundojë pjesërisht me sukses. Dhe ne do të përpiqemi të plotësojmë përsëri pjesën tjetër pas një intervali kohor (Cilën? A vendos pjesa e përparme?). Por shorti mbeti i njëjtë. Kërkesa për të dërguar SMS ka një shans 50/50 që të dështojë përsëri.
Dakord, nga ana e klientit, shërbimi nuk duket aq i besueshëm sa do të donim... po REST?
REST përdor përsëri magjinë e HTTP, por tani me kodet e përgjigjes. Kur ndodh një gabim 503 në portën SMS, backend-i e transmeton këtë gabim te balancuesi. Balancuesi e merr këtë gabim dhe pa ndërprerë lidhjen me klientin, e dërgon kërkesën në një nyje tjetër, e cila e përpunon me sukses kërkesën. Ato. klienti merr rezultatin e pritur dhe infrastruktura konfirmon titullin e saj të lartë "shumë i aksesueshëm". Përdoruesi është i lumtur.
Dhe përsëri kjo nuk është e gjitha. Balancuesi nuk mori vetëm një kod përgjigjeje prej 503. Kur përgjigjeni, sipas standardit, këshillohet që ky kod të jepet me titullin "Riprovo-Pas". Kreu i bën të qartë balancuesit se nuk ia vlen të shqetësohet kjo nyje në këtë rrugë për një kohë të caktuar. Dhe kërkesat e radhës për të dërguar SMS do të dërgohen drejtpërdrejt në një nyje që nuk ka probleme me portën SMS.
Siç mund ta shohim, besueshmëria e JSON-RPC është e mbivlerësuar. Në të vërtetë, është më e lehtë të organizohet konsistenca në bazën e të dhënave. Por sakrifica, në këtë rast, do të jetë besueshmëria e sistemit në tërësi.
Përfundimi është kryesisht i ngjashëm me atë të mëparshëm. Kur infrastruktura është e thjeshtë, qartësia e JSON-RPC është padyshim një plus. Nëse projekti përfshin disponueshmëri të lartë me një ngarkesë të lartë, REST duket si një zgjidhje më korrekte, megjithëse më komplekse.
Pragu i hyrjes në REST është më i ulët
Mendoj se analiza e mësipërme, duke zhbërë stereotipet e krijuara për RPC, tregoi qartë se pragu për hyrje në REST është padyshim më i lartë se në RPC. Kjo është për shkak të nevojës për një kuptim të thellë të mënyrës se si funksionon HTTP, si dhe nevojës për të pasur njohuri të mjaftueshme për elementët ekzistues të infrastrukturës që mund dhe duhet të përdoren në projektet WEB.
Pra, pse shumë njerëz mendojnë se REST do të jetë më i thjeshtë? Mendimi im personal është se kjo thjeshtësi e dukshme vjen nga manifestimet REST. Ato. REST nuk është një protokoll por një koncept... REST nuk ka një standard, ka disa udhëzime... REST nuk është më i komplikuar se HTTP. Liria e dukshme dhe anarkia tërheqin "artistët e lirë".
Sigurisht, REST nuk është më i komplikuar se HTTP. Por HTTP në vetvete është një protokoll i dizajnuar mirë që e ka dëshmuar vlerën e tij gjatë dekadave. Nëse nuk ka kuptim të thellë të vetë HTTP, atëherë REST nuk mund të gjykohet.
Por në lidhje me RPC - mundeni. Mjafton të merret specifikimi i tij. Pra a keni nevojë ? Apo është ende e ndërlikuar REST? Ti vendos.
Unë sinqerisht shpresoj se nuk kam humbur kohën tuaj.
Burimi: www.habr.com