Siguran sam da je naslov izazvao zdravu reakciju - "pa, opet je počelo..." Ali dozvolite mi da vam privučem pažnju na 5-10 minuta, pa ću se truditi da ne prevarim očekivanja.
Struktura članka će biti sljedeća: uzima se stereotipna izjava i otkriva se „priroda“ nastanka ovog stereotipa. Nadam se da će vam ovo omogućiti da sagledate izbor paradigme razmjene podataka u vašim projektima iz novog ugla.
Da bi bilo jasno šta je RPC, predlažem da razmotrimo standard . Nema jasnoće sa REST-om. I ne bi trebalo da bude. Sve što trebate znati o REST-u je da se ne razlikuje od njega .
RPC zahtjevi su brži i efikasniji jer vam omogućavaju da napravite paketne zahtjeve.
Poenta je da je u RPC-u moguće pozvati nekoliko procedura odjednom u jednom zahtjevu. Na primjer, kreirajte korisnika, dodajte mu avatar i pretplatite ga na neke teme u istom zahtjevu. Samo jedan zahtjev, a koliko pogodnosti!
Zaista, ako imate samo jedan pozadinski čvor, činit će se bržim sa batch zahtjevom. Zato što će tri REST zahtjeva zahtijevati tri puta više resursa iz jednog čvora za uspostavljanje veza.
Imajte na umu da prvi zahtjev u slučaju REST-a mora vratiti korisnički ID da bi mogao napraviti sljedeće zahtjeve. Što također negativno utiče na ukupni rezultat.
Ali takve infrastrukture se možda mogu naći u internim rešenjima i Enterprise. U krajnjem slučaju, u malim WEB projektima. Ali punopravna WEB rješenja, pa čak i nazvana HighLoad, ne bi se trebala tako graditi. Njihova infrastruktura mora zadovoljiti kriterije visoke dostupnosti i opterećenja. I slika se menja.
Zelenom bojom su označeni kanali infrastrukturnih aktivnosti po istom scenariju. Obratite pažnju kako se RPC ponaša sada. Zahtjev koristi infrastrukturu samo na jednom ramenu od balansera do backenda. Dok REST i dalje gubi u prvom zahtjevu, ali sustiže koristeći cijelu infrastrukturu.
Dovoljno je upisati u scenarij ne dva zahtjeva za bogaćenje, već, recimo, pet ili deset... i odgovor na pitanje "ko sada pobjeđuje?" postaje nevidljiv.
Predlažem da se problem sagleda šire. Dijagram pokazuje kako se infrastrukturni kanali koriste, ali infrastruktura nije ograničena na kanale. Keš memorije su važna komponenta visoko opterećene infrastrukture. Hajde sada da uzmemo neki korisnički artefakt. Ponavljano. Recimo 32 puta.
Pogledajte kako se infrastruktura na RPC-u primjetno „oporavila“ kako bi ispunila zahtjeve visokog opterećenja. Stvar je u tome što REST koristi punu snagu HTTP protokola, za razliku od RPC-a. U gornjem dijagramu ova snaga se realizuje metodom zahtjeva - GET.
HTTP metode, između ostalog, imaju strategije keširanja. Možete ih pronaći u dokumentaciji na . Za RPC se koriste POST zahtjevi, koji se ne smatraju idempotentnima, odnosno ponovljeno ponavljanje istih POST zahtjeva može dati različite rezultate (na primjer, nakon svakog poslanog komentara, pojavit će se još jedna kopija ovog komentara) ().
Shodno tome, RPC nije u stanju da efikasno koristi infrastrukturne keš memorije. To dovodi do činjenice da morate "uvoziti" meke keš memorije. Dijagram prikazuje Redis u ovoj ulozi. Soft cache, zauzvrat, zahtijeva dodatni sloj koda i primjetne promjene u arhitekturi od programera.
Hajde sada da izračunamo koliko je zahtjeva REST i RPC "porodilo" u infrastrukturi koja se razmatra?
Zahtjevi
inbox
to backend
na DBMS
u meku keš memoriju (Redis)
UKUPNO
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
U poređenju sa prvom šemom, razlika je upadljiva. Sada je korist od REST-a očigledna. Ali predlažem da se tu ne zaustavlja. Razvijena infrastruktura uključuje CDN. Često rješava i pitanje suprotstavljanja DDoS i DoS napadima. Dobijamo:
Ovdje za RPC sve postaje prilično žalosno. RPC jednostavno nije u mogućnosti delegirati posao na CDN opterećenje. Možemo se samo nadati sistemima za suzbijanje napada.
Može li se tu završiti? I opet, ne. HTTP metode, kao što je gore spomenuto, imaju svoju "magiju". I nije uzalud što se metoda GET u potpunosti koristi na Internetu. Imajte na umu da ova metoda može pristupiti dijelu sadržaja, može postaviti uslove koje infrastrukturni elementi mogu interpretirati prije nego što prenesu kontrolu vašem kodu, itd. Sve ovo vam omogućava da kreirate fleksibilnu infrastrukturu kojom se može upravljati koja može da obradi zaista velike zahteve. A u RPC-u ovaj metod se ... ignoriše.
Pa zašto je mit da su batch zahtjevi (RPC) brži tako uporan? Lično mi se čini da većina projekata jednostavno ne dostiže takav nivo razvoja kada REST može da pokaže svoju snagu. Štaviše, u malim projektima, spremniji je pokazati svoju slabost.
Izbor REST-a ili RPC-a nije voljni izbor pojedinca u projektu. Ovaj izbor mora zadovoljiti zahtjeve projekta. Ako je projekat u stanju da iz REST-a istisne sve što zaista može, a to mu je zaista potrebno, onda je REST odličan izbor.
Ali ako da biste ostvarili sav REST profit, morate unajmiti devope za projekat koji će brzo skalirati infrastrukturu, administratore za upravljanje infrastrukturom, arhitektu da dizajnira sve slojeve WEB servisa... i projekt, na u isto vrijeme, prodaje tri pakovanja margarina dnevno... stao bih na RPC, tk. ovaj protokol je utilitarniji. Ne zahtijeva duboko poznavanje rada keš memorije i infrastrukture, ali će programera fokusirati na jednostavne i razumljive pozive procedurama koje su mu potrebne. Posao će biti sretan.
RPC zahtjevi su pouzdaniji jer mogu izvršiti paketne zahtjeve unutar jedne transakcije
Ovo svojstvo RPC-a je definitivno plus, jer lako je održavati bazu podataka u konzistentnom stanju. Ali sa REST-om postaje sve teže. Zahtjevi mogu doći nedosljedno različitim pozadinskim čvorovima.
Ova "mana" REST-a je suprotna strana njegove prednosti opisane gore - sposobnosti da se efikasno koriste svi infrastrukturni resursi. Ako je infrastruktura loše dizajnirana, a još više ako su arhitektura projekta i posebno baza podataka loše dizajnirani, onda je to zaista velika muka.
Ali da li su paketni zahtjevi pouzdani kao što se čine? Razmotrimo slučaj: kreiramo korisnika, obogatimo njegov profil nekim opisom i pošaljemo mu SMS sa tajnom da završi registraciju. One. tri poziva u jednom paketnom zahtjevu.
Razmotrimo dijagram. Predstavlja infrastrukturu sa elementima visoke dostupnosti. Postoje dva nezavisna komunikacijska kanala sa SMS gateway-ima. Ali… šta vidimo? Prilikom slanja SMS-a javlja se greška 503 - usluga je privremeno nedostupna. Jer slanje SMS-a je upakovano u paketni zahtev, a zatim ceo zahtev treba da se vrati nazad. Akcije u DBMS-u su otkazane. Klijent dobija grešku.
Sljedeći pokušaj je lutrija. Ili će zahtjev ponovo pasti na isti čvor i ponovo vratiti grešku, ili ćete imati sreće i bit će izvršen. Ali glavna stvar je da je barem jednom naša infrastruktura već uzalud radila. Bilo je opterećenja, ali nije bilo profita.
U redu, zamislimo da smo se napeli (!) i razmišljali o opciji kada se zahtjev može djelomično uspješno izvršiti. A ostalo ćemo ponovo pokušati izvršiti nakon nekog vremenskog intervala (Šta? Odlučuje front?). Ali lutrija je ostala ista. Zahtjev za slanje SMS-a sa šansom 50/50 opet neće uspjeti.
Slažem se, sa strane klijenta, usluga ne izgleda tako pouzdana koliko bismo željeli... ali šta je sa REST-om?
REST ponovo koristi "magiju" HTTP-a, ali sada sa kodovima odgovora. Kada se pojavi greška 503 na SMS gateway-u, pozadina emituje ovu grešku balanseru. Balanser koji primi ovu grešku i bez prekida veze sa klijentom, šalje zahtjev drugom čvoru, koji uspješno obrađuje zahtjev. One. klijent dobija očekivani rezultat, a infrastruktura potvrđuje svoju visoku titulu „visoko pristupačne“. Korisnik je zadovoljan.
I opet, to nije sve. Balanser nije dobio samo kod odgovora 503. Prema standardu, poželjno je da se ovaj kod dostavi sa zaglavljem “Retry-After” kada odgovara. Naslov jasno stavlja do znanja balanseru da se ovaj čvor ne smije ometati na ovoj ruti tokom određenog vremena. I sljedeći zahtjevi za slanje SMS-a biće odmah poslati čvoru koji nema problema sa SMS gateway-om.
Kao što vidimo, pouzdanost JSON-RPC-a je precijenjena. Zaista, lakše je organizirati konzistentnost u bazi podataka. Ali žrtva će, u ovom slučaju, biti pouzdanost sistema u cjelini.
Zaključak je u velikoj mjeri sličan prethodnom. Kada je infrastruktura jednostavna, očiglednost JSON-RPC-a je definitivno plus. Ako projekat uključuje visoku dostupnost sa velikim opterećenjem, REST izgleda kao ispravnije, ali složenije rješenje.
REST Donji prag ulaska
Mislim da je gornja analiza, koja je razotkrila ustaljene stereotipe o RPC-u, jasno pokazala da je ulazni prag za REST nesumnjivo veći nego za RPC. To je zbog potrebe za dubljim razumijevanjem rada HTTP-a, 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 misle da će REST biti jednostavniji? Moje lično mišljenje je da ova prividna jednostavnost dolazi od OSTALE manifestacije. One. REST nije protokol, već koncept... REST nema standard, postoje neke smjernice... REST nije ništa komplikovaniji od HTTP-a. Prividna sloboda i anarhija privlače "slobodne umjetnike".
Bez sumnje, REST nije ništa komplikovaniji od HTTP-a. Ali sam HTTP je dobro osmišljen protokol koji je dokazao svoju vrijednost decenijama. 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 da ti treba ? Ili je još uvijek nezgodno REST? Ti odluci.
Iskreno se nadam da nisam gubio vaše vrijeme.
izvor: www.habr.com