Hei Habr!

Yng ngoleuni digwyddiadau cyfredol oherwydd coronafirws, mae nifer o wasanaethau Rhyngrwyd wedi dechrau derbyn mwy o lwyth. Er enghraifft, Yn syml, rhoddodd un o gadwyni manwerthu’r DU y gorau i’w safle archebu ar-lein., oherwydd nid oedd digon o gapasiti. Ac nid yw bob amser yn bosibl cyflymu gweinydd trwy ychwanegu offer mwy pwerus yn unig, ond rhaid prosesu ceisiadau cleientiaid (neu byddant yn mynd at gystadleuwyr).

Yn yr erthygl hon byddaf yn siarad yn fyr am arferion poblogaidd a fydd yn caniatáu ichi greu gwasanaeth cyflym a goddefgar. Fodd bynnag, o’r cynlluniau datblygu posibl, dim ond y rhai sydd ar hyn o bryd a ddewisais hawdd i'w defnyddio. Ar gyfer pob eitem, mae gennych naill ai lyfrgelloedd parod, neu mae gennych gyfle i ddatrys y broblem gan ddefnyddio platfform cwmwl.

Graddio llorweddol

Y pwynt symlaf a mwyaf adnabyddus. Yn gonfensiynol, y ddau gynllun dosbarthu llwyth mwyaf cyffredin yw graddio llorweddol a fertigol. Yn yr achos cyntaf rydych yn caniatáu i wasanaethau redeg yn gyfochrog, gan ddosbarthu'r llwyth rhyngddynt. Yn yr ail rydych chi'n archebu gweinyddwyr mwy pwerus neu'n gwneud y gorau o'r cod.

Er enghraifft, byddaf yn cymryd storfa ffeiliau cwmwl haniaethol, hynny yw, rhywfaint o analog o OwnCloud, OneDrive, ac ati.

Mae llun safonol o gylched o'r fath isod, ond dim ond cymhlethdod y system y mae'n ei ddangos. Wedi'r cyfan, mae angen inni rywsut gysoni'r gwasanaethau. Beth sy'n digwydd os bydd y defnyddiwr yn arbed ffeil o'r dabled ac yna eisiau ei weld o'r ffôn?

Y gwahaniaeth rhwng y dulliau: mewn graddio fertigol, rydym yn barod i gynyddu pŵer nodau, ac mewn graddio llorweddol, rydym yn barod i ychwanegu nodau newydd i ddosbarthu'r llwyth.

CQRS

Ymholiad Gorchymyn Cyfrifoldeb Gwahanu Patrwm eithaf pwysig, gan ei fod yn caniatáu i wahanol gleientiaid nid yn unig gysylltu â gwahanol wasanaethau, ond hefyd i dderbyn yr un ffrydiau digwyddiad. Nid yw ei fanteision mor amlwg ar gyfer cais syml, ond mae'n hynod bwysig (a syml) ar gyfer gwasanaeth prysur. Ei hanfod: ni ddylai llifoedd data sy'n dod i mewn ac sy'n mynd allan groestorri. Hynny yw, ni allwch anfon cais a disgwyl ymateb; yn lle hynny, rydych yn anfon cais at wasanaeth A, ond yn cael ymateb gan wasanaeth B.

Bonws cyntaf y dull hwn yw'r gallu i dorri'r cysylltiad (yn ystyr eang y gair) wrth weithredu cais hir. Er enghraifft, gadewch i ni gymryd dilyniant safonol mwy neu lai:

1. Anfonodd y cleient gais at y gweinydd.
2. Dechreuodd y gweinydd amser prosesu hir.
3. Ymatebodd y gweinydd i'r cleient gyda'r canlyniad.

Gadewch i ni ddychmygu bod y cysylltiad ym mhwynt 2 wedi'i dorri (neu fod y rhwydwaith wedi'i ailgysylltu, neu i'r defnyddiwr fynd i dudalen arall, gan dorri'r cysylltiad). Yn yr achos hwn, bydd yn anodd i'r gweinydd anfon ymateb at y defnyddiwr gyda gwybodaeth am beth yn union a broseswyd. Gan ddefnyddio CQRS, bydd y dilyniant ychydig yn wahanol:

1. Mae'r cleient wedi tanysgrifio i ddiweddariadau.
2. Anfonodd y cleient gais at y gweinydd.
3. Ymatebodd y gweinydd “derbyniwyd y cais.”
4. Ymatebodd y gweinydd gyda'r canlyniad trwy'r sianel o bwynt “1”.

