Siguran sam da je naslov izazvao zdravu reakciju - "pa opet je počelo..." Ali dopustite mi da zaokupim vašu pažnju na 5-10 minuta, a ja ću pokušati ne iznevjeriti vaša očekivanja.
Struktura članka bit će sljedeća: uzima se stereotipna izjava i otkriva se "priroda" nastanka tog stereotipa. Nadam se da će vam ovo omogućiti da sagledate izbor paradigme razmjene podataka u svojim projektima iz novog kuta.
Kako bi bilo jasno što je RPC, predlažem da razmotrimo standard . S REST-om nema jasnoće. A ne bi trebalo biti. Sve što trebate znati o REST-u - ne razlikuje se od njega .
RPC zahtjevi brži su i učinkovitiji jer vam omogućuju slanje skupnih zahtjeva.
Poanta je da u RPC-u možete pozvati nekoliko procedura odjednom u jednom zahtjevu. Na primjer, kreirajte korisnika, dodajte mu avatar i u istom zahtjevu pretplatite ga na neke teme. Samo jedan zahtjev, a kolika korist!
Doista, ako imate samo jedan pozadinski čvor, činit će se bržim sa skupnim zahtjevom. Zato što će tri REST zahtjeva zahtijevati tri puta više resursa iz jednog čvora za uspostavljanje veze.
Imajte na umu da prvi zahtjev u slučaju REST-a mora vratiti korisnički ID kako bi se mogli napraviti sljedeći zahtjevi. Što također negativno utječe na ukupni rezultat.
Ali takve se infrastrukture mogu pronaći samo u internim rješenjima i Enterpriseima. U krajnjem slučaju, u malim WEB projektima. Ali potpuna WEB rješenja, pa čak ni ona koja se nazivaju HighLoad, ne isplati se graditi. Njihova infrastruktura mora zadovoljiti kriterij visoke raspoloživosti i opterećenja. I slika se mijenja.
Kanali infrastrukturnih aktivnosti u istom scenariju označeni su zelenom bojom. Primijetite kako se RPC sada ponaša. Zahtjev koristi infrastrukturu samo na jednoj strani od balansera do pozadine. Iako REST još uvijek gubi u prvom zahtjevu, nadoknađuje izgubljeno vrijeme korištenjem cijele infrastrukture.
Dovoljno je u scenarij unijeti ne dva zahtjeva za bogaćenje, nego, recimo, pet ili deset... i odgovor na pitanje “tko sad pobjeđuje?” postaje nejasno.
Predlažem još širi pogled na problem. Dijagram pokazuje kako se koriste kanali infrastrukture, ali infrastruktura nije ograničena na kanale. Važna komponenta visokoopterećene infrastrukture su predmemorije. Uzmimo sada neku vrstu korisničkog artefakta. Opetovano. Recimo 32 puta.
Pogledajte kako se RPC infrastruktura značajno poboljšala kako bi zadovoljila zahtjeve velikog opterećenja. Stvar je u tome što REST koristi punu snagu HTTP protokola, za razliku od RPC-a. U gornjem dijagramu ova se moć realizira putem metode zahtjeva - GET.
HTTP metode, između ostalog, imaju strategije predmemoriranja. Možete ih pronaći u dokumentaciji na . Za RPC se koriste POST zahtjevi koji se ne smatraju idempotentnim, odnosno ponovljena ponavljanja istih POST zahtjeva mogu dati različite rezultate (na primjer, nakon svakog poslanog komentara pojavit će se još jedna kopija ovog komentara) ().
Posljedično, RPC ne može učinkovito koristiti infrastrukturne predmemorije. To dovodi do potrebe za "uvozom" softverskih predmemorija. Dijagram prikazuje Redis u ovoj ulozi. Softverska predmemorija pak zahtijeva od programera dodavanje dodatnog sloja koda i primjetnih promjena u arhitekturi.
Prebrojimo sada koliko su REST i RPC zahtjeva “izrodili” u infrastrukturi koja se razmatra?
Upiti
Vhodâŝie
na pozadinu
u DBMS
u meku predmemoriju (Redis)
UKUPNO
OSTALO
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
U usporedbi s prvom shemom, razlika je upečatljiva. Sada postaje jasna korist od REST-a. Ali predlažem da ne stanemo na tome. Razvijena infrastruktura uključuje CDN. Često također rješava problem suzbijanja DDoS i DoS napada. Dobivamo:
Ovo je mjesto gdje stvari postaju jako loše za RPC. RPC jednostavno nije sposoban delegirati radno opterećenje na CDN. Možemo se osloniti samo na sustave za suzbijanje napada.
Može li se ovdje završiti? I opet ne. HTTP metode, kao što je gore spomenuto, imaju vlastitu "čaroliju". I nije bez razloga GET metoda naširoko korištena na Internetu. Imajte na umu da ova metoda može pristupiti dijelu sadržaja, može postaviti uvjete koje elementi infrastrukture mogu protumačiti prije nego što se kontrola prenese na vaš kod, i tako dalje. Sve vam to omogućuje stvaranje fleksibilnih infrastruktura kojima se može upravljati i koje mogu podnijeti stvarno velike protoke zahtjeva. Ali u RPC-u ova se metoda... zanemaruje.
Pa zašto je mit da su skupni zahtjevi (RPC) brži tako uporan? Osobno mi se čini da većina projekata jednostavno ne dostiže razinu razvoja na kojoj REST može pokazati svoju snagu. Štoviše, u malim projektima spremniji je pokazati svoje slabosti.
Odabir REST-a ili RPC-a nije voljni izbor pojedinca u projektu. Ovaj izbor mora zadovoljiti zahtjeve projekta. Ako projekt može iz REST-a izvući sve što stvarno može, a to mu je stvarno potrebno, onda će REST biti odličan izbor.
Ali ako, da biste dobili sve prednosti REST-a, trebate angažirati devops stručnjake za projekt za brzo skaliranje infrastrukture, administratore za upravljanje infrastrukturom, arhitekta za dizajn svih slojeva WEB usluge... i projekt , u isto vrijeme, prodaje tri pakiranja margarina dnevno... Držao bih se RPC-a, jer... ovaj je protokol utilitarniji. Neće zahtijevati duboko znanje o tome kako predmemorije i infrastruktura rade, ali će programera usredotočiti na jednostavne i razumljive pozive procedura koje su mu potrebne. Posao će biti sretan.
RPC zahtjevi su pouzdaniji jer mogu izvršavati paketne zahtjeve unutar jedne transakcije
Ovo svojstvo RPC-a je definitivna prednost, jer Jednostavno je održavati bazu podataka dosljednom. Ali s REST-om postaje sve kompliciranije. Zahtjevi mogu nedosljedno stizati do različitih pozadinskih čvorova.
Ovaj “nedostatak” REST-a je naličje njegove gore opisane prednosti – mogućnosti učinkovitog korištenja svih infrastrukturnih resursa. Ako je infrastruktura loše osmišljena, a još više ako je arhitektura projekta i posebno baza podataka loše osmišljena, onda je to stvarno velika muka.
No jesu li skupni zahtjevi pouzdani kao što se čine? Pogledajmo slučaj: kreiramo korisnika, obogatimo njegov profil nekim opisom i pošaljemo mu SMS s tajnom za dovršetak registracije. Oni. tri poziva u jednom grupnom zahtjevu.
Pogledajmo dijagram. Predstavlja infrastrukturu s elementima visoke dostupnosti. Postoje dva neovisna komunikacijska kanala sa SMS gatewayima. Ali... što vidimo? Prilikom slanja SMS-a pojavljuje se greška 503 - usluga je privremeno nedostupna. Jer Slanje SMS-a pakirano je u skupni zahtjev, a zatim se cijeli zahtjev mora vratiti nazad. Akcije u DBMS-u su otkazane. Klijent prima grešku.
Sljedeći pokušaj je lutrija. Ili će zahtjev ponovo pogoditi isti čvor i opet vratiti pogrešku, ili ćete imati sreće i on će biti izvršen. Ali glavna stvar je da je barem jednom naša infrastruktura već radila uzalud. Opterećenje je bilo, ali nije bilo zarade.
Dobro, zamislimo da smo se napregli (!) i razmislili o opciji kada se zahtjev može djelomično uspješno ispuniti. A ostatak ćemo ponovno pokušati dovršiti nakon nekog vremenskog intervala (Koji? Odlučuje li fronta?). Ali lutrija je ostala ista. Zahtjev za slanje SMS-a ima 50/50 šanse da ponovno ne uspije.
Slažem se, sa strane klijenta, usluga se ne čini pouzdanom koliko bismo željeli... što je s REST-om?
REST ponovno koristi magiju HTTP-a, ali sada s kodovima odgovora. Kada se pojavi pogreška 503 na SMS pristupniku, pozadina emitira ovu pogrešku balanseru. Balanser prima ovu pogrešku i bez prekida veze s klijentom šalje zahtjev drugom čvoru, koji uspješno obrađuje zahtjev. Oni. klijent dobiva očekivani rezultat, a infrastruktura potvrđuje svoju visoku titulu „visoko pristupačne“. Korisnik je zadovoljan.
I opet to nije sve. Balanser nije samo primio kod odgovora 503. Prilikom odgovaranja, prema standardu, preporučljivo je dati ovaj kod sa zaglavljem "Ponovni pokušaj nakon". Zaglavlje balanseru jasno daje do znanja da se ne isplati ometati ovaj čvor na ovoj ruti određeno vrijeme. I sljedeći zahtjevi za slanje SMS-a bit će poslani izravno na čvor koji nema problema sa SMS pristupnikom.
Kao što vidimo, pouzdanost JSON-RPC-a je precijenjena. Doista, lakše je organizirati dosljednost u bazi podataka. Ali žrtva će u ovom slučaju biti pouzdanost sustava u cjelini.
Zaključak je uvelike sličan prethodnom. Kada je infrastruktura jednostavna, očiglednost JSON-RPC-a je definitivno plus. Ako projekt uključuje visoku dostupnost s velikim opterećenjem, REST izgleda kao ispravnije, iako kompleksnije rješenje.
Prag ulaska u REST je niži
Mislim da je gornja analiza, razotkrivajući ustaljene stereotipe o RPC-u, jasno pokazala da je prag za ulazak u REST nedvojbeno viši nego u RPC. To je zbog potrebe za dubokim razumijevanjem načina na koji HTTP funkcionira, kao i potrebe za posjedovanjem dovoljno znanja o postojećim infrastrukturnim elementima koji se mogu i trebaju koristiti u WEB projektima.
Pa zašto mnogi ljudi misle da će REST biti jednostavniji? Moje osobno mišljenje je da ova prividna jednostavnost dolazi od REST manifesta. Oni. REST nije protokol nego koncept... REST nema standard, postoje neke smjernice... REST nije ništa kompliciraniji od HTTP-a. Prividna sloboda i anarhija privlače “slobodne umjetnike”.
Naravno, REST nije ništa kompliciraniji od HTTP-a. Ali sam HTTP je dobro osmišljen protokol koji je dokazao svoju vrijednost tijekom desetljeća. Ako nema dubokog razumijevanja samog HTTP-a, onda se REST ne može suditi.
Ali o RPC-u - možete. Dovoljno je uzeti njegovu specifikaciju. Tako trebaš ? Ili je još uvijek nezgodan REST? Ti odluči.
Iskreno se nadam da vam nisam uzalud potrošio vrijeme.
Izvor: www.habr.com