Prepričan sem, da je naslov povzročil zdravo reakcijo - "no, spet se je začelo ..." Ampak dovolite mi, da pritegnem vašo pozornost za 5-10 minut in poskušal bom ne razočarati vaših pričakovanj.
Struktura članka bo naslednja: vzeta je stereotipna izjava in razkrita je "narava" nastanka tega stereotipa. Upam, da vam bo to omogočilo pogled na izbiro paradigme izmenjave podatkov v vaših projektih z novega zornega kota.
Da bi bilo jasno, kaj je RPC, predlagam, da razmislimo o standardu . Z REST ni jasnosti. In ne bi smelo biti. Vse, kar morate vedeti o RESTu - se od njega ne razlikuje .
Zahteve RPC so hitrejše in učinkovitejše, ker vam omogočajo, da naredite paketne zahteve.
Bistvo je, da lahko v RPC v eni zahtevi pokličete več postopkov hkrati. Na primer, ustvarite uporabnika, mu dodajte avatar in ga v isti zahtevi naročite na nekatere teme. Samo ena zahteva in koliko koristi!
Če imate samo eno zaledno vozlišče, se bo zdelo hitreje s paketno zahtevo. Ker bodo tri zahteve REST zahtevale trikrat več sredstev iz enega vozlišča za vzpostavitev povezav.
Upoštevajte, da mora prva zahteva v primeru REST vrniti ID uporabnika, da se lahko izvedejo naslednje zahteve. Kar tudi negativno vpliva na skupni rezultat.
Toda takšne infrastrukture je mogoče najti samo v internih rešitvah in podjetjih. V skrajnem primeru pri majhnih WEB projektih. Toda polnopravnih SPLETNIH rešitev, tudi tistih, ki se imenujejo HighLoad, ni vredno graditi. Njihova infrastruktura mora ustrezati kriterijem visoke razpoložljivosti in obremenitve. In slika se spreminja.
Kanali infrastrukturne dejavnosti po istem scenariju so označeni z zeleno. Opazite, kako se zdaj obnaša RPC. Zahteva uporablja infrastrukturo samo na eni strani od izravnalnika do zaledja. Čeprav REST še vedno izgubi pri prvi zahtevi, nadoknadi izgubljeni čas z uporabo celotne infrastrukture.
Dovolj je, da v scenarij vnesete ne dve zahtevi za obogatitev, ampak recimo pet ali deset ... in odgovor na vprašanje "kdo zdaj zmaga?" postane nejasno.
Predlagam, da na problem pogledamo še širše. Diagram prikazuje, kako se uporabljajo infrastrukturni kanali, vendar infrastruktura ni omejena na kanale. Pomemben sestavni del visoko obremenjene infrastrukture so predpomnilniki. Zdaj dobimo nekakšen uporabniški artefakt. Večkrat. Recimo 32-krat.
Oglejte si, kako se je infrastruktura RPC znatno izboljšala, da bi izpolnila zahteve visoke obremenitve. Stvar je v tem, da REST uporablja polno moč protokola HTTP, za razliko od RPC. V zgornjem diagramu je ta moč realizirana z metodo zahteve - GET.
Metode HTTP imajo med drugim tudi strategije predpomnjenja. Najdete jih v dokumentaciji na . Za RPC se uporabljajo zahteve POST, ki se ne štejejo za idempotentne, kar pomeni, da ponavljajoče se ponavljanje istih zahtev POST lahko vrnejo različne rezultate (na primer, po vsakem poslanem komentarju se pojavi še ena kopija tega komentarja) ().
Posledično RPC ne more učinkovito uporabljati infrastrukturnih predpomnilnikov. To vodi do potrebe po "uvozu" predpomnilnikov programske opreme. Diagram prikazuje Redis v tej vlogi. Predpomnilnik programske opreme pa od razvijalca zahteva, da doda dodatno plast kode in opazne spremembe v arhitekturi.
Preštejmo zdaj, koliko zahtev sta REST in RPC “rodila” v obravnavani infrastrukturi?
zahteve
Prejeto
v zaledje
v DBMS
v mehki predpomnilnik (Redis)
SKUPAJ
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
V primerjavi s prvo shemo je razlika presenetljiva. Zdaj postane korist REST jasna. Vendar predlagam, da se ne ustavite pri tem. Razvita infrastruktura vključuje CDN. Pogosto rešuje tudi vprašanje boja proti napadom DDoS in DoS. Dobimo:
Tu postanejo stvari za RPC zelo slabe. RPC preprosto ni sposoben prenesti delovne obremenitve na CDN. Za boj proti napadom se lahko zanesemo samo na sisteme.
Je mogoče tukaj končati? In spet ne. Metode HTTP, kot je omenjeno zgoraj, imajo svojo »čarovnijo«. In ni brez razloga, da se metoda GET pogosto uporablja na internetu. Upoštevajte, da lahko ta metoda dostopa do dela vsebine, lahko nastavi pogoje, ki jih lahko infrastrukturni elementi interpretirajo, preden se nadzor prenese na vašo kodo itd. Vse to vam omogoča, da ustvarite prilagodljive, obvladljive infrastrukture, ki lahko obravnavajo res velike tokove zahtev. Toda v RPC je ta metoda ... prezrta.
Zakaj je torej mit, da so paketne zahteve (RPC) hitrejše, tako vztrajen? Osebno se mi zdi, da večina projektov preprosto ne doseže stopnje razvoja, kjer bi REST lahko pokazal svojo moč. Poleg tega je v majhnih projektih bolj pripravljen pokazati svoje slabosti.
Izbira REST ali RPC ni prostovoljna izbira posameznika v projektu. Ta izbira mora ustrezati zahtevam projekta. Če je projekt sposoben iz REST-a iztisniti vse, kar res lahko, in to res potrebuje, potem bo REST odlična izbira.
Če pa morate, da bi izkoristili vse prednosti REST, za projekt najeti strokovnjake za devops za hitro nadgradnjo infrastrukture, skrbnike za upravljanje infrastrukture, arhitekta za oblikovanje vseh plasti spletne storitve ... in projekt , hkrati pa proda tri zavitke margarine na dan ... Jaz bi ostal pri RPC, ker ... ta protokol je bolj uporaben. Ne bo zahtevalo poglobljenega znanja o delovanju predpomnilnikov in infrastrukture, ampak bo razvijalca osredotočilo na preproste in razumljive klice postopkov, ki jih potrebuje. Posel bo vesel.
Zahteve RPC so bolj zanesljive, ker lahko izvajajo paketne zahteve znotraj ene transakcije
Ta lastnost RPC je nedvomna prednost, ker Zbirko podatkov je enostavno vzdrževati skladno. Toda z REST postaja vse bolj zapleteno. Zahteve lahko pridejo nedosledno do različnih zalednih vozlišč.
Ta "slabost" REST-a je hrbtna stran njegove zgoraj opisane prednosti - zmožnost učinkovite uporabe vseh infrastrukturnih virov. Če je infrastruktura slabo zasnovana, še bolj pa, če sta arhitektura projekta in predvsem baza podatkov slabo zasnovana, potem je to res velika muka.
Toda ali so paketne zahteve 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. Tisti. trije klici v eni paketni zahtevi.
Poglejmo diagram. Predstavlja infrastrukturo z elementi visoke razpoložljivosti. Obstajata dva neodvisna komunikacijska kanala s prehodi SMS. Toda ... kaj vidimo? Pri pošiljanju SMS-a se pojavi napaka 503 - storitev začasno ni na voljo. Ker Pošiljanje SMS je zapakirano v paketno zahtevo, nato pa je treba celotno zahtevo povrniti nazaj. Dejanja v DBMS so preklicana. Stranka prejme napako.
Naslednji poskus je loterija. Zahteva bo znova dosegla isto vozlišče in znova vrnila napako ali pa boste imeli srečo in bo izvedena. A glavno je, da je vsaj enkrat naša infrastruktura že delovala zaman. Obremenitev je bila, dobička pa ne.
V redu, predstavljajmo si, da smo se napeli (!) in razmislili o možnosti, ko je zahtevo mogoče delno uspešno zaključiti. Ostalo pa bomo poskušali dokončati znova po določenem časovnem intervalu (Katerem? Ali odloča fronta?). Toda loterija je ostala enaka. Zahteva za pošiljanje SMS-a ima 50/50 možnosti, da ponovno ne uspe.
Strinjam se, s strani stranke se storitev ne zdi tako zanesljiva, kot bi si želeli ... kaj pa REST?
REST ponovno uporablja čarobnost HTTP, vendar zdaj z odzivnimi kodami. Ko pride do napake 503 na prehodu SMS, zaledje to napako odda izravnalniku. Balancer prejme to napako in brez prekinitve povezave z odjemalcem pošlje zahtevo drugemu vozlišču, ki zahtevo uspešno obdela. Tisti. naročnik prejme pričakovan rezultat, infrastruktura pa potrdi svoj visok naziv »visoko dostopna«. Uporabnik je zadovoljen.
In spet to še ni vse. Balancer ni le prejel kode odgovora 503. Pri odzivu je v skladu s standardom priporočljivo, da to kodo navedete z glavo »Poskusi znova«. Glava daje izravnalcu jasno vedeti, da ni vredno vznemirjati tega vozlišča na tej poti za določen čas. In naslednje zahteve za pošiljanje SMS bodo poslane neposredno vozlišču, ki nima težav s prehodom SMS.
Kot lahko vidimo, je zanesljivost JSON-RPC precenjena. Dejansko je lažje organizirati doslednost v bazi podatkov. Toda žrtev bo v tem primeru zanesljivost sistema kot celote.
Zaključek je v veliki meri podoben prejšnjemu. Ko je infrastruktura preprosta, je očitnost JSON-RPC zagotovo plus. Če projekt vključuje visoko razpoložljivost z visoko obremenitvijo, je REST videti bolj pravilna, čeprav bolj kompleksna rešitev.
Vstopni prag za REST je nižji
Mislim, da je zgornja analiza, ki razbija ustaljene stereotipe o RPC, jasno pokazala, da je prag za vstop v REST nedvomno višji kot v RPC. To je posledica potrebe po globokem razumevanju delovanja HTTP, pa tudi potrebe po zadostnem znanju o obstoječih infrastrukturnih elementih, ki jih je mogoče in jih je treba uporabiti v spletnih projektih.
Zakaj torej veliko ljudi misli, da bo REST enostavnejši? Moje osebno mnenje je, da ta navidezna preprostost izvira iz samih manifestov REST. Tisti. REST ni protokol, ampak koncept ... REST nima standarda, obstajajo nekatere smernice ... REST ni nič bolj zapleten kot HTTP. Navidezna svoboda in anarhija privlačita »svobodne umetnike«.
Seveda REST ni nič bolj zapleten kot HTTP. Toda sam HTTP je dobro zasnovan protokol, ki je v desetletjih dokazal svojo vrednost. Če ni globokega razumevanja samega HTTP-ja, potem REST-a ni mogoče oceniti.
Ampak glede RPC - lahko. Dovolj je, da vzamete njegovo specifikacijo. Torej potrebujete ? Ali pa je še vedno zapleten REST? Ti odločaš.
Iskreno upam, da nisem zapravil vašega časa.
Vir: www.habr.com