JSON-RPC? Pagkuha ug malisud nga PAHULAY

Sigurado ko nga ang ulohan nagpahinabo sa usa ka himsog nga reaksyon - "maayo, nagsugod na usab ..." Apan tugoti ako nga makuha ang imong atensyon sa 5-10 minuto, ug sulayan nako nga dili mahigawad ang imong mga gilauman.

Ang istruktura sa artikulo mahimong ingon sa mosunod: usa ka stereotypical nga pahayag ang gikuha ug ang "kinaiyahan" sa pagtunga niini nga stereotype gipadayag. Nanghinaut ko nga kini magtugot kanimo sa pagtan-aw sa pagpili sa data exchange paradigm sa imong mga proyekto gikan sa usa ka bag-ong anggulo.

Aron klaro kung unsa ang RPC, gisugyot nako nga tagdon ang sumbanan JSON-RPC 2.0. Sa REST walay klaro. Ug dili unta. Ang tanan nga kinahanglan nimong mahibal-an bahin sa REST - dili kini mailhan http.

Ang mga hangyo sa RPC mas paspas ug mas episyente tungod kay gitugotan ka nila nga maghimo mga hangyo sa batch.

Ang punto mao nga sa RPC mahimo nimong tawagan ang daghang mga pamaagi sa usa ka hangyo. Pananglitan, paghimo usa ka tiggamit, pagdugang usa ka avatar kaniya ug, sa parehas nga hangyo, i-subscribe siya sa pipila ka mga hilisgutan. Usa lang ka hangyo, ug unsa ka dako ang kaayohan!

Sa tinuud, kung ikaw adunay usa ra ka backend node, kini daw mas paspas sa usa ka batch nga hangyo. Tungod kay ang tulo ka REST nga mga hangyo manginahanglan tulo ka beses nga dugang nga mga kapanguhaan gikan sa usa ka node aron makatukod mga koneksyon.

Timan-i nga ang unang hangyo sa kaso sa REST kinahanglang ibalik ang user ID aron mahimo ang sunod nga mga hangyo. Nga negatibo usab makaapekto sa kinatibuk-ang resulta.

Apan ang ingon nga mga imprastraktura makit-an ra sa mga in-house nga solusyon ug Enterprise. Ingon usa ka katapusan nga paagi, sa gagmay nga mga proyekto sa WEB. Apan ang bug-os nga mga solusyon sa WEB, ug bisan kadtong gitawag nga HighLoad, dili takus sa pagtukod. Ang ilang imprastraktura kinahanglan nga makab-ot ang mga pamatasan sa taas nga pagkaanaa ug pagkarga. Ug ang hulagway nagbag-o.

Ang mga agianan sa kalihokan sa imprastraktura sa ilawom sa parehas nga senaryo gimarkahan nga berde. Matikdi kung giunsa ang paggawi sa RPC karon. Ang hangyo naggamit sa imprastraktura sa usa ra ka tiil gikan sa balanse hangtod sa backend. Samtang napildi gihapon ang REST sa una nga hangyo, kini naghimo sa nawala nga oras gamit ang tibuuk nga imprastraktura.

Igo na nga mosulod sa script dili duha ka hangyo alang sa pagpalambo, apan, ingnon ta, lima o napulo ... ug ang tubag sa pangutana nga "kinsa ang nakadaog karon?" mahimong dili klaro.

Gisugyot ko nga mas lapad pa ang pagtan-aw sa problema. Gipakita sa diagram kung giunsa gigamit ang mga channel sa imprastraktura, apan ang imprastraktura dili limitado sa mga kanal. Usa ka importante nga bahin sa usa ka high-load nga imprastraktura mao ang mga cache. Magkuha ta karon og usa ka matang sa user artifact. Gibalikbalik. Ingnon ta 32 ka beses.

