Esmu pārliecināts, ka virsraksts izraisīja veselīgu reakciju - "nu, atkal sākās..." Bet ļaujiet man piesaistīt jūsu uzmanību uz 5-10 minūtēm, un es centīšos nepievilt jūsu cerības.
Raksta struktūra būs šāda: tiek pieņemts stereotipisks apgalvojums un tiek atklāta šī stereotipa rašanās “daba”. Ceru, ka tas ļaus paskatīties uz datu apmaiņas paradigmas izvēli savos projektos no jauna leņķa.
Lai būtu skaidrs, kas ir RPC, es ierosinu apsvērt standartu . Ar REST nav skaidrības. Un tā tam nevajadzētu būt. Viss, kas jums jāzina par REST - to nevar atšķirt .
RPC pieprasījumi ir ātrāki un efektīvāki, jo tie ļauj veikt pakešu pieprasījumus.
Lieta tāda, ka RPC vienā pieprasījumā var izsaukt vairākas procedūras vienlaikus. Piemēram, izveidojiet lietotāju, pievienojiet viņam iemiesojumu un tajā pašā pieprasījumā abonējiet viņam dažas tēmas. Tikai viens lūgums, un cik daudz labuma!
Patiešām, ja jums ir tikai viens aizmugursistēmas mezgls, tas šķitīs ātrāks ar pakešu pieprasījumu. Tā kā trīs REST pieprasījumiem no viena mezgla būs nepieciešams trīs reizes vairāk resursu, lai izveidotu savienojumus.
Ņemiet vērā, ka pirmajā pieprasījumā REST gadījumā ir jāatgriež lietotāja ID, lai varētu veikt turpmākos pieprasījumus. Kas arī negatīvi ietekmē kopējo rezultātu.
Taču šādas infrastruktūras var atrast tikai iekšējos risinājumos un uzņēmumā. Kā pēdējais līdzeklis mazos WEB projektos. Taču pilnvērtīgus WEB risinājumus un pat tos, ko sauc par HighLoad, nav vērts veidot. To infrastruktūrai jāatbilst augstas pieejamības un slodzes kritērijiem. Un aina mainās.
Infrastruktūras darbības kanāli saskaņā ar to pašu scenāriju ir atzīmēti zaļā krāsā. Ievērojiet, kā RPC uzvedas tagad. Pieprasījums izmanto infrastruktūru tikai vienā posmā no balansētāja līdz aizmugursistēmai. Lai gan REST joprojām zaudē pirmajā pieprasījumā, tas kompensē zaudēto laiku, izmantojot visu infrastruktūru.
Pietiek ierakstīt scenārijā nevis divus bagātināšanas pieprasījumus, bet, teiksim, piecus vai desmit... un atbildi uz jautājumu "kurš tagad uzvar?" kļūst neskaidrs.
Es ierosinu šo problēmu aplūkot vēl plašāk. Diagramma parāda, kā tiek izmantoti infrastruktūras kanāli, bet infrastruktūra neaprobežojas tikai ar kanāliem. Svarīga lielas slodzes infrastruktūras sastāvdaļa ir kešatmiņas. Tagad iegūsim sava veida lietotāja artefaktu. Atkārtoti. Teiksim, 32 reizes.
Skatiet, kā RPC infrastruktūra ir ievērojami uzlabojusies, lai apmierinātu augstas slodzes prasības. Lieta ir tāda, ka REST atšķirībā no RPC izmanto visu HTTP protokola jaudu. Iepriekš redzamajā diagrammā šī jauda tiek realizēta, izmantojot pieprasījuma metodi - GET.
HTTP metodēm, cita starpā, ir kešatmiņas stratēģijas. Jūs varat tos atrast dokumentācijā vietnē . RPC tiek izmantoti POST pieprasījumi, kas netiek uzskatīti par idempotentiem, tas ir, to pašu POST pieprasījumu atkārtota atkārtošana var sniegt atšķirīgus rezultātus (piemēram, pēc katra komentāra nosūtīšanas parādīsies cita šī komentāra kopija) ().
Līdz ar to RPC nespēj efektīvi izmantot infrastruktūras kešatmiņas. Tas rada nepieciešamību “importēt” programmatūras kešatmiņas. Diagramma parāda Redisu šajā lomā. Programmatūras kešatmiņa savukārt pieprasa izstrādātājam pievienot papildu koda slāni un pamanāmas izmaiņas arhitektūrā.
Tagad saskaitīsim, cik pieprasījumu REST un RPC “dzemdēja” apskatāmajā infrastruktūrā?
pieprasījumi
Iesūtne
uz aizmuguri
uz DBVS
uz mīksto kešatmiņu (Redis)
KOPĀ
ATPŪTA
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Salīdzinot ar pirmo shēmu, atšķirība ir pārsteidzoša. Tagad REST ieguvums kļūst skaidrs. Bet es iesaku pie tā neapstāties. Izstrādātā infrastruktūra ietver CDN. Bieži vien tas atrisina arī DDoS un DoS uzbrukumu apkarošanas problēmu. Mēs iegūstam:
Šeit RPC situācija kļūst ļoti slikta. RPC vienkārši nespēj deleģēt darba slodzi CDN. Mēs varam paļauties tikai uz sistēmām, lai cīnītos pret uzbrukumiem.
Vai šeit ir iespējams beigt? Un atkal nē. HTTP metodēm, kā minēts iepriekš, ir sava "maģija". Un ne velti GET metode tiek plaši izmantota internetā. Ņemiet vērā, ka šī metode spēj piekļūt satura daļai, var iestatīt nosacījumus, kurus infrastruktūras elementi var interpretēt, pirms kontrole tiek nodota jūsu kodam utt. Tas viss ļauj izveidot elastīgu, pārvaldāmu infrastruktūru, kas spēj apstrādāt patiešām lielas pieprasījumu plūsmas. Bet RPC šī metode... tiek ignorēta.
Tātad, kāpēc mīts, ka pakešu pieprasījumi (RPC) ir ātrāki, ir tik pastāvīgs? Man personīgi šķiet, ka lielākā daļa projektu vienkārši nesasniedz tādu attīstības līmeni, kurā REST spēj parādīt savu spēku. Turklāt mazos projektos viņš labprātāk parāda savas vājās puses.
REST vai RPC izvēle nav indivīda brīvprātīga izvēle projektā. Šai izvēlei jāatbilst projekta prasībām. Ja projekts spēj no REST izspiest visu, ko tas patiešām var, un tam tas patiešām ir vajadzīgs, tad REST būs lieliska izvēle.
Bet, ja, lai izmantotu visas REST priekšrocības, projektam ir jānoalgo devops speciālisti, lai ātri paplašinātu infrastruktūru, administratori, lai pārvaldītu infrastruktūru, arhitekts, lai izstrādātu visus WEB pakalpojuma slāņus... un projektu. , tajā pašā laikā pārdod trīs pakas margarīna dienā... Es paliktu pie RPC, jo... šis protokols ir utilitārāks. Tas neprasīs dziļas zināšanas par to, kā darbojas kešatmiņas un infrastruktūra, bet gan koncentrēsies uz vienkāršiem un saprotamiem izsaukumiem uz viņam nepieciešamajām procedūrām. Bizness būs laimīgs.
RPC pieprasījumi ir uzticamāki, jo tie var izpildīt pakešu pieprasījumus viena darījuma ietvaros
Šī RPC īpašība ir neapšaubāma priekšrocība, jo Ir viegli uzturēt datubāzes konsekvenci. Bet ar REST tas kļūst arvien sarežģītāk. Pieprasījumi dažādos aizmugursistēmas mezglos var nonākt nekonsekventi.
Šis REST “trūkums” ir tā iepriekš aprakstītā priekšrocība – spēja efektīvi izmantot visus infrastruktūras resursus. Ja infrastruktūra ir slikti izstrādāta un vēl jo vairāk, ja projekta arhitektūra un jo īpaši datubāze ir slikti izstrādāta, tad tas patiešām ir lielas sāpes.
Bet vai pakešu 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 noslēpumu, lai pabeigtu reģistrāciju. Tie. trīs zvani vienā pakešu pieprasījumā.
Apskatīsim diagrammu. Tā piedāvā infrastruktūru ar augstas pieejamības elementiem. Ir divi neatkarīgi saziņas kanāli ar SMS vārtejām. Bet... ko mēs redzam? Nosūtot SMS, rodas kļūda 503 - pakalpojums īslaicīgi nav pieejams. Jo SMS sūtīšana tiek iesaiņota pakešu pieprasījumā, tad viss pieprasījums ir jāatgriež. Darbības DBVS ir atceltas. Klients saņem kļūdu.
Nākamais mēģinājums ir loterija. Vai nu pieprasījums atkal un atkal sasniegs vienu un to pašu mezglu, vai arī jums paveiksies un tas tiks izpildīts. Bet galvenais ir tas, ka vismaz vienu reizi mūsu infrastruktūra jau ir strādājusi veltīgi. Bija slodze, bet peļņas nebija.
Labi, iedomāsimies, ka esam sasprindzinājušies (!) un pārdomājuši variantu, kad pieprasījumu var daļēji izpildīt veiksmīgi. Un mēs mēģināsim vēlreiz pabeigt pārējo pēc kāda laika intervāla (kurš no tiem? Vai fronte izlemj?). Bet izloze palika tā pati. Pieprasījumam nosūtīt SMS ir 50/50 iespējamība, ka tas atkal neizdosies.
Piekrītu, no klienta puses serviss nešķiet tik uzticams kā gribētos... kā ar REST?
REST atkal izmanto HTTP burvību, bet tagad ar atbildes kodiem. Ja SMS vārtejā rodas kļūda 503, aizmugursistēma pārraida šo kļūdu līdzsvarotājam. Balsotājs saņem šo kļūdu un, nepārtraucot savienojumu ar klientu, nosūta pieprasījumu citam mezglam, kas veiksmīgi apstrādā pieprasījumu. Tie. klients saņem gaidīto rezultātu, un infrastruktūra apliecina savu augsto titulu “augsti pieejams”. Lietotājs ir laimīgs.
Un atkal tas vēl nav viss. Balansētājs nesaņēma tikai atbildes kodu 503. Atbildot, saskaņā ar standartu, ieteicams norādīt šo kodu ar galveni “Retry-After”. Galvene balansētājam liek saprast, ka nav vērts traucēt šo mezglu šajā maršrutā uz noteiktu laiku. Un nākamie SMS sūtīšanas pieprasījumi tiks nosūtīti tieši uz mezglu, kuram nav problēmu ar SMS vārteju.
Kā redzam, JSON-RPC uzticamība ir pārvērtēta. Patiešām, datubāzē ir vieglāk organizēt konsekvenci. Bet upuris šajā gadījumā būs visas sistēmas uzticamība.
Secinājums lielā mērā ir līdzīgs iepriekšējam. Ja infrastruktūra ir vienkārša, JSON-RPC acīmredzamība noteikti ir pluss. Ja projekts ir saistīts ar augstu pieejamību ar lielu slodzi, REST izskatās kā pareizāks, lai arī sarežģītāks risinājums.
Ieejas slieksnis REST ir zemāks
Domāju, ka iepriekš minētā analīze, atmaskojot iedibinātos stereotipus par RPC, skaidri parādīja, ka slieksnis iekļūšanai REST neapšaubāmi ir augstāks nekā RPC. Tas ir saistīts ar nepieciešamību pēc dziļas izpratnes par HTTP darbību, kā arī ar pietiekamām zināšanām par esošajiem infrastruktūras elementiem, kurus var un vajadzētu izmantot WEB projektos.
Tātad, kāpēc daudzi cilvēki domā, ka ATPŪTA būs vienkāršāka? Mans personīgais viedoklis ir tāds, ka šī šķietamā vienkāršība izriet no REST izpausmēm. Tie. REST nav protokols, bet jēdziens... REST nav standarta, ir dažas vadlīnijas... REST nav sarežģītāks par HTTP. Šķietamā brīvība un anarhija piesaista “brīvos māksliniekus”.
Protams, REST nav sarežģītāks par HTTP. Bet pats HTTP ir labi izstrādāts protokols, kas ir pierādījis savu vērtību gadu desmitiem ilgi. Ja nav dziļas izpratnes par pašu HTTP, tad REST nevar spriest.
Bet par RPC - jūs varat. Pietiek ņemt tā specifikāciju. Tātad, vai jums ir nepieciešams ? Vai arī tā joprojām ir viltīga ATPŪTA? Izlem tu.
Es patiesi ceru, ka neesmu tērējis jūsu laiku.
Avots: www.habr.com