Fel y gwelwch, mae'r cynllun ychydig yn fwy cymhleth. Ar ben hynny, mae'r dull ymateb cais greddfol ar goll yma. Fodd bynnag, fel y gwelwch, ni fydd toriad cysylltiad wrth brosesu cais yn arwain at wall. Ar ben hynny, os yw'r defnyddiwr mewn gwirionedd wedi'i gysylltu â'r gwasanaeth o sawl dyfais (er enghraifft, o ffôn symudol ac o dabled), gallwch sicrhau bod yr ymateb yn dod i'r ddau ddyfais.

Yn ddiddorol, mae'r cod ar gyfer prosesu negeseuon sy'n dod i mewn yn dod yr un peth (nid 100%) ar gyfer digwyddiadau y dylanwadwyd arnynt gan y cleient ei hun, ac ar gyfer digwyddiadau eraill, gan gynnwys y rhai gan gleientiaid eraill.

Fodd bynnag, mewn gwirionedd rydym yn cael bonws ychwanegol oherwydd y ffaith y gellir trin llif un cyfeiriad mewn arddull swyddogaethol (gan ddefnyddio RX a thebyg). Ac mae hyn eisoes yn fantais ddifrifol, oherwydd yn ei hanfod gellir gwneud y cais yn gwbl adweithiol, a hefyd gan ddefnyddio dull swyddogaethol. Ar gyfer rhaglenni braster, gall hyn arbed datblygiad a chymorth adnoddau yn sylweddol.

Os byddwn yn cyfuno'r dull hwn â graddio llorweddol, yna fel bonws cawn y gallu i anfon ceisiadau at un gweinydd a derbyn ymatebion gan un arall. Felly, gall y cleient ddewis y gwasanaeth sy'n gyfleus iddo, a bydd y system y tu mewn yn dal i allu prosesu digwyddiadau'n gywir.

Cyrchu Digwyddiadau

Fel y gwyddoch, un o brif nodweddion system ddosbarthedig yw absenoldeb amser cyffredin, adran hanfodol gyffredin. Ar gyfer un broses, gallwch chi wneud cydamseriad (ar yr un mutexes), lle rydych chi'n siŵr nad oes unrhyw un arall yn gweithredu'r cod hwn. Fodd bynnag, mae hyn yn beryglus i system ddosbarthedig, gan y bydd angen gorbenion arno, a bydd hefyd yn lladd yr holl harddwch graddio - bydd yr holl gydrannau'n dal i aros am un.

O'r fan hon cawn ffaith bwysig - ni ellir cydamseru system ddosbarthedig gyflym, oherwydd yna byddwn yn lleihau perfformiad. Ar y llaw arall, yn aml mae arnom angen cysondeb penodol rhwng cydrannau. Ac ar gyfer hyn gallwch chi ddefnyddio'r dull gyda cysondeb yn y pen draw, lle y gwarantir, os nad oes unrhyw newidiadau data am gyfnod o amser ar ôl y diweddariad diwethaf (“yn y pen draw”), bydd pob ymholiad yn dychwelyd y gwerth diweddaraf wedi'i ddiweddaru.

Mae'n bwysig deall ei fod yn cael ei ddefnyddio'n eithaf aml ar gyfer cronfeydd data clasurol cysondeb cryf, lle mae gan bob nod yr un wybodaeth (yn aml, cyflawnir hyn yn yr achos lle ystyrir bod y trafodiad wedi'i sefydlu dim ond ar ôl i'r ail weinydd ymateb). Mae yna rai ymlacio yma oherwydd y lefelau ynysu, ond mae'r syniad cyffredinol yn aros yr un fath - gallwch chi fyw mewn byd sydd wedi'i gysoni'n llwyr.

Fodd bynnag, gadewch i ni ddychwelyd at y dasg wreiddiol. Os gellir adeiladu rhan o'r system gyda cysondeb yn y pen draw, yna gallwn adeiladu'r diagram canlynol.

Nodweddion pwysig y dull hwn:

