Jam e sigurtë që titulli shkaktoi një reagim të shëndetshëm - “po filloi përsëri...” Por lejoni të përfitoj nga vëmendja juaj për 5-10 minuta, dhe do mundohem të mos zhgënjej pritshmëritë.
Struktura e artikullit do të jetë kështu: merret një pohim stereotipik dhe zbulon “natyrën” e shfaqjes së këtij stereotipi. Shpresoj se kjo do të lejojë një perspektivë të re mbi zgjedhjen e paradigmes së shkëmbimit të të dhënave në projektet tuaja.
Për të qenë e qartë se çfarë është RPC, propozoj të shqyrtojmë standardin . Me REST nuk ka qartësi. Dhe nuk duhet të ketë. E gjithë çfarë duhet të dini për REST - ai është i pandashëm nga .
Kërkesat RPC janë më të shpejta dhe më efikase, sepse lejojnë të bëhen kërkesa grupore.
Bëhet fjalë për faktin se në RPC mund të thirren menjëherë disa procedura me një kërkesë. Për shembull, të krijoni një përdorues, të shtoni një avatar dhe në të njëjtën kërkesë ta regjistroni në disa tema. Një kërkesë e vetme, por sa dobi!
Në të vërtetë, nëse keni vetëm një nodë backend, do të duket më e shpejtë në kërkesat grupore. Sepse tre kërkesa REST do të kërkojnë tri herë më shumë burime nga një nodë për të vendosur lidhjet.
Kujdes, kërkesa e parë në rastin e REST duhet të kthejë identifikuesin e përdoruesit, për të kryer kërkesat e mëpasshme. Kjo gjithashtu ndikon negativisht në rezultatin e përgjithshëm.
Por struktura të tilla mund të hasen, ndoshta, vetëm në zgjidhjet in-house dhe Enterprise. Në raste ekstreme, në projektet e vogla WEB. Megjithatë, zgjidhjet e plota WEB, sidomos ato të quajtura HighLoad, nuk duhet të ndërtohen kështu. Infrastruktura e tyre duhet të përmbushë kriteret e disponueshmërisë së lartë dhe ngarkesës. Dhe situata ndryshon.
Me gjelbër është shënuar kanali i aktiviteteve të infrastrukturës në të njëjtin skenar. Vini re se si sillet tani RPC. Kërkesa përdor infrastrukturën vetëm për një krah nga balancuesi në backend. Ndërsa REST gjithashtu humbet në kërkesën e parë, por e përmbush borxhin duke përdorur të gjithë infrastrukturën.
Bëni një skenar ku nuk keni dy kërkesa për pasurim, por le të themi pesë ose dhjetë... dhe përgjigja për pyetjen “kush fiton tani?” bëhet e paqartë.
Propozoj të shohim edhe më gjerë në problem. Në skemë është e dukshme si përdoren kanalet e infrastrukturës, por infrastruktura nuk kufizohet 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ë.
Shihni se si infrastruktura e RPC është “përmirësuar” në mënyrë të dukshme për t’u përgjigjur kërkesave të ngarkesës së lartë. E gjithë çështja është se REST përdor të gjithë fuqinë e protokollit HTTP krahasuar me RPC. Në skemën e dhënë, kjo fuqi realizohet përmes metodës së kërkesës - GET.
Metodet e HTTP, përveç të tjerave, kanë strategji keҫhimi. Mund të njiheni me to në dokumentacionin mbi . Për RPC përdoren kërkesa POST, të cilat nuk konsiderohen idempotente, që do të thotë se përsëritja e njëjtave kërkesa POST mund të kthejë rezultate të ndryshme (për shembull, pas çdo dërgimi të një komenti do të shfaqet një kopje e re e këtij komentit) ().
Prandaj, RPC nuk është në gjendje të përdorë në mënyrë efektive cache-t e infrastrukturës. Kjo çon në nevojën për të “sërrish” cache të softuerit. Në këtë skemë, Redis është paraqitur në këtë rol. Cache i softuerit, nga ana tjetër, kërkon një shtresë të re kodi nga zhvilluesi dhe ndryshime të dukshme në arkitekturë.
Tani, le të numërojmë se sa kërkesa “ka lindur” REST dhe RPC në infrastrukturën e shqyrtuar?
Kërkesat
Të ardhura
tek backend
tek DBMS
tek cache-i softueror (Redis)
TOTAL
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] në rastin më të mirë (nëse cache-i lokal është përdorur) 1 kërkesë (një!), në rastin më të keq 32 kërkesa hyrëse.
Në krahasim me skemën e parë, ndryshimi është i theksuar. Tani bëhet e qartë se si fiton REST. Por propozoni të mos ndalemi këtu. Një infrastrukturë e zhvilluar përfshin CDN. Ai shpesh zgjidh problemin e kundërshtimit të DDoS dhe DoS sulmeve. Le të marrim:
Këtu për RPC gjithçka bëhet mjaft e mjerueshme. RPC thjesht nuk është në gjendje të delegojë punën me ngarkesën e CDN. E vetmja gjë që mbetet është të shpresojmë në sistemet e kundërshtimit të sulmeve.
A mund të mbyllet këtu? Sërish, jo. Metodat HTTP, siç është përmendur më parë, kanë "magjinë" e tyre. Dhe nuk është rastësi që metoda GET është e përdorur gjerësisht në Internet. Vini re se kjo metodë ka aftësinë për të adresuar pjesë të përmbajtjes, dhe për të vendosur kushte që mund të interpretohen nga elementët infrastrukturorë ende para se t'i kalojë kontrollin kodit tuaj, etj. Të gjitha këto lejojnë krijimin e infrastrukturave fleksibël dhe të menaxhueshme që mund të përballojnë flukse të mëdha kërkesash. Ndërsa në RPC, kjo metodë... injorohet.
Pra, pse miti se kërkesat batch (RPC) janë më të shpejta është kaq i qëndrueshëm? Personalish, mendoj se shumica e projekteve thjesht nuk arrijnë një nivel zhvillimi ku REST-i tregon forcën e tij. Më shumë, në projektet e vogla, ai më shumë tregon dobësitë e tij.
Zgjedhja midis REST dhe RPC nuk është një vendim arbitrar i një individi brenda projektit. Kjo zgjedhje duhet të përputhet me kërkesat e projektit. Nëse projekti mund ta shfrytëzojë në maksimum atë që REST ofron vërtet dhe kjo është vërtet e nevojshme, atëherë REST do të jetë një zgjedhje e shkëlqyer.
Por nëse për të përfituar nga të gjitha përfitimet e REST, është e nevojshme të punësohet dev-opë për të menaxhuar infrastrukturën në mënyrë operative, administratorë për menaxhimin e infrastrukturës, dhe një arkitekt për të dizajnuar të gjitha shtresat e shërbimit WEB... dhe projekti, për më tepër, shes tre paketat e margarinës në ditë... unë do të ndalesha në RPC, pasi ky protokoll është më utilitar. Ai nuk kërkon njohuri të thella mbi punën e caches dhe infrastrukturës, dhe fokusohet në thirrje të thjeshta dhe kuptimplota të procedurave që i duhen zhvilluesit. Biznesi do të jetë i kënaqur.
Kërkesat RPC janë më të besueshme, sepse mund të realizojnë kërkesa batch brenda një transaksioni.
Ky atribut i RPC është një avantazh i padyshimtë, pasi është më e lehtë të mbajmë bazën e të dhënave në një gjendje konsistente. Ndërsa me REST bëhet më e komplikuar. Kërkesat mund të vijnë në mënyrë të paqartë në node të ndryshme backend.
Ky "disavantazh" i REST-it është ana tjetër e avantajit të tij të përmendur më lart — aftësia për të shfrytëzuar në mënyrë efektive të gjitha burimet e infrastrukturës.Nëse infrastruktura është projektuar keq, e veçanërisht, nëse arkitektura e projektit dhe e bazës së të dhënave është projektuar keq, atëherë kjo është vërtet një dhimbje e madhe.
Por a janë kërkesat batch aq të besueshme sa duken? Le t'i hedhim një vështrim një rasti: krijojmë një përdorues, e pasurojmë profilin e tij me një përshkrim dhe i dërgojmë SMS me një kod për të përfunduar regjistrimin. Pra, tre thirrje në një kërkesë batch.
Le ta shqyrtojmë skemën. Ajo paraqet infrastrukturën me elemente të disponueshmërisë së lartë. Ka dy kanale të pavarura të komunikimit me portat SMS. Por... çfarë shohim? Gjatë dërgimit të SMS, ndodh një gabim 503 — shërbimi nuk është përkohësisht i disponueshëm. Duke qenë se dërgimi i SMS është i paketuara në një kërkesë batch, atëherë gjithë kërkesa duhet të anulohet. Veprimet në DB anullohen. Klienti merr një gabim.
Përpjekja e ardhshme është një llotari. Ose kerkesa përsëri do të shkojë në të njëjtën node dhe do të kthejë sërish gabimin, ose do të kemi fat dhe do të realizohet. Por më e rëndësishmja, që të paktën një herë infrastruktura jonë ka punuar kot. Ka pasur ngarkesë, por nuk ka pasur dobi.
Mirë, le të imagjinojmë se jemi munduar (!) dhe kemi menduar për një variant kur kërkesa mund të realizohet me sukses pjesërisht. Ndërsa e mbetura, ne do të përpiqemi ta realizojmë përsëri pas një periudhe kohe (Cila? E vendos fronti?). Por llotaria mbetet po ashtu. Kërkesa për dërgimin e SMS ka probabilitet 50/50 që përsëri do të dështojë.
Pranoni se, nga këndvështrimi i klientit, shërbimi nuk duket aq i besueshëm sa dëshirohej... dhe çfarë me REST?
REST përsëri përdor "magjinë" e HTTP, por tani me kodet e përgjigjeve. Kur ndodh një gabim 503 në portin SMS, backend e transmeton këtë gabim tek balancuesi. Balancuesi, duke marrë këtë gabim dhe pa e ndërprerë lidhjen me klientin, e drejton kërkesën drejt një node tjetër, e cila e realizon kërkesën me sukses. Kështu, klienti merr rezultatin e pritur, dhe infrastruktura konfirmon titullin e saj të lartë si “të disponueshme”. Përdoruesi është i lumtur.
Dhe përsëri, kjo nuk është gjithçka. Balancuesi nuk mori thjesht kodin e përgjigjes 503. Ky kod, sipas standardit, preferohet të shoqërohet me një header "Retry-After". Headeri tregon balancuesit se nuk duhet ta shqetësojë këtë node për këtë rrugë për një periudhë të caktuar kohe. Kështu, kërkesat e ardhshme për dërgimin e SMS do të dërgohen menjëherë në një node që nuk ka probleme me portin SMS.
Siç e shohim, besueshmëria e JSON-RPC është e ekzagjeruar. Vërtet, është më e lehtë të organizohet konsistenca në DB. Por si pasojë, besueshmëria e sistemit në tërësi do të dëmtohet.
Dalja e ngjashme me atë të mëparshmen. Kur infrastruktura është e thjeshtë, transparenca e JSON-RPC është padyshim një përfitim. Nëse projekti parashikon disponibilitet të lartë me një ngarkesë të lartë, REST duket si një zgjidhje më e saktë, megjithëse më komplekse.
Pra, kufiri i hyrjes në REST është më i ulët
Mendoj se analiza e lartpërmendur që hedh poshtë stereotipat e ngulitur për RPC e tregon qartë se kufiri i hyrjes në REST është padyshim më i lartë se sa në RPC. Kjo është për shkak të nevojës për një kuptim të thellë të funksionimit të HTTP, si dhe për nevojën për të pasur njohuri të mjaftueshme rreth elementeve ekzistuese të infrastrukturës që mund dhe duhet të përdoren në projektet WEB.
Pra, përse shumë mendojnë se REST është më i lehtë? Mendoj se kjo dukshmëri e lehtësisë buron nga vetë manifestet e REST. Pra, REST nuk është një protokoll, por një koncept... REST nuk ka standard, por disa rekomandime... REST nuk është më i komplikuar se HTTP. Duket si liri dhe anarshi që tërheq "artizane të lirë".
Pa dyshim, REST nuk është më i komplikuar se HTTP. Por vetë HTTP është një protokoll i mirëpërcaktuar, i cili e ka provuar vlerën e tij për dekada. Nëse nuk keni një kuptim të thellë të vetë HTTP-së, atëherë nuk mund të gjykoni as për REST.
Ndërsa për RPC — mund të bëhet. Mjafton të merrni specifikimin e tij. Pra, a ju nevojitet ? Или все же хитрый REST? Решать вам.
Shpresoj sinqerisht se nuk e kam humbur kohën tuaj kot.
Burimi: habr.com
