Tha mi cinnteach gun do dh’ adhbhraich an ceann-naidheachd freagairt fallain - “uill, tha e air tòiseachadh a-rithist…” Ach leig dhomh d’ aire a ghlacadh airson 5-10 mionaidean, agus feuchaidh mi gun a bhith a’ briseadh-dùil na bha dùil agad.
Bidh structar an artaigil mar a leanas: tha aithris stereotypical air a ghabhail agus tha “nàdar” nochdadh an stereotype seo air fhoillseachadh. Tha mi an dòchas gun leig seo leat sùil a thoirt air an roghainn paradigm iomlaid dàta anns na pròiseactan agad bho cheàrn ùr.
Gus a bhith soilleir mu dè a th’ ann an RPC, tha mi a’ moladh beachdachadh air an inbhe . Le REST chan eil soilleireachd ann. Agus cha bu chòir a bhith. A h-uile dad a dh ’fheumas tu a bhith agad mu REST - chan urrainnear a sgaradh bho .
Tha iarrtasan RPC nas luaithe agus nas èifeachdaiche oir leigidh iad leat iarrtasan baidse a dhèanamh.
Is e a’ phuing gum faod thu ann an RPC grunn mhodhan-obrach a ghairm aig an aon àm ann an aon iarrtas. Mar eisimpleir, cruthaich neach-cleachdaidh, cuir avatar ris agus, san aon iarrtas, fo-sgrìobhadh dha cuid de chuspairean. Dìreach aon iarrtas, agus cia mheud buannachd!
Gu dearbh, mura h-eil agad ach aon nód backend, bidh e coltach nas luaithe le iarrtas baidse. Leis gum feum trì iarrtasan REST trì tursan a bharrachd ghoireasan bho aon nód gus ceanglaichean a stèidheachadh.
Thoir an aire gum feum a’ chiad iarrtas ann an cùis REST an ID cleachdaiche a thilleadh gus an tèid iarrtasan às deidh sin a dhèanamh. A tha cuideachd a 'toirt droch bhuaidh air an toradh iomlan.
Ach chan fhaighear bun-structaran mar sin ach ann am fuasglaidhean in-thaigh agus Iomairt. Mar roghainn mu dheireadh, ann am pròiseactan beaga WEB. Ach chan fhiach fuasglaidhean WEB làn-chuimseach, agus eadhon an fheadhainn ris an canar HighLoad, a thogail. Feumaidh am bun-structar aca coinneachadh ri slatan-tomhais ruigsinneachd àrd agus luchd. Agus tha an dealbh ag atharrachadh.
Tha seanalan gnìomhachd bun-structair fon aon suidheachadh air an comharrachadh ann an uaine. Mothaich mar a bhios RPC gad ghiùlan fhèin a-nis. Bidh an t-iarrtas a’ cleachdadh a’ bhun-structair air dìreach aon chas bhon chothromachadh chun an backend. Fhad ‘s a tha REST fhathast a’ call anns a ’chiad iarrtas, tha e a’ dèanamh suas airson ùine a chall a ’cleachdadh a’ bhun-structair gu lèir.
Tha e gu leòr airson a dhol a-steach don sgriobt chan e dà iarrtas airson beairteas, ach, can, còig no deich ... agus freagairt na ceiste “cò a bhuannaicheas a-nis?” fàs neo-shoilleir.
Tha mi a 'moladh sùil eadhon nas fharsainge a thoirt air an duilgheadas. Tha an diagram a’ sealltainn mar a thathar a’ cleachdadh seanalan bun-structair, ach chan eil bun-structar cuingealaichte ri seanalan. Is e pàirt chudromach de bhun-structar àrd luchdan caches. Feuch gum faigh sinn a-nis seòrsa de artifact cleachdaiche. A-rithist. Canaidh sinn 32 uair.
Faic mar a tha bun-structar RPC air a thighinn air adhart gu mòr gus coinneachadh ri iarrtasan luchdan àrd. Is e an rud gu bheil REST a’ cleachdadh làn chumhachd a’ phròtacail HTTP, eu-coltach ri RPC. Anns an dealbh gu h-àrd, tha an cumhachd seo air a thoirt gu buil tron dòigh iarrtas - GET.
Tha ro-innleachdan caching aig dòighean HTTP, am measg rudan eile. Gheibh thu iad anns na sgrìobhainnean aig . Airson RPC, thathas a’ cleachdadh iarrtasan POST, nach eilear a’ meas neo-chomasach, is e sin, faodaidh ath-aithris a dhèanamh air na h-aon iarrtasan POST toraidhean eadar-dhealaichte (mar eisimpleir, às deidh gach beachd a chuir a-steach, nochdaidh leth-bhreac eile den bheachd seo) ().
Mar thoradh air an sin, chan urrainn dha RPC tasgaidhean bun-structair a chleachdadh gu h-èifeachdach. Tha seo a’ leantainn gu feum air tasgadan bathar-bog “ion-phortadh”. Tha an diagram a’ sealltainn Redis san dreuchd seo. Tha an tasgadan bathar-bog, an uair sin, ag iarraidh air an leasaiche sreath a bharrachd de chòd a chuir ris agus atharrachaidhean follaiseach san ailtireachd.
Nach cunnt sinn a-nis cia mheud iarrtas a thug REST agus RPC “air an breith” anns a’ bhun-structar air a bheilear a’ beachdachadh?
Iarrtasan
bhogsa a-steach
gu cùl-taic
dhan DBMS
gu tasgadan bog (Redis)
IOMLAN
CÒRR
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
An coimeas ris a 'chiad sgeama, tha an eadar-dhealachadh iongantach. A-nis tha buannachd REST a’ fàs soilleir. Ach tha mi a’ moladh gun a bhith a’ stad an sin. Tha am bun-structar leasaichte a’ toirt a-steach CDN. Gu tric bidh e cuideachd a’ fuasgladh na cùise mu bhith a’ cur an aghaidh ionnsaighean DDoS agus DoS. Gheibh sinn:
Seo far a bheil cùisean a’ fàs gu math dona dha RPC. Gu sìmplidh chan urrainn dha RPC an eallach obrach a thiomnadh gu CDN. Chan urrainn dhuinn ach a bhith an urra ri siostaman gus cuir an-aghaidh ionnsaighean.
A bheil e comasach crìochnachadh an seo? Agus a-rithist, chan eil. Tha an “draoidheachd” aca fhèin aig modhan HTTP, mar a chaidh ainmeachadh gu h-àrd. Agus chan ann gun adhbhar a tha an dòigh GET air a chleachdadh gu farsaing air an eadar-lìn. Thoir an aire gu bheil an dòigh seo comasach air faighinn gu pìos susbaint, comasach air suidheachaidhean a shuidheachadh a dh’ fhaodas eileamaidean bun-structair a mhìneachadh mus tèid smachd a ghluasad chun chòd agad, agus mar sin air adhart. Leigidh seo leat bun-structaran sùbailte, so-ruigsinneach a chruthachadh as urrainn dèiligeadh ri sruthan fìor mhòr de dh’ iarrtasan. Ach ann an RPC tha an dòigh seo ... air a leigeil seachad.
Mar sin carson a tha an uirsgeul gu bheil iarrtasan baidse (RPC) nas luaithe cho leantainneach? Gu pearsanta, tha e coltach riumsa nach eil a 'mhòr-chuid de phròiseactan dìreach a' ruighinn ìre leasachaidh far a bheil REST comasach air a neart a shealltainn. A bharrachd air an sin, ann am pròiseactan beaga, tha e nas deònaiche na laigsean aige a nochdadh.
Chan e roghainn REST no RPC a tha ann an roghainn neach fa leth ann am pròiseact. Feumaidh an roghainn seo coinneachadh ri riatanasan a’ phròiseict. Ma tha pròiseact comasach air a h-uile dad as urrainn dha a bhrùthadh a-mach à REST, agus gu bheil feum aige air, bidh REST na dheagh roghainn.
Ach ma tha, gus na buannachdan uile bho REST fhaighinn, feumaidh tu eòlaichean devops fhastadh airson a’ phròiseict gus am bun-structar a sgèile gu sgiobalta, luchd-rianachd gus am bun-structar a riaghladh, ailtire gus gach sreath den t-seirbheis WEB a dhealbhadh ... , aig an aon àm, a' reic trì pacaidean de mhargarine gach latha... bhithinn a' cumail ri RPC, oir... tha am protocol seo nas fheumaile. Cha bhith feum air eòlas domhainn air mar a bhios caches agus bun-structar ag obair, ach cuiridh e fòcas air an leasaiche air fiosan sìmplidh agus so-thuigsinn gu na modhan-obrach a dh’ fheumas e. Bidh gnìomhachas toilichte.
Tha iarrtasan RPC nas earbsaiche oir is urrainn dhaibh iarrtasan baidse a chuir an gnìomh taobh a-staigh aon ghnothach
Tha an togalach seo de RPC na bhuannachd chinnteach, oir Tha e furasta an stòr-dàta a chumail cunbhalach. Ach le REST bidh e a’ fàs nas iom-fhillte. Faodaidh iarrtasan ruighinn gu neo-chunbhalach gu diofar nodan cùil.
Is e an “eas-bhuannachd” seo de REST an taobh flip den bhuannachd a tha air a mhìneachadh gu h-àrd - an comas a h-uile goireas bun-structair a chleachdadh gu h-èifeachdach. Ma tha am bun-structar air a dhealbhadh gu dona, agus eadhon nas motha ma tha ailtireachd a’ phròiseict agus an stòr-dàta gu sònraichte air an droch dhealbhadh, is e fìor phian a tha seo.
Ach a bheil iarrtasan baidse cho earbsach ‘s a tha iad coltach? Bheir sinn sùil air cùis: bidh sinn a ’cruthachadh neach-cleachdaidh, a’ beairteachadh a phròifil le beagan tuairisgeul agus a ’cur SMS thuige le dìomhaireachd gus clàradh a chrìochnachadh. An fheadhainn sin. Trì fiosan ann an aon baidse iarrtas.
Bheir sinn sùil air an diagram. Tha e a’ taisbeanadh bun-structar le eileamaidean ruigsinneachd àrd. Tha dà dhòigh conaltraidh neo-eisimeileach ann le geataichean SMS. Ach... dè a chì sinn? Nuair a chuireas tu SMS, bidh mearachd 503 a’ tachairt - chan eil an t-seirbheis ri fhaighinn airson ùine. Air sgàth Tha cur SMS air a phacadh ann an iarrtas baidse, an uairsin feumar an t-iarrtas gu lèir a thoirt air ais. Tha gnìomhan san DBMS air an cur dheth. Bidh an neach-dèiligidh a’ faighinn mearachd.
Is e an ath oidhirp an crannchur. An dàrna cuid buailidh an t-iarrtas air an aon nód a-rithist agus a-rithist tillidh mearachd, no bidh thu fortanach agus thèid a chuir gu bàs. Ach is e am prìomh rud gu bheil ar bun-structar air obrachadh gu dìomhain co-dhiù aon uair. Bha eallach ann, ach cha robh prothaid ann.
Ceart gu leòr, smaoinichidh sinn gun do chuir sinn cuideam oirnn fhìn (!) agus gun do smaoinich sinn tron roghainn nuair a ghabhadh pàirt den iarrtas a chrìochnachadh gu soirbheachail. Agus feuchaidh sinn ris a’ chòrr a chrìochnachadh a-rithist às deidh beagan ùine (Dè am fear? A bheil an aghaidh a’ co-dhùnadh?). Ach dh'fhuirich an crannchur mar a bha e. Tha teansa 50/50 gum fàillig an iarrtas airson SMS a chur a-rithist.
Aontaich, bho thaobh an luchd-cleachdaidh, chan eil coltas gu bheil an t-seirbheis cho earbsach 's a bu mhath leinn ... dè mu dheidhinn REST?
Bidh REST a’ cleachdadh draoidheachd HTTP a-rithist, ach a-nis le còdan freagairt. Nuair a thachras mearachd 503 air geata SMS, bidh an backend a ’craoladh a’ mhearachd seo chun neach-cothromachaidh. Bidh an cothromaiche a 'faighinn a' mhearachd seo agus gun a bhith a 'briseadh a' cheangail leis an neach-dèiligidh, cuiridh e an t-iarrtas gu nód eile, a bhios a 'pròiseasadh an iarrtais gu soirbheachail. An fheadhainn sin. gheibh an neach-dèiligidh an toradh ris a bheil dùil, agus tha am bun-structar a’ dearbhadh an tiotal àrd aige “fìor ruigsinneach”. Tha an neach-cleachdaidh toilichte.
Agus a-rithist chan eil sin uile. Cha d' fhuair an cothromaiche dìreach còd freagairt 503. Nuair a fhreagair e, a rèir na h-ìre, tha e ciallach an bann-cinn “Retry-After” a thoirt don chòd seo. Tha an ceann-cinn ga dhèanamh soilleir don chothromaiche nach fhiach dragh a chuir air an nód seo air an t-slighe seo airson ùine shònraichte. Agus thèid na h-ath iarrtasan airson SMS a chuir gu dìreach gu nód aig nach eil duilgheadas sam bith le geata SMS.
Mar a chì sinn, tha cus earbsa aig JSON-RPC. Gu dearbh, tha e nas fhasa cunbhalachd a chuir air dòigh san stòr-dàta. Ach bidh an ìobairt, sa chùis seo, earbsachd an t-siostam gu h-iomlan.
Tha an co-dhùnadh gu ìre mhòr coltach ris an fhear roimhe. Nuair a tha am bun-structar sìmplidh, tha follaiseachd JSON-RPC gu cinnteach na bhuannachd. Ma tha am pròiseact a’ toirt a-steach ruigsinneachd àrd le luchd àrd, tha coltas ann gum bi REST na fhuasgladh nas ceart, ged a tha e nas iom-fhillte.
Tha an ìre inntrigidh gu REST nas ìsle
Tha mi a’ smaoineachadh gun do sheall an anailis gu h-àrd, a’ toirt air falbh na stereotypes stèidhichte mu RPC, gu soilleir gu bheil an stairsneach airson faighinn a-steach do REST gun teagamh nas àirde na ann an RPC. Tha seo air sgàth gu bheil feum air tuigse dhomhainn air mar a tha HTTP ag obair, a bharrachd air an fheum air eòlas gu leòr a bhith agad mu eileamaidean bun-structair a dh’ fhaodar agus a bu chòir a chleachdadh ann am pròiseactan WEB.
Mar sin carson a tha mòran dhaoine den bheachd gum bi REST nas sìmplidh? Is e mo bheachd pearsanta gu bheil an sìmplidheachd fhollaiseach seo a’ tighinn bhon REST a tha gam nochdadh fhèin. An fheadhainn sin. Chan e protocol a th' ann an REST ach bun-bheachd... Chan eil inbhe aig REST, tha cuid de stiùiridhean ann... Chan eil REST nas toinnte na HTTP. Bidh saorsa agus anarchy a rèir coltais a’ tàladh “luchd-ealain an-asgaidh”.
Gu dearbh, chan eil REST nas iom-fhillte na HTTP. Ach tha HTTP fhèin na phròtacal air a dheagh dhealbhadh a tha air a luach a dhearbhadh thar deicheadan. Mura h-eil tuigse dhomhainn air HTTP fhèin, chan urrainnear REST a bhreithneachadh.
Ach mu dheidhinn RPC - faodaidh tu. Tha e gu leòr airson a shònrachadh a ghabhail. Mar sin feumaidh tu ? No a bheil e fhathast duilich REST? Bidh thu a’ co-dhùnadh.
Tha mi gu dùrachdach an dòchas nach eil mi air do chuid ùine a chaitheamh.
Source: www.habr.com