Tan-awa kung giunsa ang pag-uswag sa imprastraktura sa RPC aron matubag ang mga gipangayo nga taas nga karga. Ang butang mao nga ang REST naggamit sa bug-os nga gahum sa HTTP protocol, dili sama sa RPC. Sa dayagram sa ibabaw, kini nga gahum matuman pinaagi sa pamaagi sa paghangyo - GET.

Ang mga pamaagi sa HTTP, lakip sa ubang mga butang, adunay mga estratehiya sa pag-cache. Makita nimo sila sa dokumentasyon sa http. Alang sa RPC, gigamit ang mga hangyo sa POST, nga wala gikonsiderar nga idempotent, nga mao, ang balik-balik nga pagsubli sa parehas nga mga hangyo sa POST mahimong magbalik sa lainlaing mga resulta (pananglitan, pagkahuman ipadala ang matag komento, lain nga kopya niini nga komento ang makita) (tinubdan).

Tungod niini, ang RPC dili makahimo sa epektibong paggamit sa mga cache sa imprastraktura. Kini modala ngadto sa panginahanglan sa "import" software caches. Gipakita sa diagram si Redis sa kini nga tahas. Ang cache sa software, sa baylo, nanginahanglan sa developer nga magdugang usa ka dugang nga layer sa code ug mamatikdan nga mga pagbag-o sa arkitektura.

Atong isipon karon kung pila ang mga hangyo sa REST ug RPC nga "gipanganak" sa mga imprastraktura nga gikonsiderar?

Mga hangyo
Inbox
sa backend
ngadto sa DBMS
sa humok nga cache (Redis)
TOTAL

PAHULAY
1 / 32 *
1
1
0
3 / 35

CPR
32
32
1
31
96

[*] sa labing maayo nga kaso (kung gigamit ang lokal nga cache) 1 hangyo (usa!), sa labing grabe nga kaso 32 nga umaabot nga mga hangyo.

Kon itandi sa unang laraw, ang kalainan talagsaon. Karon ang kaayohan sa REST nahimong klaro. Apan gisugyot ko nga dili mohunong didto. Ang naugmad nga imprastraktura naglakip sa usa ka CDN. Kasagaran masulbad usab niini ang isyu sa pagbatok sa mga pag-atake sa DDoS ug DoS. Atong makuha:

Dinhi diin ang mga butang mahimong dili maayo alang sa RPC. Ang RPC yano nga dili makahimo sa pagdelegar sa workload sa usa ka CDN. Kita makasalig lamang sa mga sistema sa pagbatok sa mga pag-atake.

Posible ba nga matapos dinhi? Ug pag-usab, dili. Ang mga pamaagi sa HTTP, sama sa gihisgutan sa ibabaw, adunay ilang kaugalingong "salamangka". Ug dili kini walay rason nga ang GET nga pamaagi kaylap nga gigamit sa Internet. Timan-i nga kini nga pamaagi makahimo sa pag-access sa usa ka piraso sa sulod, makahimo sa pagtakda sa mga kondisyon nga ang mga elemento sa imprastraktura makahubad sa dili pa ang kontrol ibalhin sa imong code, ug uban pa. Ang tanan niini nagtugot kanimo sa paghimo og flexible, madumala nga mga imprastraktura nga makadumala sa dako kaayo nga pag-agos sa mga hangyo. Apan sa RPC kini nga pamaagi ... gibalewala.

Busa ngano nga ang tumotumo nga ang mga hangyo sa batch (RPC) mas paspas nga nagpadayon? Sa personal, ingon nako nga kadaghanan sa mga proyekto wala gyud makaabut sa lebel sa pag-uswag diin ang REST makahimo sa pagpakita sa kusog niini. Dugang pa, sa gagmay nga mga proyekto, mas andam siyang magpakita sa iyang mga kahuyang.

