Prepričan sem, da je naslov sprožil zdravo reakcijo – "spet se je začelo..." Ampak pustite, da vam vzamem 5-10 minut vašega časa, in potrudil se bom, da ne razočaram pričakovanj.
Struktura članka bo takšna: vzeto bo stereotipno trditev in razkrila se bo "narava" nastanka tega stereotipa. Upam, da bo to omogočilo nov pogled na izbiro paradigme izmenjave podatkov v vaših projektih.
Da bo jasno, kaj RPC je, predlagam, da obravnavamo standard . Pri REST ni jasnosti. In tudi ne bi smela biti. Vse, kar morate vedeti o REST – je, da ni razlikovati od .
RPC zahteve so hitrejše in učinkovitejše, saj omogočajo batch zahteve.
Gre za to, da je pri RPC mogoče v eni zahtevi izvesti klic več postavitev hkrati. Na primer, ustvariti uporabnika, dodati mu avatar in ga v isti zahtevi naročiti na določene teme. Samo ena zahteva, koliko koristi!
Res je, če imate samo eno backend vozlišče, se bo to zdel hitrejši pri batch zahtevi. Ker tri REST zahteve zahtevajo trikrat več virov od enega vozlišča za vzpostavitev povezav.
Upoštevajte, da mora prva zahteva pri REST vrniti identifikator uporabnika za izvedbo naslednjih zahtev. To tudi negativno vpliva na skupni rezultat.
Toda take infrastrukture lahko najdemo le v in-house rešitvah in podjetjih. V skrajnem primeru, v manjših spletnih projektih. Prava spletna rešitev, imenovana HighLoad, se ne bi smela tako graditi. Njihova infrastruktura mora ustrezati kriterijem visoke dostopnosti in obremenitve. In slika se spremeni.
Zeleno so označeni kanali aktivnosti infrastrukture pri istem scenariju. Upoštevajte, kako se zdaj obnaša RPC. Zahteva uporablja infrastrukturo le po eni poti od balansirnika do backend-a. Medtem ko pri REST še vedno izgublja pri prvi zahtevi, pa nadoknadi zamujeno z izkoriščanjem celotne infrastrukture.
Dovolj je, da v scenarij vnesete ne dve zahtevi za obogatitev, temveč, recimo, pet ali deset... in odgovor na vprašanje "kdo zdaj zmaga?" postane nejasen.
Predlagam, da si še širše ogledamo težavo. Na shemi je razvidno, kako se uporabljajo infrastrukturni kanali, vendar infrastruktura ne omejuje le na kanale. Pomembna sestavina visoko obremenjene infrastrukture so predpomnilniki. Poglejmo zdaj kakšen uporabniški artefakt. Večkrat. Recimo 32-krat.
Poglejte, kako se je infrastruktura na RPC precej 'popravila', da bi izpolnila zahteve visoke obremenitve. Vse je v tem, da REST izkorišča vso moč HTTP protokola v nasprotju z RPC. Na prikazani shemi se ta moč uresničuje preko metode zahtevka — GET.
HTTP metode imajo, poleg drugega, strategije predpomnjenja. Spoznate jih lahko v dokumentaciji na . Za RPC se uporabljajo POST zahtevki, ki niso obravnavani kot idempotentni, kar pomeni, da lahko večkratno ponavljanje istih POST zahtevkov vrača različne rezultate (npr. po vsakem pošiljanju komentarja se bo pojavila nova kopija tega komentarja) ().
Zato RPC ne more učinkovito izkoristiti infrastrukturnih predpomnilnikov. To vodi v potrebo po 'uvozu' programskih predpomnilnikov. Na shemi je v tej vlogi predstavljen Redis. Programski predpomnilnik pa od razvijalca zahteva dodatno kodo in opazne spremembe v arhitekturi.
Poglejmo zdaj, koliko zahtevkov je 'rodil' REST in RPC v obravnavani infrastrukturi?
Poizvedbe
Prejeto
k backendu
k BDS
k programskemu predpomnilniku (Redis)
SKUPAJ
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] v najboljšem primeru (če se lokalni predpomnilnik uporablja) 1 zahtevek (en!), v najslabšem primeru 32 prihodnjih zahtevkov.
V primerjavi s prvo shemo je razlika ostra. Zdaj je očitno, da ima REST prednost. Vendar ne predlagam, da se ustavimo pri tem. Razvita infrastruktura vključuje CDN. Pogosto tudi rešuje problem proti DDoS in DoS napadom. Dobimo:
Tukaj za RPC postane situacija precej obupna. RPC preprosto ne more delegirati dela na obremenitvi CDN. Ostaja nam le upanje na sisteme za preprečevanje napadov.
Ali lahko tukaj zaključimo? In ponovno, ne. HTTP metode, kot je bilo omenjeno zgoraj, imajo svojo „magijo“. In ni naključje, da je metoda GET popolnoma razširjena v internetu. Upoštevajte, da ta metoda lahko dostopa do dela vsebine, postavlja pogoje, ki jih lahko infrastrukturni elementi interpretirajo še pred prenosom nadzora vašemu kodi itd. Vse to omogoča ustvarjanje prilagodljivih, upravljanih infrastrukturnih rešitev, ki zmorejo obvladovati res velike tokove zahtev. In v RPC ta metoda... se ignorira.
Zakaj torej mit o tem, da so batch zahtevki (RPC) hitrejši, vztraja? Osebno menim, da večina projektov preprosto ne doseže tiste stopnje razvoja, kjer REST lahko pokaže svojo moč. Poleg tega v manjših projektih raje pokaže svoje slabosti.
Izbira med REST in RPC ni voljna izbira posameznika v projektu. Ta izbira mora zadostiti potrebam projekta. Če projekt lahko iz REST-a izkoristi vse to, kar dejansko lahko, in to resnično potrebujemo, bo REST odlična izbira.
Ampak, če bo za pridobitev vseh koristi REST-a treba najeti devopse za hitro širitev infrastrukture, skrbnike za upravljanje infrastrukture, arhitekta za načrtovanje vseh plasti WEB storitve... in projekt pri tem prodaja tri pakete margarinske maščobe na dan... bi se raje ustavil na RPC, ker je ta protokol bolj utilitarističen. Ne zahteva globokih znanj o delovanju predpomnilnikov in infrastrukture, temveč osredotoča razvijalca na preproste in jasne klice potrebnih mu postopkov. Posel bo zadovoljen.
RPC zahtevki so zanesljivejši, ker lahko izvajajo batch-zahtevke znotraj ene transakcije.
Ta lastnost RPC je nedvomna prednost, saj je enostavno ohranjati bazo podatkov v doslednem stanju. Z REST-om pa je vse težje. Zahtevki lahko prihajajo nepovezano na različne backend vozlišča.
Ta "slabost" REST-a je obrnjena stran njegove prednosti, opisane zgoraj - sposobnost učinkovite uporabe vseh virov infrastrukture. Če je infrastruktura slabo zasnovana, še posebej če je tudi arhitektura projekta in baze podatkov slaba, potem je to resna težava.
Toda miška batch заявки tako zanesljive, kot se zdijo? Poglejmo primer: ustvarimo uporabnika, obogatimo njegov profil z opisom in mu pošljemo SMS s skrivnostjo za dokončanje registracije. To pomeni tri klice v eni batch izjavi.
Poglejmo shemo. Na njej je prikazana infrastruktura z elementi visoke razpoložljivosti. Obstajata dva neodvisna komunikacijska kanala s SMS prehodi. Ampak ... kaj vidimo? Pri pošiljanju SMS pride do napake 503 — storitev je začasno nedostopna. Ker je pošiljanje SMS vključeno v batch izjavo, se mora celotna izjema razveljaviti. Dejavnosti v SDB se prekličejo. Stranka prejme napako.
Naslednji poskus je loterija. Bodisi bo zahteva spet šla na isto vozlišče in ponovno vrnila napako, bodisi bo imela srečo in bo uspešno izvedena. Pomembno pa je, da je naša infrastruktura vsaj enkrat že delala zaman. Obremenitev je bila, koristi pa ni bilo.
No, predstavljajmo si, da smo se potrudili (!) in premislili možnost, da lahko zahteva uspešno delno izvede. Preostanek, bomo ponovno poskusili izvesti po nekem časovnem intervalu (Kakšnem? Odloča sprednji del?). Ampak loterija je ostala enaka. Zahteva za pošiljanje SMS bo z verjetnostjo 50/50 ponovno propadla.
Strinjate se, da se storitev z vidika stranke ne zdi tako zanesljiva, kot bi si želeli ... kaj pa REST?
REST spet uporablja 'magijo' HTTP, tokrat s kodo odgovorov. Ko pride do napake 503 na SMS prehodu, backend to napako posreduje uravnoteževalniku obremenitve. Uravnoteževalnik, prejemajući to napako in ne prekinjajoč povezave s stranko, usmeri zahtevo na drugo vozlišče, ki uspešno obdeluje zahtevo. To pomeni, da stranka prejme pričakovani rezultat, infrastruktura pa potrjuje svoje visoko ime 'visoko razpoložljivo'. Uporabnik je srečen.
In to še ni vse. Uravnoteževalnik ni prejel le kode odgovora 503. Ta koda mora biti v skladu s standardom, pri odgovoru obdarjena z glavo 'Retry-After'. Glava daje uravnoteževalniku vedeti, da ni smiselno obremenjevati tega vozlišča po tej poti v določenem času. Naslednje zahteve za pošiljanje SMS-ov bodo tako usmerjene neposredno na vozlišče, ki nima težav s SMS prehodom.
Kot vidimo, je zanesljivost JSON-RPC precenjena. Res je, da je lažje organizirati doslednost v SDB. Toda žrtev v takem primeru bo zanesljivost sistema kot celote.
Izhod je v mnogih pogledih podoben prejšnjemu. Ko je infrastruktura preprosta, je očitnost JSON-RPC nedvomno njegova prednost. Če projekt zahteva visoko razpoložljivost z veliko obremenitvijo, se REST zdi boljša izbira, čeprav je kompleksnejša rešitev.
Vstopna ovira za REST je nižja.
Mislim, da je zgoraj predstavljena analiza, ki razbija ustaljene stereotipe o RPC, jasno pokazala, da je vstopna ovira za REST nedvomno višja kot za RPC. To je povezano z nujnostjo globokega razumevanja delovanja HTTP, pa tudi s potrebnimi znanji o obstoječih infrastrukturnih elementih, ki jih lahko in je treba uporabljati v spletnih projektih.
Zakaj torej mnogi menijo, da bo REST lažji? Moje osebno mnenje je, da ta očitna enostavnost izhaja iz samih manifestov REST. Torej, REST ni protokol, temveč koncept ... REST nima standarda, obstajajo nekatera priporočila ... REST ni težji od HTTP. Očitna svoboda in anarhija privlačita "svobodne umetnike".
Nedvomno, REST ni težji od HTTP. Toda sam HTTP je dobro premišljen protokol, ki je dokazal svojo zanesljivost desetletja. Če ni globokega razumevanja samega HTTP, o RESTu ne moremo soditi.
O RPC pa lahko. Dovolj je, da vzamete njegovo specifikacijo. Torej, ali potrebujete ? Или все же хитрый REST? Решать вам.
Iskreno upam, da nisem zaman izgubil vašega časa.
Izvor: habr.com
