Sunt sigur că titlul a provocat o reacție sănătoasă - „ei bine, a început din nou...” Dar permiteți-mi să vă captez 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 declarație stereotipă și se dezvăluie „natura” apariției acestui stereotip. Sper că acest lucru vă va permite să priviți alegerea paradigmei de schimb de date în proiectele dvs. dintr-un unghi nou.
Pentru a fi clar ce este RPC, propun să luăm în considerare standardul . Cu REST nu există claritate. Și nu ar trebui să fie. Tot ce trebuie să știți despre REST - nu se poate distinge .
Solicitările RPC sunt mai rapide și mai eficiente, deoarece vă permit să faceți solicitări în lot.
Ideea este că în RPC puteți apela mai multe proceduri deodată într-o singură solicitare. De exemplu, creați un utilizator, adăugați-i un avatar și, în aceeași solicitare, abonați-l la unele subiecte. O singură cerere și câte beneficii!
Într-adevăr, dacă aveți un singur nod backend, va părea mai rapid cu o solicitare de lot. Deoarece trei cereri REST vor necesita de trei ori mai multe resurse de la un nod pentru a stabili conexiuni.
Rețineți că prima solicitare în cazul REST trebuie să returneze ID-ul utilizatorului pentru ca cererile ulterioare să fie făcute. Ceea ce afectează negativ și rezultatul general.
Dar astfel de infrastructuri pot fi găsite doar în soluții interne și Enterprise. În ultimă instanță, în proiecte WEB mici. Dar soluțiile WEB cu drepturi depline, și chiar și cele numite HighLoad, nu merită să fie construite. Infrastructura lor trebuie să îndeplinească criteriile de mare disponibilitate și încărcare. Și imaginea se schimbă.
Canalele de activitate ale infrastructurii în același scenariu sunt marcate cu verde. Observați cum se comportă RPC acum. Solicitarea folosește infrastructura pe un singur picior de la echilibrator la backend. În timp ce REST încă pierde la prima solicitare, compensează timpul pierdut folosind întreaga infrastructură.
Este suficient să introduceți în scenariu nu două cereri de îmbogățire, ci, să zicem, cinci sau zece... și răspunsul la întrebarea „cine câștigă acum?” devine neclar.
Îmi propun să aruncăm o privire și mai amplă asupra problemei. Diagrama arată cum sunt utilizate canalele de infrastructură, dar infrastructura nu se limitează la canale. O componentă importantă a unei infrastructuri cu încărcare mare este memoria cache. Să obținem acum un fel de artefact de utilizator. Repetat. Să spunem de 32 de ori.
Vedeți cum infrastructura RPC s-a îmbunătățit semnificativ pentru a răspunde cerințelor de sarcină mare. Chestia este că REST folosește întreaga putere a protocolului HTTP, spre deosebire de RPC. În diagrama de mai sus, această putere este realizată prin metoda cererii - GET.
Metodele HTTP, printre altele, au strategii de stocare în cache. Le găsiți în documentație la . Pentru RPC se folosesc cereri POST, care nu sunt considerate idempotente, adică repetările repetate ale acelorași solicitări POST pot returna rezultate diferite (de exemplu, după trimiterea fiecărui comentariu, va apărea o altă copie a acestui comentariu) ().
În consecință, RPC nu poate folosi în mod eficient cache-urile de infrastructură. Acest lucru duce la necesitatea „importului” cache-urilor software. Diagrama îl arată pe Redis în acest rol. Cache-ul software, la rândul său, necesită dezvoltatorului să adauge un strat suplimentar de cod și modificări vizibile în arhitectură.
Să numărăm acum câte cereri REST și RPC au „născut” în infrastructura luată în considerare?
cereri
Primite
a backend
la SGBD
la cache soft (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
În comparație cu prima schemă, diferența este izbitoare. Acum beneficiul REST devine clar. Dar recomand să nu ne oprim aici. Infrastructura dezvoltată include un CDN. Adesea rezolvă și problema contracarării atacurilor DDoS și DoS. Primim:
Aici lucrurile devin foarte proaste pentru RPC. RPC pur și simplu nu este capabil să delege volumul de lucru unui CDN. Ne putem baza doar pe sisteme pentru a contracara atacurile.
Este posibil să se încheie aici? Și din nou, nu. Metodele HTTP, așa cum am menționat mai sus, au propria lor „magie”. Și nu fără motiv metoda GET este utilizată pe scară largă pe Internet. Rețineți că această metodă este capabilă să acceseze o bucată de conținut, este capabilă să stabilească condiții pe care elementele de infrastructură le pot interpreta înainte ca controlul să fie transferat în codul dvs. și așa mai departe. Toate acestea vă permit să creați infrastructuri flexibile, gestionabile, care pot gestiona fluxuri foarte mari de cereri. Dar în RPC această metodă... este ignorată.
Așadar, de ce este atât de persistent mitul conform căruia cererile în loturi (RPC) sunt mai rapide? Personal, mi se pare că majoritatea proiectelor pur și simplu nu ating un nivel de dezvoltare în care REST este capabil să-și arate puterea. Mai mult, în proiectele mici, este mai dispus să-și arate slăbiciunile.
Alegerea REST sau RPC nu este o alegere volitivă a unui individ într-un proiect. Această alegere trebuie să îndeplinească cerințele proiectului. Dacă un proiect este capabil să stoarce tot ce poate din REST și chiar are nevoie de el, atunci REST va fi o alegere excelentă.
Dar dacă, pentru a beneficia de toate beneficiile REST, trebuie să angajați specialiști devops pentru proiect pentru a scala rapid infrastructura, administratori care să gestioneze infrastructura, un arhitect care să proiecteze toate straturile serviciului WEB... și proiectul , in acelasi timp, vinde trei pachete de margarina pe zi... Eu as ramane cu RPC, pentru ca... acest protocol este mai utilitar. Nu va necesita cunoștințe profunde despre modul în care funcționează cache-urile și infrastructura, dar va concentra dezvoltatorul pe apeluri simple și ușor de înțeles la procedurile de care are nevoie. Afacerile vor fi fericite.
Solicitările RPC sunt mai fiabile, deoarece pot executa solicitări lot în cadrul unei singure tranzacții
Această proprietate a RPC este un avantaj cert, deoarece Este ușor să păstrați consecvența bazei de date. Dar cu REST devine din ce în ce mai complicat. Solicitările pot ajunge în mod inconsecvent către diferite noduri backend.
Acest „dezavantaj” al REST este reversul avantajului său descris mai sus - capacitatea de a utiliza eficient toate resursele infrastructurii. Dacă infrastructura este prost proiectată și cu atât mai mult dacă arhitectura proiectului și baza de date în special sunt prost proiectate, atunci aceasta este într-adevăr o mare durere.
Dar sunt cererile de loturi la fel de fiabile pe cât par? Să ne uităm la un caz: creăm un utilizator, îi îmbogățim profilul cu o descriere și îi trimitem un SMS cu un secret pentru a finaliza înregistrarea. Acestea. trei apeluri într-o cerere de lot.
Să ne uităm la diagramă. Prezintă o infrastructură cu elemente de înaltă disponibilitate. Există două canale de comunicare independente cu gateway-uri SMS. Dar... ce vedem? La trimiterea unui SMS, apare o eroare 503 - serviciul este temporar indisponibil. Deoarece Trimiterea SMS este împachetată într-o solicitare de lot, apoi întreaga solicitare trebuie să fie anulată. Acțiunile din SGBD sunt anulate. Clientul primește o eroare.
Următoarea încercare este loteria. Fie cererea va lovi din nou același nod și va returna din nou o eroare, fie vei avea noroc și va fi executată. Dar principalul lucru este că cel puțin o dată infrastructura noastră a funcționat deja în zadar. A fost încărcătură, dar fără profit.
Bine, să ne imaginăm că ne-am efortat (!) și ne-am gândit la opțiunea când cererea poate fi parțial finalizată cu succes. Și vom încerca să completăm din nou restul după un interval de timp (care dintre ele? Decide frontul?). Dar loteria a rămas aceeași. Solicitarea de a trimite SMS are o șansă de 50/50 de a eșua din nou.
De acord, din partea clientului, serviciul nu pare atât de fiabil pe cât ne-am dori... ce zici de REST?
REST folosește din nou magia HTTP, dar acum cu coduri de răspuns. Când apare o eroare 503 pe gateway-ul SMS, backend-ul transmite această eroare către echilibrator. Echilibratorul primește această eroare și fără a întrerupe conexiunea cu clientul, trimite cererea către alt nod, care procesează cu succes cererea. Acestea. clientul primește rezultatul așteptat, iar infrastructura își confirmă titlul înalt de „foarte accesibil”. Utilizatorul este fericit.
Și din nou asta nu e tot. Echilibratorul nu a primit doar un cod de răspuns de 503. Când răspunde, conform standardului, este recomandabil să furnizați acest cod cu antetul „Retry-After”. Antetul îi arată clar echilibrantului că nu merită deranjat acest nod pe această rută pentru un timp specificat. Iar următoarele solicitări de a trimite SMS-uri vor fi trimise direct către un nod care nu are probleme cu gateway-ul SMS.
După cum putem vedea, fiabilitatea JSON-RPC este supraevaluată. Într-adevăr, este mai ușor să organizezi consistența în baza de date. Dar sacrificiul, în acest caz, va fi fiabilitatea sistemului în ansamblu.
Concluzia este în mare măsură similară cu cea anterioară. Când infrastructura este simplă, evidenta JSON-RPC este cu siguranță un plus. Dacă proiectul implică 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, dezmințind stereotipurile stabilite despre RPC, a arătat clar că pragul de intrare în REST este, fără îndoială, 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 nevoii de a avea suficiente cunoștințe despre elementele de infrastructură existente care pot și ar trebui utilizate în proiecte WEB.
Deci, de ce mulți oameni cred că REST va fi mai simplu? Părerea mea personală este că această aparentă simplitate provine din manifestările REST. Acestea. REST nu este un protocol, ci un concept... REST nu are un standard, există niște linii directoare... REST nu este mai complicat decât HTTP. Libertatea aparentă și anarhia atrag „artişti liberi”.
Desigur, REST nu este mai complicat decât HTTP. Dar HTTP în sine este un protocol bine conceput care și-a dovedit valoarea de-a lungul deceniilor. Dacă nu există o înțelegere profundă a HTTP în sine, atunci REST nu poate fi judecat.
Dar despre RPC - poți. Este suficient să-i luăm specificația. Deci ai nevoie ? Sau este încă dificil REST? Tu decizi.
Sper din tot sufletul că nu ți-am pierdut timpul.
Sursa: www.habr.com