Ang pagpili sa REST o RPC dili usa ka boluntaryong pagpili sa usa ka indibidwal sa usa ka proyekto. Kini nga pagpili kinahanglan nga makab-ot ang mga kinahanglanon sa proyekto. Kung ang usa ka proyekto makahimo sa pagpiit sa tanan nga mahimo niini gikan sa REST, ug kinahanglan gyud kini, nan ang REST usa ka maayo nga kapilian.

Apan kung, aron makuha ang tanan nga mga benepisyo sa REST, kinahanglan nimo nga mag-hire og mga espesyalista sa devops alang sa proyekto aron dali nga ma-scale ang imprastraktura, mga administrador sa pagdumala sa imprastraktura, usa ka arkitekto nga magdesinyo sa tanan nga mga layer sa serbisyo sa WEB ... ug ang proyekto. , sa samang higayon, namaligya ug tulo ka pakete sa margarine kada adlaw... Mopilit ko sa RPC, kay... kini nga protocol mas utilitarian. Dili kini magkinahanglan og lawom nga kahibalo kung giunsa ang mga cache ug imprastraktura molihok, apan ipunting ang developer sa yano ug masabtan nga mga tawag sa mga pamaagi nga iyang gikinahanglan. Ang negosyo mahimong malipayon.

Ang mga hangyo sa RPC mas kasaligan tungod kay mahimo nilang ipatuman ang mga hangyo sa batch sulod sa usa ka transaksyon

Kini nga kabtangan sa RPC usa ka tino nga bentaha, tungod kay Sayon nga huptan nga makanunayon ang database. Apan sa REST kini mahimong mas komplikado. Ang mga hangyo mahimong moabut nga dili managsama sa lainlaing mga backend node.

Kini nga "kakulangan" sa REST mao ang pikas nga bahin sa iyang bentaha nga gihulagway sa ibabaw - ang katakus nga epektibo nga magamit ang tanan nga mga kapanguhaan sa imprastraktura. Kung ang imprastraktura dili maayo nga gidisenyo, ug labi pa kung ang arkitektura sa proyekto ug ang database labi na dili maayo nga gidisenyo, nan kini usa ka dako nga kasakit.

Apan ang mga hangyo ba sa batch ingon ka kasaligan sa ilang hitsura? Atong tan-awon ang usa ka kaso: naghimo kami usa ka tiggamit, gipauswag ang iyang profile sa pipila nga paghulagway ug gipadala siya usa ka SMS nga adunay sekreto aron makompleto ang pagrehistro. Mga. tulo ka tawag sa usa ka batch nga hangyo.

Atong tan-awon ang diagram. Nagpresentar kini og usa ka imprastraktura nga adunay taas nga magamit nga mga elemento. Adunay duha ka independenteng mga channel sa komunikasyon nga adunay mga SMS gateway. Apan... unsay atong nakita? Kung nagpadala usa ka SMS, usa ka sayup 503 ang nahitabo - ang serbisyo temporaryo nga wala magamit. Kay Ang pagpadala sa SMS giputos sa usa ka batch nga hangyo, unya ang tibuok nga hangyo kinahanglang ibalik. Ang mga aksyon sa DBMS gikansela. Ang kliyente nakadawat usa ka sayup.

Ang sunod nga pagsulay mao ang loterya. Bisan ang hangyo moigo sa parehas nga node balik-balik nga magbalik usa ka sayup, o ikaw swerte ug kini ipatuman. Apan ang nag-unang butang mao nga bisan sa usa ka higayon nga ang atong mga imprastraktura nagtrabaho sa kawang. Adunay usa ka karga, apan walay ganansya.

Okay, atong huna-hunaon nga gipugos nato ang atong kaugalingon (!) Ug paningkamutan namon nga makompleto pag-usab ang nahabilin pagkahuman sa pila ka oras nga agwat (Hain usa? Ang atubangan ba ang nagdesisyon?). Apan ang loterya nagpabilin nga pareho. Ang hangyo nga ipadala ang SMS adunay 50/50 nga higayon nga mapakyas pag-usab.

