Ég er viss um að fyrirsögnin olli heilbrigðum viðbrögðum - "jæja, það er byrjað aftur..." En ég leyfi mér að fanga athygli þína í 5-10 mínútur og ég mun reyna að valda ekki vonbrigðum þínum.
Uppbygging greinarinnar verður sem hér segir: Staðlað staðalímynd er tekin og „eðli“ tilkomu þessarar staðalímyndar kemur í ljós. Ég vona að þetta geri þér kleift að skoða val á hugmyndafræði gagnaskipta í verkefnum þínum frá nýjum sjónarhóli.
Til þess að vera skýr um hvað RPC er, legg ég til að íhuga staðalinn . Með REST er engin skýrleiki. Og það ætti ekki að vera. Allt sem þú þarft að vita um REST - það er ekki hægt að greina hana frá .
RPC beiðnir eru hraðari og skilvirkari vegna þess að þær gera þér kleift að gera hópbeiðnir.
Málið er að í RPC er hægt að hringja í nokkrar aðferðir í einu í einni beiðni. Til dæmis, búðu til notanda, bættu avatar við hann og gerðu áskrifandi að sumum umræðuefnum í sömu beiðni. Bara ein beiðni og hversu mikill ávinningur!
Reyndar, ef þú ert aðeins með einn bakendahnút, mun það virðast hraðari með lotubeiðni. Vegna þess að þrjár REST beiðnir þurfa þrisvar sinnum meira fjármagn frá einum hnút til að koma á tengingum.
Athugaðu að fyrsta beiðnin þegar um REST er að ræða verður að skila notandaauðkenninu til þess að síðari beiðnir séu gerðar. Sem hefur líka neikvæð áhrif á heildarniðurstöðuna.
En slíka innviði er aðeins að finna í eigin lausnum og Enterprise. Sem síðasta úrræði, í litlum vefverkefnum. En fullgildar WEB lausnir, og jafnvel þær sem kallast HighLoad, eru ekki þess virði að byggja upp. Innviðir þeirra verða að uppfylla skilyrði um mikið framboð og álag. Og myndin er að breytast.
Virkjunarrásir innviða undir sömu atburðarás eru merktar með grænu. Taktu eftir hvernig RPC hegðar sér núna. Beiðnin notar innviðina á aðeins einum fæti frá jafnvægisbúnaði til bakenda. Þó REST tapi enn í fyrstu beiðninni, bætir það upp tapaðan tíma með því að nota allan innviðina.
Það er nóg að setja inn í handritið ekki tvær beiðnir um auðgun, heldur, segjum, fimm eða tíu... og svarið við spurningunni „hver vinnur núna? verður óljóst.
Ég legg til að skoða vandamálið enn víðtækara. Skýringarmyndin sýnir hvernig innviðarásir eru notaðar, en innviðir takmarkast ekki við rásir. Mikilvægur þáttur í innviðum með mikið álag eru skyndiminni. Við skulum nú fá einhvers konar notendagrip. Ítrekað. Segjum 32 sinnum.
Sjáðu hvernig RPC innviðir hafa batnað verulega til að mæta kröfum um mikið álag. Málið er að REST notar fullan kraft HTTP samskiptareglunnar, ólíkt RPC. Í skýringarmyndinni hér að ofan er þessi kraftur að veruleika með beiðniaðferðinni - GET.
HTTP aðferðir, meðal annars, hafa skyndiminni aðferðir. Þú getur fundið þær í skjölunum á . Fyrir RPC eru POST beiðnir notaðar, sem eru ekki taldar óþolandi, það er að endurteknar endurtekningar á sömu POST beiðnum geta skilað mismunandi niðurstöðum (til dæmis, eftir að hver athugasemd er send mun annað eintak af þessari athugasemd birtast) ().
Þar af leiðandi getur RPC ekki notað skyndiminni innviða í raun. Þetta leiðir til þess að þurfa að „flytja inn“ skyndiminni hugbúnaðar. Myndin sýnir Redis í þessu hlutverki. Hugbúnaðarskyndiminni, aftur á móti, krefst þess að verktaki bæti við viðbótarlagi af kóða og áberandi breytingum á arkitektúrnum.
Við skulum nú telja hversu margar beiðnir REST og RPC „fæddu“ í þeim innviðum sem verið er að skoða?
Beiðnir
Innhólf
að bakenda
til DBMS
í mjúkt skyndiminni (Redis)
SAMTALS
REST
1 / 32 *
1
1
0
3 / 35
CPR
32
32
1
31
96
Miðað við fyrsta kerfið er munurinn sláandi. Nú kemur ávinningurinn af REST í ljós. En ég legg til að hætta ekki þar. Þróuðu innviðirnir innihalda CDN. Oft leysir það einnig vandamálið við að vinna gegn DDoS og DoS árásum. Við fáum:
Þetta er þar sem hlutirnir fara mjög illa fyrir RPC. RPC er einfaldlega ekki fær um að framselja vinnuálagið til CDN. Við getum aðeins treyst á kerfi til að vinna gegn árásum.
Er hægt að enda hér? Og aftur, nei. HTTP aðferðir, eins og getið er hér að ofan, hafa sína eigin „töfra“. Og það er ekki að ástæðulausu að GET aðferðin er mikið notuð á netinu. Athugaðu að þessi aðferð er fær um að fá aðgang að efni, er fær um að setja skilyrði sem innviðaþættir geta túlkað áður en stjórn er flutt yfir á kóðann þinn, og svo framvegis. Allt þetta gerir þér kleift að búa til sveigjanlegan, viðráðanlegan innviði sem geta séð um mjög stórt flæði beiðna. En í RPC er þessi aðferð hunsuð.
Svo hvers vegna er goðsögnin um að lotubeiðnir (RPC) séu hraðari svo viðvarandi? Persónulega sýnist mér að flest verkefni nái einfaldlega ekki því þróunarstigi að REST geti sýnt styrk sinn. Þar að auki, í litlum verkefnum, er hann viljugri til að sýna veikleika sína.
Valið á REST eða RPC er ekki viljandi val einstaklings í verkefni. Þetta val verður að uppfylla kröfur verkefnisins. Ef verkefni er fær um að kreista allt sem það getur raunverulega úr REST, og það þarf virkilega á því að halda, þá mun REST vera frábært val.
En ef, til að fá allan ávinninginn af REST, þarftu að ráða devops sérfræðinga í verkefnið til að stækka innviðina fljótt, stjórnendur til að stjórna innviðunum, arkitekt til að hanna öll lög vefþjónustunnar ... og verkefnið , selur á sama tíma þrjá pakka af smjörlíki á dag... Ég myndi halda mig við RPC, vegna þess að... þessi siðareglur eru hagnýtari. Það mun ekki krefjast djúprar þekkingar á því hvernig skyndiminni og innviðir virka, en mun einbeita framkvæmdaraðilanum að einföldum og skiljanlegum símtölum til verklaganna sem hann þarfnast. Viðskipti verða hamingjusöm.
RPC beiðnir eru áreiðanlegri vegna þess að þær geta framkvæmt lotubeiðnir í einni færslu
Þessi eiginleiki RPC er ákveðinn kostur vegna þess Það er auðvelt að halda gagnagrunninum stöðugum. En með REST verður þetta sífellt flóknara. Beiðnir kunna að berast ósamræmi til mismunandi bakendahnúta.
Þessi „ókostur“ REST er bakhliðin á kostinum sem lýst er hér að ofan - hæfileikinn til að nota öll innviðaauðlindir á skilvirkan hátt. Ef innviðir eru illa hönnuð, og enn frekar ef arkitektúr verkefnisins og gagnagrunnurinn sérstaklega er illa hannaður, þá er þetta í raun mikill sársauki.
En eru lotubeiðnir eins áreiðanlegar og þær virðast? Við skulum skoða mál: við búum til notanda, auðgum prófílinn hans með einhverri lýsingu og sendum honum SMS með leyndarmáli til að ljúka skráningu. Þeir. þrjú símtöl í einni lotu beiðni.
Við skulum skoða skýringarmyndina. Það sýnir innviði með háum framboðsþáttum. Það eru tvær sjálfstæðar samskiptaleiðir með SMS-gáttum. En... hvað sjáum við? Þegar þú sendir SMS kemur upp villa 503 - þjónustan er tímabundið ekki tiltæk. Vegna þess að SMS sendingu er pakkað í lotubeiðni, þá þarf að rúlla allri beiðninni til baka. Hætt er við aðgerðir í DBMS. Viðskiptavinurinn fær villu.
Næsta tilraun er lottóið. Annað hvort mun beiðnin lenda í sama hnút aftur og aftur og skila villu, eða þú verður heppinn og hún verður framkvæmd. En aðalatriðið er að að minnsta kosti einu sinni hafa innviðir okkar þegar virkað til einskis. Það var álag, en enginn hagnaður.
Allt í lagi, við skulum ímynda okkur að við höfum þrýst á okkur (!) og hugsað í gegnum þann möguleika þegar hægt er að klára beiðnina að hluta með góðum árangri. Og við munum reyna að klára restina aftur eftir nokkurt tímabil (Hver einn? Ákveður framhliðin?). En lottóið stóð í stað. Beiðnin um að senda SMS hefur 50/50 möguleika á að mistakast aftur.
Sammála, frá hlið viðskiptavinarins virðist þjónustan ekki eins áreiðanleg og við viljum... hvað með REST?
REST notar töfra HTTP aftur, en nú með svarkóða. Þegar villa 503 kemur upp á SMS gáttinni sendir bakendinn þessa villu til jafnvægisbúnaðarins. Jafnvægismaðurinn fær þessa villu og án þess að rjúfa tenginguna við viðskiptavininn sendir hann beiðnina á annan hnút sem vinnur úr beiðninni. Þeir. viðskiptavinurinn fær þá niðurstöðu sem búist er við og innviðirnir staðfesta háan titil sinn „mjög aðgengilegur“. Notandinn er ánægður.
Og aftur er það ekki allt. Jafnvægismaðurinn fékk ekki bara svarkóðann 503. Þegar svarað er, samkvæmt staðlinum, er ráðlegt að gefa þennan kóða upp á „Retry-After“ hausinn. Hausinn gerir jafnvægisstjóranum ljóst að það ætti ekki að trufla þennan hnút á þessari leið í tiltekinn tíma. Og næstu beiðnir um að senda SMS verða sendar beint á hnút sem hefur engin vandamál með SMS-gáttina.
Eins og við sjáum er áreiðanleiki JSON-RPC ofmetinn. Reyndar er auðveldara að skipuleggja samræmi í gagnagrunninum. En fórnin, í þessu tilfelli, verður áreiðanleiki kerfisins í heild.
Niðurstaðan er að mestu svipuð þeirri fyrri. Þegar innviðirnir eru einfaldir er augljóst JSON-RPC vissulega plús. Ef verkefnið felur í sér mikið framboð með miklu álagi lítur REST út fyrir að vera réttari, þó flóknari, lausn.
Aðgangsþröskuldur til REST er lægri
Ég held að ofangreind greining, þar sem viðurkenndar staðalímyndir um RPC voru afgreiddar, hafi greinilega sýnt að þröskuldurinn fyrir inngöngu í REST er án efa hærri en í RPC. Þetta stafar af þörfinni fyrir djúpan skilning á því hvernig HTTP virkar, sem og þörfina á að hafa nægilega þekkingu á núverandi innviðaþáttum sem hægt er og ætti að nota í WEB verkefnum.
Svo hvers vegna halda margir að REST verði einfaldari? Mín persónulega skoðun er sú að þessi augljósi einfaldleiki komi frá REST birtingunum sjálfum. Þeir. REST er ekki siðareglur heldur hugtak... REST er ekki með staðal, það eru nokkrar leiðbeiningar... REST er ekkert flóknara en HTTP. Augljóst frelsi og stjórnleysi laða að „frjálsa listamenn“.
Auðvitað er REST ekki flóknara en HTTP. En HTTP sjálft er vel hönnuð samskiptaregla sem hefur sannað gildi sitt í áratugi. Ef það er enginn djúpur skilningur á HTTP sjálfu, þá er ekki hægt að dæma REST.
En um RPC - þú getur. Það er nóg að taka forskrift þess. Svo þarftu ? Eða er það enn erfiður REST? Þú ræður.
Ég vona innilega að ég hafi ekki sóað tíma þínum.
Heimild: www.habr.com