• Rhoddir pob cais sy'n dod i mewn mewn un ciw.
• Wrth brosesu cais, gall y gwasanaeth hefyd osod tasgau mewn ciwiau eraill.
• Mae gan bob digwyddiad sy'n dod i mewn ddynodwr (sy'n angenrheidiol ar gyfer dad-ddyblygu).
• Mae'r ciw yn ideolegol yn gweithio yn ôl y cynllun “atodiad yn unig”. Ni allwch dynnu elfennau ohono na'u haildrefnu.
• Mae'r ciw yn gweithio yn ôl cynllun FIFO (sori am y tautoleg). Os oes angen i chi wneud gweithrediad cyfochrog, yna ar un cam dylech symud gwrthrychau i wahanol giwiau.

Gadewch imi eich atgoffa ein bod yn ystyried achos storio ffeiliau ar-lein. Yn yr achos hwn, bydd y system yn edrych fel hyn:

Mae'n bwysig nad yw'r gwasanaethau yn y diagram o reidrwydd yn golygu gweinydd ar wahân. Gall hyd yn oed y broses fod yr un peth. Mae peth arall yn bwysig: yn ideolegol, mae'r pethau hyn wedi'u gwahanu yn y fath fodd fel y gellir cymhwyso graddio llorweddol yn hawdd.

Ac ar gyfer dau ddefnyddiwr bydd y diagram yn edrych fel hyn (mae gwasanaethau a fwriedir ar gyfer gwahanol ddefnyddwyr wedi'u nodi mewn gwahanol liwiau):

Bonysau o gyfuniad o'r fath:

• Mae gwasanaethau prosesu gwybodaeth wedi'u gwahanu. Mae'r ciwiau hefyd wedi'u gwahanu. Os oes angen i ni gynyddu'r trwybwn system, yna mae angen i ni lansio mwy o wasanaethau ar fwy o weinyddion.
• Pan fyddwn yn derbyn gwybodaeth gan ddefnyddiwr, nid oes rhaid i ni aros nes bod y data wedi'i gadw'n llwyr. I'r gwrthwyneb, does ond angen i ni ateb “iawn” ac yna dechrau gweithio'n raddol. Ar yr un pryd, mae'r ciw yn llyfnhau copaon, gan fod ychwanegu gwrthrych newydd yn digwydd yn gyflym, ac nid oes rhaid i'r defnyddiwr aros am basio cyflawn trwy'r cylch cyfan.
• Er enghraifft, ychwanegais wasanaeth dad-ddyblygu sy'n ceisio uno ffeiliau union yr un fath. Os yw'n gweithio am amser hir mewn 1% o achosion, prin y bydd y cleient yn sylwi arno (gweler uchod), sy'n fantais fawr, gan nad yw'n ofynnol i ni fod yn XNUMX% cyflymder a dibynadwy mwyach.

Fodd bynnag, mae'r anfanteision i'w gweld ar unwaith:

• Mae ein system wedi colli ei chysondeb llym. Mae hyn yn golygu, er enghraifft, os ydych chi'n tanysgrifio i wahanol wasanaethau, yna yn ddamcaniaethol gallwch chi gael cyflwr gwahanol (oherwydd efallai na fydd gan un o'r gwasanaethau amser i dderbyn hysbysiad gan y ciw mewnol). O ganlyniad arall, nid oes gan y system amser cyffredin bellach. Hynny yw, mae'n amhosibl, er enghraifft, didoli pob digwyddiad yn syml yn ôl amser cyrraedd, oherwydd efallai na fydd y clociau rhwng gweinyddwyr yn gydamserol (ar ben hynny, mae'r un amser ar ddau weinydd yn iwtopia).
• Ni all unrhyw ddigwyddiadau gael eu dychwelyd yn syml bellach (fel y gellid ei wneud gyda chronfa ddata). Yn lle hynny, mae angen i chi ychwanegu digwyddiad newydd - digwyddiad iawndal, a fydd yn newid y cyflwr olaf i'r un gofynnol. Fel enghraifft o faes tebyg: heb ailysgrifennu hanes (sy'n ddrwg mewn rhai achosion), ni allwch rolio ymrwymiad mewn git yn ôl, ond gallwch chi wneud arbennig ymrwymiad dychwelyd, sydd yn ei hanfod yn dychwelyd yr hen gyflwr. Fodd bynnag, bydd yr ymrwymiad gwallus a'r dychwelyd yn aros mewn hanes.
• Gall y sgema data newid o ryddhau i ryddhau, ond ni fydd yn bosibl diweddaru hen ddigwyddiadau i'r safon newydd mwyach (gan na ellir newid digwyddiadau mewn egwyddor).