Uyon, gikan sa bahin sa kliyente, ang serbisyo ingon og dili kasaligan sama sa among gusto ... unsa man ang REST?

Ang REST naggamit sa salamangka sa HTTP pag-usab, apan karon adunay mga code sa pagtubag. Kung ang usa ka sayup nga 503 mahitabo sa SMS gateway, ang backend nagsibya niini nga sayup sa balancer. Ang balancer nakadawat niini nga sayup ug sa walay pagbungkag sa koneksyon sa kliyente, nagpadala sa hangyo ngadto sa laing node, nga malampuson nga nagproseso sa hangyo. Mga. ang kliyente makadawat sa gipaabot nga resulta, ug ang imprastraktura nagpamatuod sa taas nga titulo niini nga "magamit kaayo". Nalipay ang user.

Ug usab dili kana ang tanan. Ang balancer dili lang makadawat sa tubag nga code sa 503. Sa pagtubag, sumala sa sumbanan, kini mao ang advisable sa paghatag niini nga code uban sa "Sulayi-Pagkahuman" header. Gipatin-aw sa header sa balancer nga dili kini angay nga disturbohon kini nga node sa kini nga ruta sa usa ka piho nga oras. Ug ang sunod nga mga hangyo sa pagpadala sa SMS ipadala direkta sa usa ka node nga walay mga problema sa SMS gateway.

Sama sa atong makita, ang pagkakasaligan sa JSON-RPC sobra ra ang gibug-aton. Sa tinuud, mas dali ang pag-organisar sa pagkamakanunayon sa database. Apan ang sakripisyo, sa kini nga kaso, mao ang kasaligan sa sistema sa kinatibuk-an.

Ang konklusyon sa kadaghanan susama sa nauna. Kung yano ang imprastraktura, ang klaro sa JSON-RPC siguradong usa ka dugang. Kung ang proyekto naglakip sa taas nga magamit nga adunay taas nga karga, ang REST morag mas husto, bisan pa mas komplikado, nga solusyon.

Ang entry threshold sa REST mas ubos

Sa akong hunahuna nga ang pag-analisar sa ibabaw, nga nagsalikway sa natukod nga mga stereotype bahin sa RPC, tin-aw nga nagpakita nga ang threshold sa pagsulod sa REST sa walay duhaduha mas taas kaysa sa RPC. Kini tungod sa panginahanglan alang sa usa ka lawom nga pagsabut kung giunsa ang HTTP nagtrabaho, ingon man ang panginahanglan nga adunay igo nga kahibalo bahin sa mga naglungtad nga mga elemento sa imprastraktura nga mahimo ug kinahanglan gamiton sa mga proyekto sa WEB.

Busa nganong daghang mga tawo ang naghunahuna nga ang REST mahimong mas simple? Ang akong personal nga opinyon mao nga kini nga dayag nga kayano naggikan sa REST nga gipakita sa ilang kaugalingon. Mga. Ang REST dili usa ka protocol apan usa ka konsepto ... Ang REST wala’y sukaranan, adunay pipila nga mga panudlo ... Ang REST dili labi ka komplikado kaysa HTTP. Ang dayag nga kagawasan ug anarkiya nakadani sa "libre nga mga artista".

Siyempre, ang REST dili labi ka komplikado kaysa HTTP. Apan ang HTTP mismo usa ka maayong pagkadisenyo nga protocol nga napamatud-an ang kantidad niini sa daghang mga dekada. Kung walay lawom nga pagsabot sa HTTP mismo, nan ang REST dili mahukman.

Apan bahin sa RPC - mahimo nimo. Igo na ang pagkuha sa espesipikasyon niini. Busa kinahanglan ba nimo buang nga JSON-RPC? O malisud pa ba ang PAGPAHULAY? Ikaw ang magdesisyon.

Ako kinasingkasing nga naglaum nga ako wala mag-usik sa imong panahon.

Source: www.habr.com