Siguran sam da je naslov izazvao zdravu reakciju - "pa opet je počelo..." Ali dopustite mi da vam privučem pažnju na 5-10 minuta, i potrudiću se da ne razočaram očekivanja.
Struktura članka će biti ovakva: uzima se stereotipna tvrdnja i razrađuje se "priroda" nastanka tog stereotipa. Nadam se da će to omogućiti drugačiji pogled na izbor paradigme razmjene podataka u vašim projektima.
Da bismo imali jasnoću u vezi s tim šta je RPC, predlažem da razmatramo standard . Sa REST-om nema jasnoće. I ne bi trebalo biti. Sve što treba znati o REST-u - on se ne razlikuje od .
RPC zahtjevi su brži i efikasniji jer omogućavaju batch zahtjeve.
Radi se o tome da se u RPC-u može u jednom zahtjevu izvršiti poziv više procedura odjednom. Na primjer, kreirati korisnika, dodati mu avatar i u istom zahtjevu ga pretplatiti na određene teme. Samo jedan zahtjev, a koliko koristi!
Zaista, ako imate samo jedan backend čvor, to će se činiti bržim za batch zahtjev. Jer tri REST zahtjeva će zahtijevati tri puta više resursa od jednog čvora za uspostavljanje veza.
Obratite pažnju da prvi zahtjev u slučaju sa REST-om mora vratiti identifikator korisnika, kako bi se mogli izvesti naredni zahtjevi. Što također negativno utiče na ukupni rezultat.
Ali takve infrastrukture se mogu sresti, jedva, u in-house rješenjima i Enterprise. U krajnjem slučaju, u malim WEB projektima. A prava WEB rješenja, posebno ona nazivana HighLoad, se ne bi trebala graditi na ovaj način. Njihova infrastruktura treba da odgovara kriterijima visoke dostupnosti i opterećenja. A slika se mijenja.
Zeleno označeni su kanali aktivnosti infrastrukture pri istom scenariju. Obratite pažnju kako se RPC sada ponaša. Zahtjev koristi infrastrukturu samo preko jednog kraka od balansirnika do backenda. Dok REST i dalje gubi u prvom zahtjevu, ali nadoknađuje propušteno koristeći cijelu infrastrukturu.
Dovoljno je u scenarij uvesti ne dva zahtjeva za obogaćivanje, već, recimo, pet ili deset... i odgovor na pitanje "ko pobjeđuje sada?" postaje nejasan.
Predlažem da malo šire pogledamo na problem. Na dijagramu se vidi kako se koriste kanali infrastrukture, no infrastruktura se ne ograničava samo na kanale. Važan dio visoko opterećene infrastrukture su keševi. A sada hajde da dobijemo neki artefakt korisnika. Nekoliko puta. Recimo 32 puta.
Pogledajte kako je infrastrukturno “popravila” RPC da bi odgovarala zahtjevima visoke opterećenosti. Cijela stvar je u tome što REST koristi svu moć HTTP protokola, nasuprot RPC-u. Na prikazanom dijagramu ta moć se ostvaruje putem metode zahtjeva — GET.
HTTP metode, između ostalog, imaju strategije keširanja. Upoznati se s njima možete u dokumentaciji na . Za RPC se koriste POST zahtjevi, koji se ne smatraju idempotentnim, to jest višekratno ponavljanje istih POST zahtjeva može vraćati različite rezultate (na primjer, nakon svakog slanja komentara će se pojaviti nova kopija tog komentara) ().
Stoga, RPC nije u mogućnosti učinkovito koristiti infrastrukturne keševe. To dovodi do potrebe za “uvozom” softverskih keševa. Na dijagramu je u toj ulozi predstavljen Redis. Softverski keš, s druge strane, zahtijeva od programera dodatni kodni sloj i značajne promjene u arhitekturi.
Hajde sada da prebrojimo koliko je zahtjeva “stvorio” REST i RPC u razmatranoj infrastrukturi?
Upiti
Ulazni
k backendu
k SGBD-u
k softveru-više kešu (Redis)
UKUPNO
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] u najboljem slučaju (ako se koristi lokalni keš) 1 zahtjev (jedan!), u najgorem 32 ulazna zahtjeva.
U usporedbi s prvom shemom razlika je drastična. Sada postaje očita prednost REST-a. No, predlažem da ne stajemo ovdje. Razvijena infrastruktura uključuje CDN. Često on rješava i pitanje suprotstavljanja DDoS i DoS napadima. Dobijamo:
Tu za RPC sve postaje vrlo tužno. RPC jednostavno nije u mogućnosti delegirati rad s opterećenjem CDN-u. Ostat će nada samo u sustave protiv napada.
Može li se ovdje završiti? I opet, ne. HTTP metode, kao što je već rečeno, imaju svoju ‘magičnost’. I nije bez razloga što je GET metoda potpuno najkorištenija na internetu. Obratite pažnju da ova metoda može pristupiti dijelu sadržaja, može postavljati uvjete koje infrastrukturni elementi mogu interpretirati čak i prije nego što se kontrola preda vašem kodu itd. Sve to omogućava stvaranje fleksibilnih, upravljanih infrastruktura koje mogu procesirati zaista velike protoke zahtjeva. A u RPC ova metoda... se ignorira.
Zašto onda mit o tome da su batch zahtjevi (RPC) brži toliko otporan? Osobno mi se čini da većina projekata jednostavno ne doseže razinu razvoja na kojoj REST može pokazati svoju snagu. Štoviše, u malim projektima, rado pokazuje svoju slabost.
Odabir između REST-a i RPC-a nije isključiva odluka pojedinca u projektu. Ova odluka treba odgovarati zahtjevima projekta. Ako projekt može izvući iz REST-a sve ono što stvarno može, i to je zaista potrebno, tada će REST biti odličan izbor.
Ali ako je za postizanje svih prednosti REST-a potrebno zaposliti devopse za hitno skaliranje infrastrukture, administratore za upravljanje infrastrukturom, arhitekta za projektiranje svih slojeva WEB usluge... a projekt, pritom, prodaje tri paketa margarina dnevno... ja bih odustao od RPC-a, jer je ovaj protokol korisniji. Neće zahtijevati duboka znanja o radu cache-a i infrastrukture, već će fokusirati programera na jednostavne i razumljive pozive potrebnih mu procedura. Posao će biti zadovoljan.
RPC zahtjevi su pouzdaniji, jer mogu obavljati batch-zahtjeve unutar jedne transakcije.
Ova osobina RPC-a je nesumnjivo pogodnost, jer lako održava bazu podataka u dosljednom stanju. Međutim, s REST-om to postaje složenije. Zahtjevi mogu dolaziti nesequencijalno na različite backend čvorove.
Ova ‘manjkavost’ REST-a je suprotna strana njegove prednosti opisane više — sposobnost učinkovitog korištenja svih resursa infrastrukture. Ako je infrastruktura loše projektirana, a pogotovo ako je arhitektura projekta i baze podataka posebno loša, to može biti veliki problem.
Ali koliko su pouzdani batch upiti kao što se čine? Razmotrimo slučaj: kreiramo korisnika, obogaćujemo njegov profil nekim opisom i šaljemo mu SMS s tajnom za završetak registracije. To jest, tri poziva u jednom batch upitu.
Pogledajmo shemu. Na njoj je prikazana infrastruktura s elementima visoke dostupnosti. Postoje dva neovisna komunikacijska kanala s SMS gateway-ima. Ali... što vidimo? Prilikom slanja SMS-a javlja se pogreška 503 — usluga je privremeno nedostupna. Budući da je slanje SMS-a upakirano u batch upit, cijeli upit mora biti poništen. Akcije u Bazi podataka se poništavaju. Klijent dobiva pogrešku.
Sljedeći pokušaj — lutrija. Ili će upit ponovno završiti na istoj nodi i ponovno će vratiti pogrešku, ili će imati sreće i bit će izvršen. No glavno je to da je barem jednom naša infrastruktura već radila uzalud. Bilo je opterećenja, a profita nema.
Dobro, pretpostavimo da smo se potrudili (!) i razmislili o mogućnosti da upit može biti uspješno izvršen djelomično. A ostatak, pokušat ćemo ponovno izvršiti nakon nekog vremenskog intervala (Koji? Odluku donosi front?). No lutrija je ostala. Upit za slanje SMS-a s vjerojatnošću 50/50 ponovno će neuspjeti.
Slažete se, s gledišta klijenta, usluga ne izgleda toliko pouzdano koliko bi se htjelo… a što je s REST-om?
REST ponovno koristi “magiju” HTTP-a, ali sada s kodovima odgovora. Kada se javi pogreška 503 na SMS gateway-u, backend prenosi tu pogrešku ravnotežnom uređaju. Ravnotežni uređaj, primajući ovu pogrešku, i ne prekidajući vezu s klijentom, preusmjerava upit na drugu nodu koja uspješno obrađuje upit. To jest, klijent dobiva očekivani rezultat, a infrastruktura potvrđuje svoju visoku oznaku “visoko dostupna”. Korisnik je sretan.
I opet to nije sve. Ravnotežni uređaj ne samo da je dobio kod odgovora 503. Ovaj kod prilikom odgovora, prema standardu, poželjno je opremiti zaglavljem “Retry-After”. Zaglavlje jasno daje do znanja ravnotežnom uređaju da ne treba uznemiravati ovu nodu po ovom rutu tijekom određenog vremena. I sljedeći upiti za slanje SMS-a bit će usmjereni odmah na nodu koja nema problema s SMS gateway-om.
Kao što vidimo, pouzdanost JSON-RPC-a je precijenjena. Doista, lakše je organizirati dosljednost u Bazi podataka. No žrtva, u tom slučaju, bit će pouzdanost sustava u cijelosti.
Izlaz je uglavnom sličan prethodnom. Kada je infrastruktura jednostavna, jasnoća JSON-RPC-a nesumnjivo je njegova prednost. Ako projekt podrazumijeva visoku dostupnost s velikim opterećenjem, REST se čini kao ispravnije, iako složenije rješenje.
Prag ulaska u REST je niži
Mislim da je gornja analiza, koja razbija ustaljene stereotipe o RPC-u, jasno pokazala da je prag ulaska u REST nesumnjivo viši nego u RPC. To je povezano s potrebom za dubokim razumijevanjem rada HTTP-a, kao i s potrebom da se imaju dovoljna znanja o postojećim infrastrukturnim elementima koji se mogu i trebaju primjenjivati u WEB projektima.
Pa zašto mnogi misle da će REST biti jednostavniji? Moje osobno mišljenje je da ova prividna jednostavnost dolazi iz samih manifestacija REST-a. Naime, REST nije protokol, već koncept... REST nema standard, postoje neka preporučena pravila... REST nije teži od HTTP-a. Prividna sloboda i anarhija zovu 'slobodne umjetnike'.
Nesumnjivo, REST nije teži od HTTP-a. Ali sam HTTP je dobro osmišljen protokol koji je dokazao svoju sposobnost desetljećima. Ako nemate duboko razumijevanje samog HTTP-a, ne možete ni ocjenjivati REST.
A što se tiče RPC-a — može se. Dovoljno je uzeti njegovu specifikaciju. Dakle, treba li vam ? Или все же хитрый REST? Решать вам.
Iskreno se nadam da nisam uzalud izgubio vaše vrijeme.
Izvor: habr.com
