Sunt sigur că titlul a provocat o reacție sănătoasă - „ei bine, din nou a început...”. Dar permiteți-mi să vă rețin atenția timp de 5-10 minute și voi încerca să nu vă dezamăgesc așteptările.
Structura articolului va fi următoarea: se ia o afirmație stereotipică și se dezvăluie „natura” apariției acestui stereotip. Sper că aceasta va permite să priviți alegerea paradigmei de schimb de date în proiectele dumneavoastră dintr-o nouă perspectivă.
Pentru a avea o claritate în ceea ce privește RPC, vă propun să analizăm standardul . Cu REST nu există claritate. Și nu ar trebui să existe. Tot ce trebuie să știți despre REST - este indistinct de .
Solicitările RPC sunt mai rapide și mai eficiente deoarece permit realizarea de solicitări în bloc.
Este vorba despre faptul că în RPC poți apela simultan mai multe proceduri într-o singură solicitare. De exemplu, să creezi un utilizator, să-i adaugi un avatar și să-l abonezi la unele subiecte în aceeași solicitare. Doar o solicitare, dar cât de multe beneficii!
Într-adevăr, dacă aveți doar un nod backend, acesta va părea mai rapid la solicitările în bloc. Pentru că trei solicitări REST vor necesita de trei ori mai multe resurse de la un nod pentru stabilirea conexiunilor.
Rețineți că prima solicitare în cazul REST trebuie să returneze identificatorul utilizatorului pentru a efectua solicitările ulterioare. Acest lucru afectează de asemenea rezultatul general.
Dar astfel de infrastructuri se pot găsi, cel mult, în soluții interne și Enterprise. În cel mai rău caz, în proiecte WEB mai mici. Însă soluțiile WEB complete, numite încă și HighLoad, nu ar trebui construite astfel. Infrastructura lor trebuie să corespundă criteriilor de înaltă disponibilitate și încărcare. Și imaginea se schimbă.
Canalele de activitate ale infrastructurii sunt marcate în verde în același scenariu. Observați cum se comportă RPC acum. Solicitarea utilizează infrastructura doar pe un singur braț de la balansor la backend. În timp ce REST continuă să piardă la prima solicitare, dar compensează pierderea utilizând întreaga infrastructură.
Este suficient să introducem în scenariu nu două solicitări pentru îmbogățire, ci, să zicem, cinci sau zece... și răspunsul la întrebarea „cine câștigă acum?” devine neclar.
Propun să privim mai larg problema. În diagramă se poate observa cum sunt utilizate canalele infrastructurii, dar infrastructura nu se limitează la canale. O componentă importantă a infrastructurii cu sarcină înaltă o constituie cache-urile. Haideți acum să obținem un artefact al utilizatorului. De câteva ori. Să spunem de 32 de ori.
Observați cât de mult s-a "îmbunătățit" infrastructura pe RPC pentru a răspunde cerințelor de sarcină mare. Totul se datorează faptului că REST utilizează întreaga putere a protocolului HTTP, spre deosebire de RPC. În diagrama prezentată, această putere este realizată prin metoda de cerere — GET.
Metodele HTTP, printre altele, au strategii de caching. Puteți să vă familiarizați cu ele în documentația de la . Pentru RPC se folosesc cereri POST, care nu sunt considerate idempotente, adică repetarea de mai multe ori a aceleași cereri POST poate returna rezultate diferite (de exemplu, după fiecare trimitere a unui comentariu va apărea o nouă copie a acelui comentariu) ().
Prin urmare, RPC nu este capabil să utilizeze eficient cache-urile infrastructurii. Acest lucru duce la necesitatea de a "importa" cache-uri software. În schemă, Redis este reprezentat în acest rol. Cache-ul software, la rândul său, necesită de la dezvoltator un strat de cod suplimentar și modificări semnificative în arhitectură.
Hai să calculăm acum câte cereri a generat REST și RPC în infrastructura examinată?
Cererile
Încoming
towards backend
towards DBMS
towards soft cache (Redis)
TOTAL
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] în cel mai bun caz (dacă se folosește cache local) 1 cerere (una!), în cel mai rău caz 32 de cereri incoming.
Comparativ cu prima diagramă, diferența este izbitoare. Acum devine evident avantajul REST. Dar propun să nu ne oprim aici. O infrastructură dezvoltată include CDN. Deseori aceasta rezolvă problema contracarării atacurilor DDoS și DoS. Să obținem:
Aici pentru RPC devine totul foarte problematic. RPC pur și simplu nu este capabil să deleze munca cu încărcarea CDN. Rămâne doar să sperăm la Sistemele de contracarare a atacurilor.
Se poate încheia aici? Și din nou, nu. Metodele HTTP, așa cum s-a menționat mai sus, au „magia” lor. Și nu este întâmplător că metoda GET este utilizată pe scară largă în Internet. Observați că această metodă poate accesa o parte a conținutului, poate impune condiții care pot fi interpretate de elementele infrastructurii înainte de a preda controlul codului dumneavoastră etc. Toate acestea permit crearea de infrastructuri flexibile, gestionate, capabile să proceseze cu adevărat volume mari de cereri. Iar în RPC, această metodă… este ignorată.
Atunci de ce există acest mit persistent că cererile batch (RPC) sunt mai rapide? Personal, mi se pare că majoritatea proiectelor nu ajung la un nivel de dezvoltare în care REST să își poată arăta puterea. Mai mult, în proiectele mici, el își arată mai repede slăbiciunile.
Alegerea între REST sau RPC nu este o decizie arbitrară a unei singure persoane în proiect. Această alegere trebuie să răspundă cerințelor proiectului. Dacă proiectul poate extrage tot ce poate REST, iar acest lucru este cu adevărat necesar, atunci REST va fi o alegere excelentă.
Dar dacă pentru a obține toate avantajele REST trebuie să angajezi devops în proiect pentru scalarea rapidă a infrastructurii, administratori pentru gestionarea infrastructurii, un arhitect pentru proiectarea tuturor stratelor serviciului WEB… iar proiectul vinde, între timp, trei pachete de margarină pe zi… m-aș opri la RPC, deoarece acest protocol este mai utilitar. Nu va necesita cunoștințe aprofundate despre modul de funcționare a cache-urilor și infrastructurii, și va concentra dezvoltatorul pe apeluri simple și clare ale procedurilor necesare. Afacerea va fi mulțumită.
Cererea RPC este mai fiabilă, deoarece poate executa cereri batch într-o singură tranzacție.
Această proprietate a RPC este un avantaj incontestabil, deoarece este ușor să menții baza de date în stare consistentă. Cu REST, însă, devine mai complicat. Cererile pot ajunge neordonat pe noduri diferite ale backend-ului.
Această „neajuns” al REST-ului este reversul avantajului său descris mai sus — capacitatea de a utiliza eficient toate resursele infrastructurii. Dacă infrastructura este proiectată prost, iar mai ales, dacă arhitectura proiectului și a bazei de date în special este slab concepută, atunci aceasta poate fi cu adevărat o mare durere.
Dar cât de fiabile sunt cererile batch așa cum par? Să examinăm un caz: creăm un utilizator, îmbogățim profilul său cu o descriere și îi trimitem un SMS cu un secret pentru a finaliza înregistrarea. Așadar, trei apeluri într-o singură cerere batch.
Să examinăm schema. Aceasta prezintă infrastructura cu elemente de disponibilitate ridicată. Există două canale de comunicare independente cu gateway-urile SMS. Dar... ce vedem? La trimiterea SMS-ului apare o eroare 503 — serviciul este temporar indisponibil. Deoarece trimiterea SMS-ului este inclusă într-o cerere batch, întreaga cerere trebuie să fie revenită. Acțiunile din SGBD sunt anulate. Clientul primește o eroare.
Următoarea încercare este o loterie. Fie cererea ajunge din nou la aceeași nodă și returnează din nou o eroare, fie avem noroc și se va executa. Dar cel mai important, ca măcar o dată infrastructura noastră a muncit în zadar. A existat o încărcare, dar nu a fost niciun profit.
Bine, să presupunem că ne-am străduit (!) și am gândit o variantă în care cererea poate fi executată parțial cu succes. Iar restul, vom încerca din nou să-l executăm după un anumit interval de timp (Ce interval? Deciderea revine front-end-ului?). Dar loteria a rămas aceeași. Cererea de trimitere a SMS-ului cu o probabilitate de 50/50 va eșua din nou.
Să fim sinceri, din perspectiva clientului, serviciul nu pare atât de fiabil pe cât ne-am dori... și ce zice REST?
REST folosește din nou „ magia” HTTP, dar acum cu coduri de răspuns. La apariția erorii 503 la gateway-ul SMS, backend-ul translează această eroare către echilibrator. Echilibratorul, primind această eroare, și fără a întrerupe conexiunea cu clientul, direcționează cererea către o altă nodă, care procesează cu succes cererea. Așadar, clientul primește rezultatul așteptat, iar infrastructura își confirmă titlul de „high availability”. Utilizatorul este fericit.
Și din nou, asta nu este tot. Echilibratorul nu a obținut doar codul de răspuns 503. Acest cod, conform standardului, ar trebui ideal să fie însoțit de antetul „Retry-After”. Antetul îi explică echilibratorului că nu ar trebui să deranjeze această nodă pe acest traseu timp de o perioadă de timp specificată. Iar următoarele cereri de trimitere a SMS-ului vor fi direcționate imediat către nodul care nu are probleme cu gateway-ul SMS.
După cum vedem, fiabilitatea JSON-RPC este supraestimată. Într-adevăr, este mai ușor să organizăm consistența în SGBD. Dar, în acest caz, fiabilitatea sistemului în ansamblu va fi sacrificată.
Ieşirea este în mare parte similară cu cea anterioară. Când infrastructura este simplă, claritatea JSON-RPC este cu siguranță un avantaj. Dacă proiectul preconizează o disponibilitate ridicată cu o încărcare mare, REST pare o soluție mai corectă, deși mai complexă.
Pragul de intrare în REST este mai scăzut
Cred că analiza de mai sus, care demontează stereotipuri bine înrădăcinate despre RPC, arată clar că pragul de intrare în REST este cu siguranță mai mare decât în RPC. Acest lucru se datorează necesității unei înțelegeri profunde a modului în care funcționează HTTP, precum și necesității de a avea suficiente cunoștințe despre elementele infrastructurale existente care pot fi aplicate în proiectele web.
Atunci de ce mulți cred că REST va fi mai simplu? Personal, opinia mea este că această aparență de simplitate provine din însăși manifestele REST. Adică, REST nu este un protocol, ci o concepție... REST nu are un standard, există anumite recomandări... REST nu este mai complicat decât HTTP. Aparenta libertate și anarhie cheamă „artisti liberi”.
Cu siguranță, REST nu este mai complicat decât HTTP. Dar HTTP în sine este un protocol bine gândit care și-a demonstrat soliditatea timp de decenii. Dacă nu există o înțelegere profundă a ceea ce este HTTP, atunci nu se poate judeca nici despre REST.
Dar despre RPC - se poate. Este suficient să iei specificația sa. Așadar, ai nevoie de ? Или все же хитрый REST? Решать вам.
Sper sincer că nu ți-am consumat timpul în zadar.
Sursa: habr.com
