Rhywsut, yn hanesyddol, mae’r diwydiant TG wedi’i rannu’n ddau wersyll amodol am unrhyw reswm: y rhai “o blaid” a’r rhai “yn erbyn”. Ar ben hynny, gall pwnc anghydfod fod yn gwbl fympwyol. Pa OS sy'n well: Win neu Linux? Ar ffôn clyfar Android neu iOS? A ddylech chi storio popeth yn y cymylau neu ei roi ar storfa RAID oer a rhoi'r sgriwiau mewn sêff? A oes gan bobl PHP yr hawl i gael eu galw'n rhaglenwyr? Mae'r anghydfodau hyn, ar adegau, yn gwbl ddirfodol eu natur ac nid oes iddynt unrhyw sail heblaw diddordeb mewn chwaraeon.
Yn union fel y digwyddodd, gyda dyfodiad cynwysyddion a'r holl fwyd annwyl hwn gyda docwyr a k8s amodol, y dechreuodd y dadleuon “o blaid” ac “yn erbyn” y defnydd o alluoedd newydd mewn amrywiol feysydd o'r backend. (Gadewch i ni archebu ymlaen llaw, er y bydd Kubernetes yn cael ei nodi amlaf fel cerddorfa yn y drafodaeth hon, nid yw dewis yr offeryn penodol hwn o bwysigrwydd sylfaenol. Yn lle hynny, gallwch amnewid unrhyw un arall sy'n ymddangos yn fwyaf cyfleus a chyfarwydd i chi .)
Ac, mae'n ymddangos, byddai hwn yn anghydfod syml rhwng dwy ochr yr un geiniog. Mor ddisynnwyr a didrugaredd â'r gwrthdaro tragwyddol rhwng Win vs Linux, lle mae digon o bobl yn bodoli rhywle yn y canol. Ond yn achos cynhwysydd, nid yw popeth mor syml. Fel arfer mewn anghydfodau o'r fath nid oes ochr dde, ond yn achos cynwysyddion “defnyddio” neu “beidio â defnyddio” ar gyfer storio cronfeydd data, mae popeth yn troi wyneb i waered. Oherwydd mewn rhai ystyr, mae cefnogwyr a gwrthwynebwyr y dull hwn yn iawn.
Ochr llachar
Gellir disgrifio dadl The Light Side yn fyr mewn un ymadrodd: “Helo, mae 2k19 y tu allan i’r ffenestr!” Mae'n swnio fel poblyddiaeth, wrth gwrs, ond os ydych chi'n ymchwilio'n fanwl i'r sefyllfa, mae ganddi ei fanteision. Gadewch i ni eu datrys nawr.
Gadewch i ni ddweud bod gennych chi brosiect gwe mawr. Gallai fod wedi'i adeiladu i ddechrau ar sail dull microwasanaeth, neu ar ryw adeg daeth ato trwy lwybr esblygiadol - nid yw hyn yn bwysig iawn, mewn gwirionedd. Fe wnaethoch chi wasgaru ein prosiect yn ficrowasanaethau ar wahân, sefydlu offeryniaeth, cydbwyso llwythi a graddio. Ac yn awr, gyda chydwybod glir, rydych chi'n sipian mojito mewn hamog yn ystod effeithiau habra yn lle codi gweinyddwyr sydd wedi cwympo. Ond ym mhob gweithred rhaid i chi fod yn gyson. Yn aml iawn, dim ond y cais ei hun - y cod - sy'n cael ei gynnwys mewn cynhwysydd. Beth arall sydd gennym ar wahân i god?
Mae hynny'n iawn, data. Calon unrhyw brosiect yw ei ddata: gall hyn fod naill ai'n DBMS nodweddiadol - MySQL, Postgre, MongoDB, neu storfa a ddefnyddir ar gyfer chwilio (ElasticSearch), storfa gwerth allweddol ar gyfer caching - er enghraifft, redis, ac ati Ar hyn o bryd nid ydym yn byddwn yn siarad am opsiynau gweithredu backend cam pan fydd y gronfa ddata yn chwalu oherwydd ymholiadau sydd wedi'u hysgrifennu'n wael, ac yn lle hynny byddwn yn siarad am sicrhau goddefgarwch nam ar yr union gronfa ddata hon o dan lwyth cleientiaid. Wedi'r cyfan, pan fyddwn yn amwys ein cais ac yn caniatáu iddo raddfa'n rhydd i brosesu unrhyw nifer o geisiadau sy'n dod i mewn, mae hyn yn naturiol yn cynyddu'r llwyth ar y gronfa ddata.
Mewn gwirionedd, mae'r sianel ar gyfer cyrchu'r gronfa ddata a'r gweinydd y mae'n rhedeg arno yn dod yn llygad y nodwydd yn ein hôl-wyneb cynhwysydd hardd. Ar yr un pryd, prif gymhelliad rhithwiroli cynhwysydd yw symudedd a hyblygrwydd y strwythur, sy'n ein galluogi i drefnu dosbarthiad llwythi brig ar draws y seilwaith cyfan sydd ar gael i ni mor effeithlon â phosibl. Hynny yw, os na fyddwn yn amwys ac yn cyflwyno holl elfennau presennol y system ar draws y clwstwr, rydym yn gwneud camgymeriad difrifol iawn.
Mae'n llawer mwy rhesymegol clystyru nid yn unig y cymhwysiad ei hun, ond hefyd y gwasanaethau sy'n gyfrifol am storio data. Trwy glystyru a defnyddio gweinyddwyr gwe sy'n gweithio'n annibynnol ac yn dosbarthu'r llwyth ymhlith ei gilydd mewn k8s, rydym eisoes yn datrys y broblem o gydamseru data - yr un sylwadau ar bostiadau, os cymerwn rywfaint o lwyfan cyfryngau neu blog fel enghraifft. Beth bynnag, mae gennym gynrychiolaeth o fewn clwstwr, hyd yn oed rhithwir, o'r gronfa ddata fel Gwasanaeth Allanol. Y cwestiwn yw nad yw'r gronfa ddata ei hun wedi'i chlystyru eto - mae'r gweinyddwyr gwe a ddefnyddir yn y ciwb yn cymryd gwybodaeth am newidiadau o'n cronfa ddata ymladd statig, sy'n cylchdroi ar wahân.
Ydych chi'n synhwyro dal? Rydym yn defnyddio k8s neu Swarm i ddosbarthu'r llwyth ac osgoi chwalu'r prif weinydd gwe, ond nid ydym yn gwneud hyn ar gyfer y gronfa ddata. Ond os bydd y gronfa ddata yn chwalu, yna nid yw ein seilwaith clystyrog cyfan yn gwneud unrhyw synnwyr - pa les yw tudalennau gwe gwag sy'n dychwelyd gwall mynediad cronfa ddata?
Dyna pam mae angen clystyru nid yn unig gweinyddwyr gwe, fel y gwneir fel arfer, ond hefyd seilwaith y gronfa ddata. Dim ond fel hyn y gallwn sicrhau strwythur sy'n gweithio'n llawn mewn un tîm, ond ar yr un pryd yn annibynnol ar ei gilydd. Ar ben hynny, hyd yn oed os bydd hanner ein hôl-ôl yn “llewygu” dan lwyth, bydd y gweddill yn goroesi, a bydd y system o gydamseru’r cronfeydd data â’i gilydd o fewn y clwstwr a’r gallu i raddfa a defnyddio clystyrau newydd yn ddiddiwedd yn helpu i gyrraedd y capasiti gofynnol yn gyflym - os mai dim ond rheseli oedd yn y ganolfan ddata .
Yn ogystal, mae model y gronfa ddata a ddosberthir mewn clystyrau yn caniatáu ichi fynd â'r union gronfa ddata hon i'r man lle mae ei hangen; Os ydym yn sôn am wasanaeth byd-eang, yna mae'n eithaf afresymegol i nyddu clwstwr gwe yn rhywle yn ardal San Francisco ac ar yr un pryd anfon pecynnau wrth gyrchu cronfa ddata yn rhanbarth Moscow ac yn ôl.
Hefyd, mae cynhwysydd y gronfa ddata yn caniatáu ichi adeiladu holl elfennau'r system ar yr un lefel o echdynnu. Sydd, yn ei dro, yn ei gwneud hi'n bosibl rheoli'r union system hon yn uniongyrchol o god, gan ddatblygwyr, heb gyfranogiad gweithredol gweinyddwyr. Roedd y datblygwyr yn meddwl bod angen DBMS ar wahân ar gyfer yr is-brosiect newydd - hawdd! ysgrifennu ffeil yaml, ei uwchlwytho i'r clwstwr ac rydych chi wedi gorffen.
Ac wrth gwrs, mae gweithrediad mewnol yn cael ei symleiddio'n fawr. Dywedwch wrthyf, sawl gwaith ydych chi wedi cau eich llygaid pan fydd aelod newydd o'r tîm wedi rhoi ei ddwylo yn y gronfa ddata ymladd ar gyfer gwaith? Pa un, mewn gwirionedd, yw'r unig un sydd gennych chi ac sy'n troelli ar hyn o bryd? Wrth gwrs, rydyn ni i gyd yn oedolion yma, ac yn rhywle mae gennym ni wrth gefn newydd, a hyd yn oed ymhellach i ffwrdd - y tu ôl i'r silff gyda chiwcymbrau mam-gu a hen sgïau - wrth gefn arall, efallai hyd yn oed mewn storfa oer, oherwydd roedd eich swyddfa eisoes ar dân unwaith. Ond yr un peth, mae pob cyflwyniad o aelod tîm newydd sydd â mynediad i'r seilwaith ymladd ac, wrth gwrs, i'r gronfa ddata ymladd yn fwced o ddilysrwydd i bawb o gwmpas. Wel, pwy sy'n ei nabod e, newbie, falle ei fod e'n draws law? Mae'n frawychus, byddwch yn cytuno.
Mae cynhwysiant ac, mewn gwirionedd, topoleg ffisegol ddosbarthedig cronfa ddata eich prosiect yn helpu i osgoi eiliadau dilysu o'r fath. Peidiwch ag ymddiried mewn newbie? IAWN! Gadewch i ni roi ei glwstwr ei hun iddo weithio gyda a datgysylltu'r gronfa ddata o'r clystyrau eraill - cydamseru yn unig trwy wthio â llaw a chylchdroi dwy allwedd yn gydamserol (un ar gyfer arweinydd y tîm, a'r llall ar gyfer y gweinyddwr). Ac mae pawb yn hapus.
Ac yn awr mae'n bryd newid i fod yn wrthwynebwyr clystyru cronfa ddata.
Ochr tywyll
Gan ddadlau pam nad yw’n werth rhoi’r gronfa ddata mewn cynhwysydd a pharhau i’w rhedeg ar un gweinydd canolog, ni fyddwn yn glynu at rethreg uniongrededd a datganiadau fel “roedd teidiau’n rhedeg cronfeydd data ar galedwedd, ac felly hefyd!” Yn lle hynny, gadewch i ni geisio dod o hyd i sefyllfa lle byddai cynwysyddion mewn gwirionedd yn talu difidendau diriaethol.
Cytuno, gall y prosiectau sydd wir angen sylfaen mewn cynhwysydd gael eu cyfrif ar fysedd un llaw gan nid y gweithredwr peiriant melino gorau. Ar y cyfan, mae hyd yn oed y defnydd o k8s neu Docker Swarm ei hun yn ddiangen - yn aml iawn mae'r offer hyn yn cael eu defnyddio oherwydd yr hype cyffredinol o dechnolegau ac agweddau'r “hollalluog” ym mherson y ddau ryw i wthio popeth i mewn i'r cymylau a chynwysyddion. Wel, oherwydd nawr mae'n ffasiynol ac mae pawb yn ei wneud.
Mewn o leiaf hanner yr achosion, mae defnyddio Kubernetis neu Docker yn unig ar brosiect yn ddiangen. Y mater yw nad yw pob tîm neu gwmni allanol a logir i gynnal seilwaith y cleient yn ymwybodol o hyn. Mae'n waeth pan osodir cynwysyddion, oherwydd mae'n costio swm penodol o ddarnau arian i'r cleient.
Yn gyffredinol, mae yna farn bod y maffia docwr / ciwb yn malu cleientiaid sy'n rhoi'r materion seilwaith hyn ar gontract allanol. Wedi'r cyfan, er mwyn gweithio gyda chlystyrau, mae angen peirianwyr arnom sy'n gallu gwneud hyn ac sy'n deall pensaernïaeth yr ateb a weithredir yn gyffredinol. Disgrifiwyd ein hachos gyda chyhoeddiad y Weriniaeth unwaith eisoes - yno fe wnaethom hyfforddi tîm y cleient i weithio yn realiti Kubernetis, ac roedd pawb yn fodlon. Ac roedd yn weddus. Yn aml, mae “gweithredwyr” k8s yn cymryd gwystl seilwaith y cleient - oherwydd nawr dim ond nhw sy'n deall sut mae popeth yn gweithio yno; nid oes unrhyw arbenigwyr ar ochr y cleient.
Nawr dychmygwch ein bod fel hyn yn rhoi rhan o weinydd y we ar gontract allanol, ond hefyd y gwaith cynnal a chadw cronfa ddata. Dywedasom mai BD yw'r galon, ac mae colli'r galon yn angheuol i unrhyw organeb byw. Yn fyr, nid y rhagolygon yw'r gorau. Felly, yn lle hype Kubernetis, ni ddylai llawer o brosiectau drafferthu â'r tariff arferol ar gyfer AWS, a fydd yn datrys yr holl broblemau gyda'r llwyth ar eu safle / prosiect. Ond nid yw AWS bellach yn ffasiynol, ac mae sioeau sioeau yn werth mwy nag arian - yn anffodus, yn yr amgylchedd TG hefyd.
IAWN. Efallai bod gwir angen clystyru’r prosiect, ond os yw popeth yn glir gyda chymwysiadau di-wladwriaeth, yna sut allwn ni drefnu cysylltedd rhwydwaith teilwng ar gyfer cronfa ddata glystyrog?
Os ydym yn sôn am ddatrysiad peirianneg di-dor, sef yr hyn yw'r newid i k8s, yna ein prif gur pen yw dyblygu data mewn cronfa ddata glystyrog. Mae rhai DBMSs i ddechrau yn eithaf teyrngar i ddosbarthiad data rhwng eu hachosion unigol. Nid yw llawer o rai eraill mor groesawgar. Ac yn eithaf aml nid y brif ddadl wrth ddewis DBMS ar gyfer ein prosiect yw'r gallu i'w ddyblygu heb fawr o gostau adnoddau a pheirianneg. Yn enwedig os nad oedd y prosiect wedi'i gynllunio i ddechrau fel microwasanaeth, ond yn syml wedi esblygu i'r cyfeiriad hwn.
Rydyn ni'n meddwl nad oes angen siarad am gyflymder gyriannau rhwydwaith - maen nhw'n araf. Y rhai. Nid oes gennym gyfle gwirioneddol o hyd, os bydd rhywbeth yn digwydd, i ailgychwyn enghraifft DBMS yn rhywle lle mae mwy, er enghraifft, pŵer prosesydd neu RAM am ddim. Byddwn yn rhedeg i mewn i berfformiad yr is-system disg rhithwir yn gyflym iawn. Yn unol â hynny, rhaid i'r DBMS gael ei hoelio ar ei set bersonol ei hun o beiriannau sydd wedi'u lleoli'n agos. Neu mae angen rhywsut oeri ar wahân cydamseru data digon cyflym ar gyfer y cronfeydd wrth gefn tybiedig.
Parhau â'r pwnc o systemau ffeiliau rhithwir: Yn anffodus, nid yw Docker Volumes yn rhydd o broblemau. Yn gyffredinol, mewn mater fel storio data dibynadwy yn y tymor hir, hoffwn ymwneud â'r cynlluniau mwyaf technegol syml. Ac mae ychwanegu haen tynnu newydd o FS y cynhwysydd i FS y rhiant letywr yn risg ynddo'i hun. Ond pan fydd gweithrediad y system cymorth cynhwysyddion hefyd yn dod ar draws anawsterau wrth drosglwyddo data rhwng yr haenau hyn, yna mae'n drychineb mewn gwirionedd. Ar hyn o bryd, mae'n ymddangos bod y rhan fwyaf o'r problemau sy'n hysbys i ddynoliaeth flaengar wedi'u dileu. Ond rydych chi'n deall, po fwyaf cymhleth yw'r mecanwaith, yr hawsaf y mae'n torri.
Yng ngoleuni'r holl “anturiaethau” hyn, mae'n llawer mwy proffidiol ac yn haws cadw'r gronfa ddata mewn un lle, a hyd yn oed os oes angen i chi gynnwys y cais, gadewch iddo redeg ar ei ben ei hun a thrwy'r porth dosbarthu dderbyn cyfathrebu ar yr un pryd â'r cronfa ddata, a ddarllenir ac a ysgrifennir unwaith yn unig ac Mewn un lle. Mae'r dull hwn yn lleihau'r tebygolrwydd o gamgymeriadau a dadgydamseru i'r lleiaf posibl.
Beth ydyn ni'n arwain ato? At hynny, mae cynhwysiant cronfa ddata yn briodol lle mae gwir angen amdano. Ni allwch stwffio cronfa ddata ap llawn a'i throelli fel pe bai gennych ddau ddwsin o ficrowasanaethau - nid yw'n gweithio felly. Ac mae'n rhaid deall hyn yn glir.
Yn hytrach nag allbwn
Os ydych chi'n aros am gasgliad clir “i rithwiroli'r gronfa ddata ai peidio,” yna byddwn yn eich siomi: ni fydd yma. Oherwydd wrth greu unrhyw ateb seilwaith, rhaid i un gael ei arwain nid gan ffasiwn a chynnydd, ond, yn gyntaf oll, gan synnwyr cyffredin.
Mae yna brosiectau y mae'r egwyddorion a'r offer sy'n dod gyda Kubernetis yn cyd-fynd yn berffaith ar eu cyfer, ac mewn prosiectau o'r fath mae heddwch o leiaf yn yr ardal gefn. Ac mae yna brosiectau nad oes angen eu cynhwysyddio, ond seilwaith gweinydd arferol, oherwydd yn y bôn ni allant ail-raddio i fodel clwstwr microwasanaeth, oherwydd byddant yn disgyn.
Ffynhonnell: hab.com