Sigurado ako na ang headline ay nagdulot ng malusog na reaksyon - "well, it's started again..." Ngunit hayaan mo akong kunin ang iyong pansin sa loob ng 5-10 minuto, at susubukan kong huwag biguin ang iyong mga inaasahan.
Ang istraktura ng artikulo ay ang mga sumusunod: ang isang stereotypical na pahayag ay kinuha at ang "kalikasan" ng paglitaw ng stereotype na ito ay ipinahayag. Umaasa ako na ito ay magbibigay-daan sa iyo upang tingnan ang pagpili ng data exchange paradigm sa iyong mga proyekto mula sa isang bagong anggulo.
Upang maging malinaw kung ano ang RPC, iminumungkahi kong isaalang-alang ang pamantayan . Sa REST walang kalinawan. At hindi dapat. Lahat ng kailangan mong malaman tungkol sa REST - ito ay hindi makikilala mula sa .
Ang mga kahilingan sa RPC ay mas mabilis at mas mahusay dahil pinapayagan ka nitong gumawa ng mga batch na kahilingan.
Ang punto ay na sa RPC maaari kang tumawag ng ilang mga pamamaraan nang sabay-sabay sa isang kahilingan. Halimbawa, lumikha ng isang user, magdagdag ng isang avatar sa kanya at, sa parehong kahilingan, i-subscribe siya sa ilang mga paksa. Isang kahilingan lang, at magkano ang benepisyo!
Sa katunayan, kung mayroon ka lamang isang backend node, ito ay tila mas mabilis sa isang batch na kahilingan. Dahil ang tatlong REST na kahilingan ay mangangailangan ng tatlong beses na mas maraming mapagkukunan mula sa isang node upang magtatag ng mga koneksyon.
Tandaan na ang unang kahilingan sa kaso ng REST ay dapat ibalik ang user ID upang magawa ang mga kasunod na kahilingan. Na negatibong nakakaapekto rin sa pangkalahatang resulta.
Ngunit ang mga naturang imprastraktura ay matatagpuan lamang sa mga in-house na solusyon at Enterprise. Bilang huling paraan, sa maliliit na proyekto sa WEB. Ngunit ang mga ganap na solusyon sa WEB, at maging ang mga tinatawag na HighLoad, ay hindi nagkakahalaga ng pagbuo. Ang kanilang imprastraktura ay dapat matugunan ang pamantayan ng mataas na kakayahang magamit at pagkarga. At nagbabago ang larawan.
Ang mga channel ng aktibidad sa imprastraktura sa ilalim ng parehong senaryo ay minarkahan ng berde. Pansinin kung paano kumikilos ang RPC ngayon. Ginagamit ng kahilingan ang imprastraktura sa isang paa lamang mula sa balancer hanggang sa backend. Habang natatalo pa rin ang REST sa unang kahilingan, binabawi nito ang nawalang oras gamit ang buong imprastraktura.
Sapat na ang pumasok sa script hindi ang dalawang kahilingan para sa pagpapayaman, ngunit, sabihin nating, lima o sampu... at ang sagot sa tanong na "sino ang nanalo ngayon?" nagiging malabo.
Iminumungkahi kong tingnan ang problema nang mas malawak. Ipinapakita ng diagram kung paano ginagamit ang mga channel sa imprastraktura, ngunit hindi limitado sa mga channel ang imprastraktura. Ang isang mahalagang bahagi ng isang high-load na imprastraktura ay ang mga cache. Kumuha tayo ngayon ng ilang uri ng artifact ng user. Paulit-ulit. Sabihin nating 32 beses.
Tingnan kung paano bumuti nang husto ang imprastraktura ng RPC upang matugunan ang mga pangangailangan ng mataas na pagkarga. Ang bagay ay ang REST ay gumagamit ng buong kapangyarihan ng HTTP protocol, hindi katulad ng RPC. Sa diagram sa itaas, ang kapangyarihang ito ay natanto sa pamamagitan ng paraan ng kahilingan - GET.
Ang mga pamamaraan ng HTTP, bukod sa iba pang mga bagay, ay may mga diskarte sa pag-cache. Maaari mong mahanap ang mga ito sa dokumentasyon sa . Para sa RPC, ginagamit ang mga kahilingan sa POST, na hindi itinuturing na idempotent, ibig sabihin, ang mga paulit-ulit na pag-uulit ng parehong mga kahilingan sa POST ay maaaring magbalik ng magkakaibang mga resulta (halimbawa, pagkatapos maipadala ang bawat komento, lalabas ang isa pang kopya ng komentong ito) ().
Dahil dito, hindi epektibong magamit ng RPC ang mga cache ng imprastraktura. Ito ay humahantong sa pangangailangan na "mag-import" ng mga cache ng software. Ipinapakita ng diagram si Redis sa papel na ito. Ang cache ng software, sa turn, ay nangangailangan ng developer na magdagdag ng karagdagang layer ng code at mga kapansin-pansing pagbabago sa arkitektura.
Bilangin natin ngayon kung gaano karaming mga kahilingan ang REST at RPC na "isinilang" sa imprastraktura na isinasaalang-alang?
kahilingan
Inbox
sa backend
sa DBMS
sa soft cache (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Kung ikukumpara sa unang pamamaraan, ang pagkakaiba ay kapansin-pansin. Ngayon ang benepisyo ng REST ay nagiging malinaw. Ngunit iminumungkahi ko na huwag tumigil doon. Kasama sa binuong imprastraktura ang isang CDN. Kadalasan ay nalulutas din nito ang isyu ng pagkontra sa mga pag-atake ng DDoS at DoS. Nakukuha namin:
Dito nagiging masama ang mga bagay para sa RPC. Hindi lang kaya ng RPC na italaga ang workload sa isang CDN. Maaari lang tayong umasa sa mga system para kontrahin ang mga pag-atake.
Posible bang dito na matapos? At muli, hindi. Ang mga pamamaraan ng HTTP, tulad ng nabanggit sa itaas, ay may sariling "magic". At hindi walang dahilan na ang pamamaraang GET ay malawakang ginagamit sa Internet. Tandaan na ang pamamaraang ito ay nakakapag-access ng isang piraso ng nilalaman, nakakapagtakda ng mga kundisyon na maaaring bigyang-kahulugan ng mga elemento ng imprastraktura bago mailipat ang kontrol sa iyong code, at iba pa. Binibigyang-daan ka ng lahat ng ito na lumikha ng nababaluktot, napapamahalaang mga imprastraktura na kayang humawak ng talagang malalaking daloy ng mga kahilingan. Ngunit sa RPC ang pamamaraang ito... ay binabalewala.
Kaya't bakit ang mitolohiya na ang mga kahilingan ng batch (RPC) ay mas mabilis kaya nagpapatuloy? Sa personal, tila sa akin na ang karamihan sa mga proyekto ay hindi lamang umabot sa isang antas ng pag-unlad kung saan ang REST ay naipakita ang lakas nito. Bukod dito, sa mga maliliit na proyekto, mas handa siyang ipakita ang kanyang mga kahinaan.
Ang pagpili ng REST o RPC ay hindi boluntaryong pagpili ng isang indibidwal sa isang proyekto. Ang pagpipiliang ito ay dapat matugunan ang mga kinakailangan ng proyekto. Kung ang isang proyekto ay magagawang pisilin ang lahat ng bagay na talagang magagawa nito sa REST, at talagang kailangan nito, kung gayon ang REST ay magiging isang mahusay na pagpipilian.
Ngunit kung, para makuha ang lahat ng benepisyo ng REST, kailangan mong kumuha ng mga devops na espesyalista para sa proyekto upang mabilis na ma-scale ang imprastraktura, mga administrador para pamahalaan ang imprastraktura, isang arkitekto upang magdisenyo ng lahat ng mga layer ng serbisyo ng WEB... at ang proyekto , sabay benta ng tatlong pakete ng margarine sa isang araw... I would stick with RPC, kasi... mas utilitarian ang protocol na ito. Hindi ito mangangailangan ng malalim na kaalaman sa kung paano gumagana ang mga cache at imprastraktura, ngunit itutuon ang developer sa mga simple at mauunawaang tawag sa mga pamamaraang kailangan niya. Magiging masaya ang negosyo.
Ang mga kahilingan sa RPC ay mas maaasahan dahil maaari silang magsagawa ng mga kahilingan sa batch sa loob ng iisang transaksyon
Ang pag-aari na ito ng RPC ay isang tiyak na kalamangan, dahil Madaling panatilihing pare-pareho ang database. Ngunit sa REST ito ay nagiging mas kumplikado. Maaaring dumating nang hindi pare-pareho ang mga kahilingan sa iba't ibang backend node.
Ang "kapinsalaan" na ito ng REST ay ang flip side ng kalamangan nito na inilarawan sa itaas - ang kakayahang magamit nang mahusay ang lahat ng mapagkukunan ng imprastraktura. Kung ang imprastraktura ay hindi maganda ang disenyo, at higit pa kung ang arkitektura ng proyekto at ang database sa partikular ay hindi maganda ang disenyo, kung gayon ito ay talagang isang malaking sakit.
Ngunit ang mga batch na kahilingan ba ay kasing maaasahan ng tila? Tingnan natin ang isang kaso: lumikha kami ng isang user, pagyamanin ang kanyang profile gamit ang ilang paglalarawan at padalhan siya ng SMS na may lihim upang makumpleto ang pagpaparehistro. Yung. tatlong tawag sa isang batch na kahilingan.
Tingnan natin ang diagram. Nagpapakita ito ng isang imprastraktura na may mataas na mga elemento ng kakayahang magamit. Mayroong dalawang independiyenteng mga channel ng komunikasyon na may mga SMS gateway. Ngunit... ano ang nakikita natin? Kapag nagpapadala ng SMS, nangyayari ang isang error 503 - pansamantalang hindi magagamit ang serbisyo. kasi Ang pagpapadala ng SMS ay nakabalot sa isang batch na kahilingan, pagkatapos ay dapat ibalik ang buong kahilingan. Kinansela ang mga pagkilos sa DBMS. Nakatanggap ng error ang kliyente.
Ang susunod na pagsubok ay ang lottery. Alinman sa kahilingan ay pindutin ang parehong node muli at muli magbabalik ng isang error, o ikaw ay mapalad at ito ay isasagawa. Ngunit ang pangunahing bagay ay na kahit minsan ang ating imprastraktura ay gumana nang walang kabuluhan. May load, pero walang tubo.
Okay, isipin natin na pinaghirapan natin ang ating sarili (!) at pinag-isipan ang opsyon kapag matagumpay na nakumpleto ang kahilingan. At susubukan naming kumpletuhin muli ang natitira pagkatapos ng ilang oras na pagitan (Alin? Ang harap ba ang magpapasya?). Ngunit ang lottery ay nanatiling pareho. Ang kahilingang magpadala ng SMS ay may 50/50 na pagkakataong mabigo muli.
Sumang-ayon, mula sa panig ng kliyente, ang serbisyo ay tila hindi maaasahan gaya ng gusto namin... paano naman ang REST?
Ginagamit muli ng REST ang magic ng HTTP, ngunit ngayon ay may mga response code. Kapag may naganap na error 503 sa SMS gateway, ibina-broadcast ng backend ang error na ito sa balancer. Natatanggap ng balancer ang error na ito at nang hindi sinira ang koneksyon sa kliyente, ipinapadala ang kahilingan sa isa pang node, na matagumpay na nagpoproseso ng kahilingan. Yung. natatanggap ng kliyente ang inaasahang resulta, at kinukumpirma ng imprastraktura ang mataas na titulong "highly accessible". Ang gumagamit ay masaya.
At muli hindi lang iyon. Ang balancer ay hindi lamang nakatanggap ng response code na 503. Kapag tumugon, ayon sa pamantayan, ipinapayong ibigay ang code na ito sa header na "Retry-After". Nilinaw ng header sa balancer na hindi sulit na abalahin ang node na ito sa rutang ito para sa isang tinukoy na oras. At ang mga susunod na kahilingang magpadala ng SMS ay direktang ipapadala sa isang node na walang problema sa SMS gateway.
Tulad ng nakikita natin, ang pagiging maaasahan ng JSON-RPC ay overrated. Sa katunayan, mas madaling ayusin ang pagkakapare-pareho sa database. Ngunit ang sakripisyo, sa kasong ito, ay ang pagiging maaasahan ng sistema sa kabuuan.
Ang konklusyon ay higit na katulad sa nauna. Kapag ang imprastraktura ay simple, ang pagiging malinaw ng JSON-RPC ay talagang isang plus. Kung ang proyekto ay nagsasangkot ng mataas na kakayahang magamit na may mataas na pagkarga, ang REST ay mukhang isang mas tama, bagama't mas kumplikado, na solusyon.
Ang threshold ng pagpasok sa REST ay mas mababa
Sa tingin ko, ang pagsusuri sa itaas, na nagpapawalang-bisa sa mga naitatag na stereotype tungkol sa RPC, ay malinaw na nagpakita na ang threshold para sa pagpasok sa REST ay walang alinlangan na mas mataas kaysa sa RPC. Ito ay dahil sa pangangailangan para sa isang malalim na pag-unawa sa kung paano gumagana ang HTTP, pati na rin ang pangangailangan na magkaroon ng sapat na kaalaman tungkol sa mga umiiral na elemento ng imprastraktura na maaari at dapat gamitin sa mga proyekto sa WEB.
Kaya bakit iniisip ng maraming tao na magiging mas simple ang REST? Ang aking personal na opinyon ay ang maliwanag na pagiging simple na ito ay nagmumula sa REST na nagpapakita mismo. Yung. Ang REST ay hindi isang protocol ngunit isang konsepto... Ang REST ay walang pamantayan, mayroong ilang mga alituntunin... Ang REST ay hindi mas kumplikado kaysa sa HTTP. Ang maliwanag na kalayaan at anarkiya ay umaakit ng "mga malayang artista".
Siyempre, ang REST ay hindi mas kumplikado kaysa sa HTTP. Ngunit ang HTTP mismo ay isang mahusay na dinisenyo na protocol na napatunayan ang halaga nito sa loob ng mga dekada. Kung walang malalim na pag-unawa sa HTTP mismo, hindi maaaring hatulan ang REST.
Ngunit tungkol sa RPC - maaari mo. Ito ay sapat na upang kunin ang pagtutukoy nito. Kaya kailangan mo ? O nakakalito pa rin ang REST? Ikaw ang magdesisyon.
Taos-puso akong umaasa na hindi ko sinayang ang iyong oras.
Pinagmulan: www.habr.com