Fel y gallwch weld, mae Event Sourcing yn gweithio'n dda gyda CQRS. Ar ben hynny, mae gweithredu system gyda chiwiau effeithlon a chyfleus, ond heb wahanu llif data, eisoes yn anodd ynddo'i hun, oherwydd bydd yn rhaid ichi ychwanegu pwyntiau cydamseru a fydd yn niwtraleiddio effaith gadarnhaol gyfan y ciwiau. Gan gymhwyso'r ddau ddull ar unwaith, mae angen addasu cod y rhaglen ychydig. Yn ein hachos ni, wrth anfon ffeil at y gweinydd, dim ond “iawn” y daw'r ymateb, sydd ond yn golygu bod “y gweithrediad o ychwanegu'r ffeil wedi'i gadw.” Yn ffurfiol, nid yw hyn yn golygu bod y data eisoes ar gael ar ddyfeisiau eraill (er enghraifft, gall y gwasanaeth dad-ddyblygu ailadeiladu'r mynegai). Fodd bynnag, ar ôl peth amser, bydd y cleient yn derbyn hysbysiad yn arddull "ffeil X wedi'i gadw."

Fel canlyniad:

• Mae nifer y statws anfon ffeiliau yn cynyddu: yn lle’r “ffeil a anfonwyd” glasurol rydym yn cael dau: “mae’r ffeil wedi’i hychwanegu at y ciw ar y gweinydd” a “mae’r ffeil wedi’i chadw yn y storfa.” Mae'r olaf yn golygu y gall dyfeisiau eraill ddechrau derbyn y ffeil eisoes (wedi'i addasu ar gyfer y ffaith bod y ciwiau'n gweithredu ar gyflymder gwahanol).
• Oherwydd bod y wybodaeth gyflwyno bellach yn dod trwy wahanol sianeli, mae angen i ni ddod o hyd i atebion i dderbyn statws prosesu'r ffeil. O ganlyniad i hyn: yn wahanol i'r cais-ymateb clasurol, gellir ailgychwyn y cleient wrth brosesu'r ffeil, ond bydd statws y prosesu hwn ei hun yn gywir. Ar ben hynny, yr eitem hon yn gweithio, yn ei hanfod, allan o'r bocs. O ganlyniad: rydym bellach yn fwy goddefgar o fethiannau.

sharding

Fel y disgrifir uchod, mae diffyg cysondeb llym mewn systemau cyrchu digwyddiadau. Mae hyn yn golygu y gallwn ddefnyddio sawl storfa heb unrhyw gydamseriad rhyngddynt. Wrth nesáu at ein problem, gallwn:

• Gwahanu ffeiliau yn ôl math. Er enghraifft, gellir dadgodio lluniau/fideos a dewis fformat mwy effeithlon.
• Cyfrifon ar wahân yn ôl gwlad. Oherwydd llawer o gyfreithiau, efallai y bydd angen hyn, ond mae'r cynllun pensaernïaeth hwn yn darparu cyfle o'r fath yn awtomatig

Os ydych chi am drosglwyddo data o un storfa i'r llall, yna nid yw dulliau safonol yn ddigon bellach. Yn anffodus, yn yr achos hwn, mae angen i chi atal y ciw, gwneud y mudo, ac yna ei gychwyn. Yn yr achos cyffredinol, ni ellir trosglwyddo data “ar y hedfan”, fodd bynnag, os yw ciw y digwyddiad yn cael ei storio'n llwyr, a bod gennych gipluniau o gyflwr storio blaenorol, yna gallwn ailchwarae'r digwyddiadau fel a ganlyn:

• Yn Event Source, mae gan bob digwyddiad ei ddynodwr ei hun (yn ddelfrydol, heb fod yn lleihau). Mae hyn yn golygu y gallwn ychwanegu cae at y storfa - id yr elfen olaf wedi'i phrosesu.
• Rydym yn dyblygu'r ciw fel y gellir prosesu pob digwyddiad ar gyfer sawl storfa annibynnol (y cyntaf yw'r un y mae'r data eisoes wedi'i storio ynddo, ac mae'r ail yn newydd, ond yn dal yn wag). Nid yw’r ail giw, wrth gwrs, yn cael ei brosesu eto.
• Rydyn ni'n lansio'r ail giw (hynny yw, rydyn ni'n dechrau ailchwarae digwyddiadau).
• Pan fydd y ciw newydd yn gymharol wag (hynny yw, mae'r gwahaniaeth amser cyfartalog rhwng ychwanegu elfen a'i hadalw yn dderbyniol), gallwch ddechrau newid darllenwyr i'r storfa newydd.

Fel y gallwch weld, nid oedd gennym, ac nid oes gennym o hyd, gysondeb llym yn ein system. Dim ond yn y pen draw gysondeb sydd, hynny yw, gwarant bod digwyddiadau'n cael eu prosesu yn yr un drefn (ond o bosibl gydag oedi gwahanol). A thrwy ddefnyddio hyn, gallwn drosglwyddo data yn gymharol hawdd heb atal y system i ochr arall y byd.

Felly, gan barhau â'n hesiampl am storio ffeiliau ar-lein, mae pensaernïaeth o'r fath eisoes yn rhoi nifer o fonysau inni:

• Gallwn symud gwrthrychau yn nes at ddefnyddwyr mewn ffordd ddeinamig. Fel hyn gallwch wella ansawdd y gwasanaeth.
• Efallai y byddwn yn storio rhywfaint o ddata o fewn cwmnïau. Er enghraifft, mae defnyddwyr Menter yn aml yn ei gwneud yn ofynnol i'w data gael ei storio mewn canolfannau data rheoledig (er mwyn osgoi gollyngiadau data). Trwy ei rannu gallwn yn hawdd gefnogi hyn. Ac mae'r dasg hyd yn oed yn haws os oes gan y cwsmer gwmwl cydnaws (er enghraifft, Azure hunangynhaliol).
• A'r peth pwysicaf yw nad oes yn rhaid i ni wneud hyn. Wedi'r cyfan, i ddechrau, byddem yn eithaf hapus gydag un storfa ar gyfer pob cyfrif (i ddechrau gweithio'n gyflym). A nodwedd allweddol y system hon yw, er ei bod yn hawdd ei hehangu, yn y cam cychwynnol mae'n eithaf syml. Nid oes yn rhaid i chi ysgrifennu cod ar unwaith sy'n gweithio gyda miliwn o giwiau annibynnol ar wahân, ac ati. Os oes angen, gellir gwneud hyn yn y dyfodol.

Cynnal Cynnwys Statig

Efallai y bydd y pwynt hwn yn ymddangos yn eithaf amlwg, ond mae'n dal i fod yn angenrheidiol ar gyfer cais llwytho safonol mwy neu lai. Mae ei hanfod yn syml: mae'r holl gynnwys statig yn cael ei ddosbarthu nid o'r un gweinydd lle mae'r cais wedi'i leoli, ond o rai arbennig sy'n benodol i'r dasg hon. O ganlyniad, mae'r gweithrediadau hyn yn cael eu perfformio'n gyflymach (mae nginx amodol yn gwasanaethu ffeiliau yn gyflymach ac yn rhatach na gweinydd Java). Yn ogystal â phensaernïaeth CDN (Rhwydwaith Darparu Cynnwys) yn ein galluogi i leoli ein ffeiliau yn agosach at ddefnyddwyr terfynol, sy'n cael effaith gadarnhaol ar hwylustod gweithio gyda'r gwasanaeth.

Yr enghraifft symlaf a mwyaf safonol o gynnwys statig yw set o sgriptiau a delweddau ar gyfer gwefan. Mae popeth yn syml gyda nhw - maen nhw'n hysbys ymlaen llaw, yna mae'r archif yn cael ei lanlwytho i weinyddion CDN, o ble maen nhw'n cael eu dosbarthu i ddefnyddwyr terfynol.

Fodd bynnag, mewn gwirionedd, ar gyfer cynnwys statig, gallwch ddefnyddio dull ychydig yn debyg i bensaernïaeth lambda. Gadewch i ni ddychwelyd at ein tasg (storio ffeiliau ar-lein), lle mae angen i ni ddosbarthu ffeiliau i ddefnyddwyr. Yr ateb symlaf yw creu gwasanaeth sydd, ar gyfer pob cais defnyddiwr, yn gwneud yr holl wiriadau angenrheidiol (awdurdodiad, ac ati), ac yna'n lawrlwytho'r ffeil yn uniongyrchol o'n storfa. Prif anfantais y dull hwn yw bod cynnwys statig (a ffeil gydag adolygiad penodol, mewn gwirionedd, yn cynnwys statig) yn cael ei ddosbarthu gan yr un gweinydd sy'n cynnwys y rhesymeg busnes. Yn lle hynny, gallwch chi wneud y diagram canlynol:

• Mae'r gweinydd yn darparu URL llwytho i lawr. Gall fod o'r ffurf file_id + allwedd, lle mae'r allwedd yn llofnod digidol bach sy'n rhoi'r hawl i gael mynediad i'r adnodd am y 24 awr nesaf.
• Mae'r ffeil yn cael ei ddosbarthu gan nginx syml gyda'r opsiynau canlynol:
  • Cuddio cynnwys. Gan y gellir lleoli'r gwasanaeth hwn ar weinydd ar wahân, rydym wedi gadael cronfa wrth gefn ar gyfer y dyfodol gyda'r gallu i storio'r holl ffeiliau diweddaraf a lawrlwythwyd ar ddisg.
  • Gwirio'r allwedd ar adeg creu cysylltiad
• Dewisol: ffrydio prosesu cynnwys. Er enghraifft, os ydym yn cywasgu'r holl ffeiliau yn y gwasanaeth, yna gallwn ddadsipio'n uniongyrchol yn y modiwl hwn. O ganlyniad: mae gweithrediadau IO yn cael eu gwneud lle maent yn perthyn. Bydd archifydd yn Java yn dyrannu llawer o gof ychwanegol yn hawdd, ond gall ailysgrifennu gwasanaeth gyda rhesymeg busnes i amodau Rust / C ++ fod yn aneffeithiol hefyd. Yn ein hachos ni, defnyddir gwahanol brosesau (neu hyd yn oed wasanaethau), ac felly gallwn wahanu gweithrediadau rhesymeg busnes ac IO yn eithaf effeithiol.

Nid yw'r cynllun hwn yn debyg iawn i ddosbarthu cynnwys statig (gan nad ydym yn uwchlwytho'r pecyn sefydlog cyfan yn rhywle), ond mewn gwirionedd, mae'r dull hwn yn ymwneud yn union â dosbarthu data na ellir ei gyfnewid. At hynny, gellir cyffredinoli'r cynllun hwn i achosion eraill lle nad yw'r cynnwys yn statig yn unig, ond gellir ei gynrychioli fel set o flociau na ellir eu cyfnewid ac na ellir eu dileu (er y gellir eu hychwanegu).

Fel enghraifft arall (ar gyfer atgyfnerthu): os ydych wedi gweithio gyda Jenkins/TeamCity, yna rydych chi'n gwybod bod y ddau ddatrysiad wedi'u hysgrifennu yn Java. Mae'r ddau ohonyn nhw'n broses Java sy'n ymdrin ag offeryniaeth adeiladu a rheoli cynnwys. Yn benodol, mae gan y ddau dasg fel “trosglwyddo ffeil / ffolder o'r gweinydd.” Er enghraifft: cyhoeddi arteffactau, trosglwyddo cod ffynhonnell (pan nad yw'r asiant yn lawrlwytho'r cod yn uniongyrchol o'r ystorfa, ond mae'r gweinydd yn ei wneud ar ei gyfer), mynediad i logiau. Mae'r holl dasgau hyn yn wahanol yn eu llwyth IO. Hynny yw, mae'n ymddangos bod yn rhaid i'r gweinydd sy'n gyfrifol am resymeg busnes cymhleth allu gwthio llif mawr o ddata trwyddo'i hun ar yr un pryd. A'r hyn sydd fwyaf diddorol yw y gellir dirprwyo gweithrediad o'r fath i'r un nginx yn ôl yr un cynllun yn union (ac eithrio y dylid ychwanegu'r allwedd ddata at y cais).

Fodd bynnag, os byddwn yn dychwelyd i'n system, byddwn yn cael diagram tebyg:

Fel y gwelwch, mae'r system wedi dod yn llawer mwy cymhleth. Nawr nid proses fach yn unig sy'n storio ffeiliau'n lleol. Nawr nid yr hyn sydd ei angen yw'r gefnogaeth symlaf, rheolaeth fersiwn API, ac ati. Felly, ar ôl i'r holl ddiagramau gael eu llunio, mae'n well gwerthuso'n fanwl a yw estynadwyedd yn werth y gost. Fodd bynnag, os ydych chi am allu ehangu'r system (gan gynnwys gweithio gyda nifer hyd yn oed yn fwy o ddefnyddwyr), yna bydd yn rhaid i chi fynd am atebion tebyg. Ond, o ganlyniad, mae'r system yn bensaernïol barod ar gyfer llwyth cynyddol (gellir clonio bron pob cydran ar gyfer graddio llorweddol). Gellir diweddaru'r system heb ei hatal (yn syml bydd rhai gweithrediadau'n cael eu harafu ychydig).

Fel y dywedais ar y dechrau, erbyn hyn mae nifer o wasanaethau Rhyngrwyd wedi dechrau derbyn llwyth cynyddol. A dechreuodd rhai ohonynt roi'r gorau i weithio'n gywir. Mewn gwirionedd, methodd y systemau yn union ar hyn o bryd pan oedd y busnes i fod i wneud arian. Hynny yw, yn lle danfoniad gohiriedig, yn lle awgrymu i gwsmeriaid “cynlluniwch eich danfoniad ar gyfer y misoedd nesaf,” dywedodd y system yn syml “ewch at eich cystadleuwyr.” Mewn gwirionedd, dyma bris cynhyrchiant isel: bydd colledion yn digwydd yn union pan fyddai elw ar ei uchaf.

Casgliad

Roedd yr holl ddulliau hyn yn hysbys o'r blaen. Mae'r un VK wedi bod yn defnyddio'r syniad o Hosting Cynnwys Statig ers amser maith i arddangos delweddau. Mae llawer o gemau ar-lein yn defnyddio'r cynllun Sharding i rannu chwaraewyr yn ranbarthau neu i wahanu lleoliadau gêm (os yw'r byd ei hun yn un). Defnyddir dull Cyrchu Digwyddiadau mewn e-bost. Mae'r rhan fwyaf o gymwysiadau masnachu lle mae data'n cael ei dderbyn yn gyson mewn gwirionedd yn seiliedig ar ddull CQRS er mwyn gallu hidlo'r data a dderbynnir. Wel, mae graddio llorweddol wedi cael ei ddefnyddio mewn llawer o wasanaethau ers amser maith.

Fodd bynnag, yn bwysicaf oll, mae'r holl batrymau hyn wedi dod yn hawdd iawn i'w cymhwyso mewn cymwysiadau modern (os ydynt yn briodol, wrth gwrs). Mae Cymylau yn cynnig Sharding a graddio llorweddol ar unwaith, sy'n llawer haws nag archebu gwahanol weinyddion pwrpasol mewn gwahanol ganolfannau data eich hun. Mae CQRS wedi dod yn llawer haws, os mai dim ond oherwydd datblygiad llyfrgelloedd fel RX. Tua 10 mlynedd yn ôl, gallai gwefan brin gefnogi hyn. Mae Cyrchu Digwyddiadau hefyd yn anhygoel o hawdd i'w sefydlu diolch i gynwysyddion parod gydag Apache Kafka. 10 mlynedd yn ôl byddai hyn wedi bod yn arloesi, nawr mae'n beth cyffredin. Mae'r un peth â Hosting Cynnwys Statig: oherwydd technolegau mwy cyfleus (gan gynnwys y ffaith bod dogfennaeth fanwl a chronfa ddata fawr o atebion), mae'r dull hwn wedi dod yn symlach fyth.

O ganlyniad, mae gweithredu nifer o batrymau pensaernïol eithaf cymhleth bellach wedi dod yn llawer symlach, sy'n golygu ei bod yn well edrych yn agosach arno ymlaen llaw. Os rhoddwyd y gorau i un o'r atebion uchod mewn cais deg oed oherwydd cost uchel gweithredu a gweithredu, nawr, mewn cymhwysiad newydd, neu ar ôl ail-ffactorio, gallwch greu gwasanaeth a fydd eisoes yn bensaernïol estynadwy ( o ran perfformiad) ac yn barod i geisiadau newydd gan gleientiaid (er enghraifft, i leoleiddio data personol).

Ac yn bwysicaf oll: peidiwch â defnyddio'r dulliau hyn os oes gennych gymhwysiad syml. Ydyn, maen nhw'n brydferth ac yn ddiddorol, ond ar gyfer safle sydd ag ymweliad brig o 100 o bobl, yn aml gallwch chi fynd heibio gyda monolith clasurol (o leiaf ar y tu allan, gellir rhannu popeth y tu mewn yn fodiwlau, ac ati).

Ffynhonnell: hab.com