Nina hakika kuwa kichwa cha habari kilisababisha athari nzuri - "vizuri, imeanza tena ..." Lakini wacha nichukue umakini wako kwa dakika 5-10, na nitajaribu kutokukatisha tamaa matarajio yako.
Muundo wa kifungu hicho utakuwa kama ifuatavyo: taarifa ya kawaida inachukuliwa na "asili" ya kuibuka kwa stereotype hii imefunuliwa. Natumai hii itakuruhusu kutazama chaguo la dhana ya kubadilishana data katika miradi yako kutoka kwa pembe mpya.
Ili kuwa wazi juu ya RPC ni nini, ninapendekeza kuzingatia kiwango . Kwa REST hakuna uwazi. Na haipaswi kuwa. Kila kitu unachohitaji kujua kuhusu REST - hakiwezi kutofautishwa nacho .
Maombi ya RPC ni ya haraka na yanafaa zaidi kwa sababu yanakuruhusu kutuma maombi ya kundi.
Jambo ni kwamba katika RPC unaweza kupiga taratibu kadhaa mara moja katika ombi moja. Kwa mfano, unda mtumiaji, ongeza avatar kwake na, kwa ombi sawa, umsajili kwa mada fulani. Ombi moja tu, na faida ngapi!
Hakika, ikiwa una nodi moja tu ya nyuma, itaonekana haraka na ombi la kundi. Kwa sababu maombi matatu ya REST yatahitaji rasilimali mara tatu zaidi kutoka kwa nodi moja ili kuanzisha miunganisho.
Kumbuka kwamba ombi la kwanza katika kesi ya REST lazima lirudishe kitambulisho cha mtumiaji ili maombi yanayofuata yafanywe. Ambayo pia huathiri vibaya matokeo ya jumla.
Lakini miundombinu kama hiyo inaweza kupatikana tu katika suluhisho za ndani na Biashara. Kama mapumziko ya mwisho, katika miradi midogo ya WEB. Lakini suluhisho kamili za WEB, na hata zile zinazoitwa HighLoad, hazifai kujengwa. Miundombinu yao lazima ikidhi vigezo vya upatikanaji wa juu na mzigo. Na picha inabadilika.
Njia za shughuli za miundombinu chini ya hali sawa zimetiwa alama ya kijani. Angalia jinsi RPC inavyofanya sasa. Ombi hutumia miundombinu kwenye mguu mmoja tu kutoka kwa usawa hadi nyuma. Wakati REST bado inapotea katika ombi la kwanza, hurekebisha muda uliopotea kwa kutumia miundombinu yote.
Inatosha kuingia kwenye hati sio maombi mawili ya utajiri, lakini, sema, tano au kumi ... na jibu la swali "nani anashinda sasa?" inakuwa haijulikani.
Ninapendekeza kuangalia kwa upana zaidi shida. Mchoro unaonyesha jinsi njia za miundombinu zinavyotumika, lakini miundombinu sio tu kwa njia. Sehemu muhimu ya miundombinu yenye mzigo mkubwa ni kache. Hebu sasa tupate aina fulani ya vizalia vya mtumiaji. Mara kwa mara. Wacha tuseme mara 32.
Tazama jinsi miundombinu ya RPC imeboreshwa kwa kiasi kikubwa ili kukidhi mahitaji ya mzigo mkubwa. Jambo ni kwamba REST hutumia nguvu kamili ya itifaki ya HTTP, tofauti na RPC. Katika mchoro hapo juu, nguvu hii inatekelezwa kupitia njia ya ombi - GET.
Njia za HTTP, kati ya mambo mengine, zina mikakati ya kuhifadhi. Unaweza kupata yao katika nyaraka katika . Kwa RPC, maombi ya POST hutumiwa, ambayo hayazingatiwi kuwa duni, yaani, marudio ya mara kwa mara ya maombi yale yale ya POST yanaweza kurudisha matokeo tofauti (kwa mfano, baada ya kila maoni kutumwa, nakala nyingine ya maoni haya itaonekana) ().
Kwa hivyo, RPC haiwezi kutumia vyema akiba ya miundombinu. Hii inasababisha haja ya "kuagiza" cache za programu. Mchoro unaonyesha Redis katika jukumu hili. Cache ya programu, kwa upande wake, inahitaji msanidi programu kuongeza safu ya ziada ya msimbo na mabadiliko yanayoonekana katika usanifu.
Hebu sasa tuhesabu ni maombi mangapi ya REST na RPC "alijifungua" katika miundombinu inayozingatiwa?
Maombi
kisanduku pokezi
kurudisha nyuma
kwa DBMS
kwa kache laini (Redis)
JUMLA
WALIOBAKI
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Ikilinganishwa na mpango wa kwanza, tofauti ni ya kushangaza. Sasa faida ya REST inakuwa wazi. Lakini napendekeza usiishie hapo. Miundombinu iliyotengenezwa ni pamoja na CDN. Mara nyingi pia hutatua suala la kukabiliana na mashambulizi ya DDoS na DoS. Tunapata:
Hapa ndipo mambo yanakuwa mabaya sana kwa RPC. RPC haina uwezo wa kukabidhi mzigo wa kazi kwa CDN. Tunaweza tu kutegemea mifumo ili kukabiliana na mashambulizi.
Je, inawezekana kuishia hapa? Na tena, hapana. Njia za HTTP, kama ilivyotajwa hapo juu, zina "uchawi" wao wenyewe. Na sio bila sababu kwamba njia ya GET inatumiwa sana kwenye mtandao. Kumbuka kwamba njia hii inaweza kufikia kipande cha maudhui, inaweza kuweka masharti ambayo vipengele vya miundombinu vinaweza kutafsiri kabla ya udhibiti kuhamishiwa kwenye msimbo wako, na kadhalika. Haya yote hukuruhusu kuunda miundomsingi inayoweza kunyumbulika, inayoweza kudhibitiwa ambayo inaweza kushughulikia mtiririko mkubwa wa maombi. Lakini katika RPC njia hii ... inapuuzwa.
Kwa hivyo ni kwa nini hadithi kwamba maombi ya kundi (RPC) yanaendelea haraka sana? Binafsi, inaonekana kwangu kuwa miradi mingi haifikii kiwango cha maendeleo ambapo REST inaweza kuonyesha nguvu zake. Aidha, katika miradi midogo, yuko tayari zaidi kuonyesha udhaifu wake.
Chaguo la REST au RPC si chaguo la hiari la mtu binafsi katika mradi. Chaguo hili lazima likidhi mahitaji ya mradi. Ikiwa mradi unaweza kubana kila kitu unachoweza kutoka kwa REST, na unaihitaji sana, basi REST itakuwa chaguo bora.
Lakini ikiwa, ili kupata faida zote za REST, unahitaji kuajiri wataalamu wa devops kwa mradi ili kuongeza haraka miundombinu, wasimamizi wa kusimamia miundombinu, mbunifu wa kubuni tabaka zote za huduma ya WEB ... na mradi huo. , wakati huo huo, huuza pakiti tatu za majarini kwa siku ... Ningependa kushikamana na RPC, kwa sababu ... itifaki hii ni ya matumizi zaidi. Haitahitaji ujuzi wa kina wa jinsi kache na miundombinu zinavyofanya kazi, lakini italenga msanidi programu kwenye simu rahisi na zinazoeleweka kwa taratibu anazohitaji. Biashara itakuwa na furaha.
Maombi ya RPC yanategemewa zaidi kwa sababu yanaweza kutekeleza maombi ya kundi ndani ya shughuli moja
Mali hii ya RPC ni faida ya uhakika, kwa sababu Ni rahisi kuweka hifadhidata thabiti. Lakini kwa REST inakuwa ngumu zaidi na zaidi. Maombi yanaweza kuwasili kwa njia tofauti kwa nodi tofauti za nyuma.
"Hasara" hii ya REST ni upande wa pili wa faida yake iliyoelezwa hapo juu - uwezo wa kutumia rasilimali zote za miundombinu. Ikiwa miundombinu imeundwa vibaya, na hata zaidi ikiwa usanifu wa mradi na hifadhidata hasa imeundwa vibaya, basi hii ni maumivu makubwa sana.
Lakini maombi ya kundi ni ya kuaminika kama yanavyoonekana? Hebu tuangalie kesi: tunaunda mtumiaji, kuimarisha wasifu wake na maelezo fulani na kumtumia SMS na siri ya kukamilisha usajili. Wale. simu tatu katika ombi la kundi moja.
Hebu tuangalie mchoro. Inatoa miundombinu yenye vipengele vya upatikanaji wa juu. Kuna njia mbili za mawasiliano huru zilizo na lango la SMS. Lakini ... tunaona nini? Wakati wa kutuma SMS, hitilafu 503 hutokea - huduma haipatikani kwa muda. Kwa sababu Utumaji SMS huwekwa katika ombi la kundi, basi ombi lote lazima lirudishwe. Vitendo katika DBMS vimeghairiwa. Mteja hupokea hitilafu.
Jaribio linalofuata ni bahati nasibu. Labda ombi litagonga nodi sawa tena na tena kurudisha kosa, au utakuwa na bahati na itatekelezwa. Lakini jambo kuu ni kwamba angalau mara moja miundombinu yetu tayari imefanya kazi bure. Kulikuwa na mzigo, lakini hakuna faida.
Sawa, wacha tufikirie kuwa tumejikaza (!) na tukafikiria chaguo wakati ombi linaweza kukamilika kwa mafanikio. Na tutajaribu kukamilisha mengine tena baada ya muda fulani (Ni lipi? Je! Mbele huamua?). Lakini bahati nasibu ilibaki sawa. Ombi la kutuma SMS lina uwezekano wa 50/50 kutofaulu tena.
Kubali, kutoka kwa upande wa mteja, huduma haionekani kuwa ya kutegemewa kama tungependa... vipi kuhusu REST?
REST hutumia uchawi wa HTTP tena, lakini sasa na misimbo ya majibu. Hitilafu 503 inapotokea kwenye lango la SMS, sehemu ya nyuma hutangaza kosa hili kwa kiweka sawa. Msawazishaji hupokea kosa hili na bila kuvunja uunganisho na mteja, hutuma ombi kwa node nyingine, ambayo inashughulikia ombi kwa mafanikio. Wale. mteja hupokea matokeo yaliyotarajiwa, na miundombinu inathibitisha kichwa chake cha juu cha "kupatikana sana". Mtumiaji ana furaha.
Na tena hiyo sio yote. Msawazishaji hakupokea tu msimbo wa majibu wa 503. Wakati wa kujibu, kwa mujibu wa kiwango, inashauriwa kutoa msimbo huu na kichwa cha "Jaribu-Baada". Kichwa kinaweka wazi kwa usawazishaji kwamba haifai kuvuruga node hii kwenye njia hii kwa muda maalum. Na maombi yafuatayo ya kutuma SMS yatatumwa moja kwa moja kwenye node ambayo haina matatizo na lango la SMS.
Kama tunavyoona, kuegemea kwa JSON-RPC kumezidiwa. Hakika, ni rahisi kupanga uthabiti katika hifadhidata. Lakini dhabihu, katika kesi hii, itakuwa kuegemea kwa mfumo kwa ujumla.
Hitimisho kwa kiasi kikubwa ni sawa na uliopita. Wakati miundombinu ni rahisi, udhahiri wa JSON-RPC ni dhahiri zaidi. Ikiwa mradi unahusisha upatikanaji wa juu na mzigo mkubwa, REST inaonekana kama suluhisho sahihi zaidi, ingawa ngumu zaidi.
Kiwango cha juu cha kuingia kwa REST kiko chini
Nadhani uchanganuzi ulio hapo juu, ukitoa maoni potofu juu ya RPC, ulionyesha wazi kuwa kizingiti cha kuingia kwenye REST bila shaka ni cha juu kuliko katika RPC. Hii ni kutokana na hitaji la ufahamu wa kina wa jinsi HTTP inavyofanya kazi, pamoja na haja ya kuwa na ujuzi wa kutosha kuhusu vipengele vya miundombinu vilivyopo ambavyo vinaweza na vinavyopaswa kutumika katika miradi ya WEB.
Kwa hivyo kwa nini watu wengi wanafikiria kuwa REST itakuwa rahisi? Maoni yangu ya kibinafsi ni kwamba unyenyekevu huu dhahiri hutoka kwa REST hujidhihirisha. Wale. REST si itifaki bali ni dhana... REST haina kiwango, kuna baadhi ya miongozo... REST sio ngumu zaidi kuliko HTTP. Uhuru unaoonekana na machafuko huvutia "wasanii huru".
Kwa kweli, REST sio ngumu zaidi kuliko HTTP. Lakini HTTP yenyewe ni itifaki iliyoundwa vizuri ambayo imethibitisha thamani yake kwa miongo kadhaa. Ikiwa hakuna uelewa wa kina wa HTTP yenyewe, basi REST haiwezi kuhukumiwa.
Lakini kuhusu RPC - unaweza. Inatosha kuchukua vipimo vyake. Hivyo unahitaji ? Au bado ni gumu REST? Unaamua.
Natumai kwa dhati kuwa sijapoteza wakati wako.
Chanzo: mapenzi.com