Es esmu pārliecināts, ka virsraksts izraisīja veselīgu reakciju — "nu atkal sācies..." Bet ļaujiet man piesaistīt jūsu uzmanību 5-10 minūtes, un es centīšos neaizvainot gaidas.
Raksta struktūra būs šāda: tiks ņemts stereotipisks apgalvojums un atklāts tā "dabas" rašanās. Ceru, ka tas ļaus paskatīties uz datu apmaiņas paradigmu jūsu projektos jaunā gaismā.
Lai būtu skaidrs, kas ir RPC, es piedāvāju aplūkot standartu . Ar REST skaidrības nav. Un tam arī nevajadzētu būt. Viss, kas jums jāzina par REST — tas nav atšķirams no .
RPC pieprasījumi ir ātrāki un efektīvāki, jo ļauj veikt partijas pieprasījumus.
Runājot par to, RPC var vienā pieprasījumā veikt vairāku procedūru izsaukumus. Piemēram, izveidot lietotāju, pievienot tam avatāru un tajā pašā pieprasījumā parakstīt to uz dažiem tematiem. Viena pieprasījuma, un tik daudz labuma!
Patiesi, ja jums būs tikai viena backend mezglu, tas šķitīs ātrāk pie partiju pieprasījuma. Jo trīs REST pieprasījumi prasīs trīs reizes vairāk resursu no viena mezgla savienojumu izveidei.
Lūdzu, ņemiet vērā, ka pirmajam pieprasījumam REST gadījumā jāatgriež lietotāja identifikators turpmāko pieprasījumu veikšanai. Tas arī negatīvi ietekmē kopējo rezultātu.
Bet šādas infrastruktūras var sastapt, tikai in-house risinājumos un Enterprise. Ekstremālā gadījumā nelielos WEB projektos. Taču pilnvērtīgas WEB risinājumus, kas tiek saukti par HighLoad, tā veidot nevajadzētu. To infrastruktūrai jāatbilst augstas pieejamības un noslogojuma kritērijiem. Un aina mainās.
Zaļā krāsā ir iezīmēti infrastruktūras aktivitātes kanāli ar to pašu scenāriju. Pievērsiet uzmanību, kā tagad uzvedas RPC. Pieprasījums izmanto infrastruktūru tikai no vienas pleca no līdzsvarotāja līdz backend. Kamēr REST joprojām zaudē pirmajā pieprasījumā, bet kompensē zaudējumu, izmantojot visu infrastruktūru.
Pietiek, lai scenārijā iedotu ne divus pieprasījumus bagātināšanai, bet, teiksim, piecus vai desmit… un atbilde uz jautājumu "kurš tagad uzvar?" kļūst neacīmredzama.
Ieteiktu palūkoties vēl plašāk uz problēmu. Shēmā redzams, kā tiek izmantoti infrastruktūras kanāli, taču infrastruktūra neaprobežojas tikai ar kanāliem. Svarīga augstas slodzes infrastruktūras sastāvdaļa ir keši. Tagad iegūsim lietotāja artefaktu. Dažreiz. Teiksim, 32 reizes.
Paskatieties, kā acīmredzami ir "uzlabota" infrastruktūra RPC, lai izpildītu augstas slodzes prasības. Viss slēpjas tajā, ka REST izmanto visu HTTP protokola jaudu, atšķirībā no RPC. Nodrošinātajā shēmā šī jauda tiek realizēta caur pieprasījuma metodi — GET.
HTTP metodēm, starp citu, ir kešošanas stratēģijas. Ar tām var iepazīties dokumentācijā uz . RPC tiek izmantoti POST pieprasījumi, kas netiek uzskatīti par idempotentiem, tas ir, atkārtota vienu un to pašu POST pieprasījumu veikšana var atgriezt dažādus rezultātus (piemēram, pēc katras komentāra nosūtīšanas tiks parādīta jauna šī komentāra kopija) ().
Tādējādi RPC nespēj efektīvi izmantot infrastruktūras kešus. Tas noved pie tā, ka ir jā‘importē’ programmatūras keši. Shēmā šajā lomā tiek attēlots Redis. Programmatūras kešs, savukārt, prasa no izstrādātāja papildu koda slāni un ievērojamas izmaiņas arhitektūrā.
Tagad aprēķināsim, cik daudz pieprasījumu “radījis” REST un RPC aplūkotajā infrastruktūrā?
Pieprasījumi
Ienākošie
uz backend
uz DBMS
uz programmatūras kešu (Redis)
KOPĀ
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] labākajā gadījumā (ja tiek izmantots lokālais kešs) 1 pieprasījums (viens!), sliktākajā 32 ienākošie pieprasījumi.
Salīdzinājumā ar pirmo shēmu atšķirība ir acīmredzama. Tagad kļūst skaidrs, kāpēc REST ir ieguvums. Bet aicinu neapstāties pie sasniegtā. Attīstīta infrastruktūra ietver CDN. Bieži vien tas arī atrisina DDoS un DoS uzbrukumu pretestības jautājumu. Iegūsim:
Te RPC situācija kļūst ļoti bēdīga. RPC vienkārši nespēj deleģēt slodzes darbu CDN. Atliek cerēt vienīgi uz uzbrukumu pretestības sistēmām.
Vai ir iespējams ar to noslēgt? Un atkal, nē. HTTP metodes, kā jau iepriekš tika minēts, ir ar savu "maģiju". Un nav nejauši, ka GET metode ir plaši izmantota Internetā. Pievērsiet uzmanību tam, ka šī metode spēj piekļūt daļai satura, spēj noteikt nosacījumus, kurus infrastruktūras elementi var interpretēt vēl pirms jūsu koda izpildes, utt. Tas viss ļauj veidot elastīgas, vadāmas infrastruktūras, kas spēj pārvaldīt patiešām lielus pieprasījumu plūdus. Savukārt RPC šī metode… tiek ignorēta.
Tātad, kāpēc pastāv mīts par to, ka partijas pieprasījumi (RPC) ir ātrāki? Personīgi man šķiet, ka lielākā daļa projektu vienkārši nesasniedz tādu attīstības līmeni, kad REST var parādīt savu spēku. Vairāk nekā tas, nelielos projektos tas labprātāk parāda savu vājumu.
Izvēle starp REST vai RPC nav atsevišķa cilvēka pašnoteikšanās projekta ietvaros. Šai izvēlei jāatbilst projekta prasībām. Ja projekts spēj gūt no REST visas tā patiesās priekšrocības, un tas tiešām ir nepieciešams, tad REST būs lieliska izvēle.
Bet, ja, lai gūtu visus REST ieguvumus, būs jānolīga projektu devopsi, lai operatīvi paplašinātu infrastruktūru, admini infrastruktūras pārvaldīšanai, arhitekts visu WEB pakalpojuma slāņu projektēšanai… un projekts šajā laikā pārdod trīs paciņas margarīna dienā… es izvēlētos RPC, jo šis protokols ir pragmatiskāks. Tas neprasa dziļas zināšanas par kešatmiņu un infrastruktūru, bet fokusē izstrādātāju uz vienkāršiem un saprotamiem nepieciešamo procedūru izsaukumiem. Bizness būs apmierināts.
RPC pieprasījumi ir uzticamāki, jo var izpildīt partijas pieprasījumus vienas transakcijas ietvaros.
Šī RPC īpašība ir viennozīmīgi plus, jo ir viegli uzturēt datubāzi konsekventā stāvoklī. Savukārt ar REST viss kļūst sarežģītāk. Pieprasījumi var nonākt nekonsekventi uz dažādām backend mezglu.
Šī REST "trūkums" ir pretējā puse tā ieguvumam, kas iepriekš aprakstīts — spēja efektīvi izmantot visus infrastruktūras resursus. Ja infrastruktūra ir slikti projektēta, un jo īpaši, ja projekta un datubāzes arhitektūra ir slikta, tas patiešām ir liela problēma.
Bet vai batch pieprasījumi ir tik uzticami, kā šķiet? Apskatīsim gadījumu: izveidojam lietotāju, bagātinām viņa profilu ar kādu aprakstu un nosūtām viņam SMS ar slepeno kodu, lai pabeigtu reģistrāciju. T.i., trīs izsaukumi vienā batch pieprasījumā.
Apskatīsim shēmu. Tajā attēlota infrastruktūra ar augstas pieejamības elementiem. Ir divi neatkarīgi sakaru kanāli ar SMS vārtiem. Bet… ko mēs redzam? Nosūtot SMS, rodas kļūda 503 — pakalpojums pagaidu nav pieejams. Tā kā SMS nosūtīšana ir iepakota batch pieprasījumā, viss pieprasījums jāatceļ. Dati datubāzē tiek anulēti. Klients saņem kļūdu.
Nākamā mēģinājuma iznākums — loterija. Vai nu pieprasījums atkal nonāks tajā pašā mezglā un atkal atgriezīs kļūdu, vai arī paveiksies, un tas izpildīsies. Bet vissvarīgākais ir tas, ka vismaz vienu reizi mūsu infrastruktūra jau ir strādājusi velti. Slodze bija, bet labuma nav.
Labi, iedomāsimies, ka mēs esam pievērsušies (!) un izdomājuši variantu, kad pieprasījums var veiksmīgi tikt izpildīts daļēji. Bet pārējo mēs atkārtoti mēģināsim izpildīt pēc kāda laika (kādu? Izlemj frontā). Bet loterija tā arī paliek. Pieprasījums nosūtīt SMS ar varbūtību 50/50 atkal izgāzīsies.
Piekritīsiet, ka klienta skatījumā, pakalpojums neveicas tik uzticami, kā vēlētos... bet kas par REST?
REST atkal izmanto “maģiju” HTTP, bet tagad ar atbildes kodiem. Kad SMS vārtos rodas kļūda 503, backend šo kļūdu pārsūta balansētājam. Balansētājs, saņemot šo kļūdu un nepārtraucot savienojumu ar klientu, nosūta pieprasījumu uz citu mezglu, kas veiksmīgi apstrādā pieprasījumu. T.i., klients saņem gaidīto rezultātu, bet infrastruktūra apstiprina savu augsto “augsti pieejama” statusu. Lietotājs ir apmierināts.
Un atkal tas nav viss. Balansētājs ne tikai saņēma atbildes kodu 503. Šis kods, atbildot, pēc standarta, vēlams, lai tiktu nodrošināts ar “Retry-After” galveni. Galvene norāda balansētājam, ka nevajadzētu uztraukt šo mezglu pa šo ceļu noteiktu laiku. Un nākamie pieprasījumi nosūtīt SMS tiks nosūtīti uzreiz uz mezglu, kuram nav problēmu ar SMS vārtiem.
Kā redzam, JSON-RPC uzticamība ir pārvērtēta. Patiesībā, ir vieglāk organizēt konsekvenci datubāzē. Bet šādā gadījumā cietīs sistēmas uzticamība kopumā.
Izvade ir lielā mērā līdzīga iepriekšējai. Kad infrastruktūra ir vienkārša, JSON-RPC acīmredzami ir tā priekšrocība. Ja projekts paredz augstu pieejamību ar augstu slodzi, REST izskatās kā pareizāka, lai gan sarežģītāka, izvēle.
Ieguldījumu slieksnis REST ir zemāks.
Es domāju, ka iepriekš minētā analīze, kas izgāž iepriekšējos stereotipus par RPC, skaidri parādīja, ka ieguldījumu slieksnis REST noteikti ir augstāks nekā RPC. Tas saistīts ar nepieciešamību dziļi izprast HTTP darbību, kā arī ar nepieciešamību būt pietiekamām zināšanām par esošajiem infrastruktūras elementiem, kurus var un vajag izmantot WEB projektos.
Tātad, kāpēc daudzi domā, ka REST būs vieglāks? Mans personīgais viedoklis ir tāds, ka šī šķietamā vienkāršība nāk no pašiem REST manifestiem. Proti, REST nav protokols, bet koncepcija... REST nav standarts, ir dažas rekomendācijas... REST nav sarežģītāk nekā HTTP. Šķietamā brīvība un anarhija vilina "brīvos māksliniekus".
Nepārprotami, REST nav sarežģītāks par HTTP. Bet pats HTTP ir labi pārdomāts protokols, kas ir pierādījis savu spēju gadu gaitā. Ja nav dziļas izpratnes par pašu HTTP, tad arī par REST nevar spriest.
Savukārt par RPC — var. Pietiek vien ņemt tā specifikāciju. Tātad, vai jums ir nepieciešams ? Или все же хитрый REST? Решать вам.
Es patiesi ceru, ka es nesu iztērējis jūsu laiku velti.
Avots: habr.com
