Op een of ander manier, histories, is die IT-industrie om enige rede in twee voorwaardelike kampe verdeel: diegene wat "vir" is en diegene wat "teen" is. Boonop kan die onderwerp van geskille heeltemal arbitrêr wees. Watter bedryfstelsel is beter: Win of Linux? Op 'n Android- of iOS-slimfoon? Moet jy alles in die wolke bêre of dit op koue RAID-berging sit en die skroewe in 'n kluis sit? Het PHP-mense die reg om programmeerders genoem te word? Hierdie geskille is soms uitsluitlik eksistensieel van aard en het geen ander grondslag as sportbelang nie.
Dit het net so gebeur dat met die koms van houers en al hierdie geliefde kookkuns met docker en voorwaardelike k8's, die debatte "vir" en "teen" die gebruik van nuwe vermoëns in verskeie areas van die backend begin het. (Kom ons maak vooraf 'n bespreking dat alhoewel Kubernetes meestal as 'n orkestreerder in hierdie bespreking aangedui sal word, die keuse van hierdie spesifieke instrument nie van fundamentele belang is nie. In plaas daarvan kan jy enige ander een vervang wat vir jou die gerieflikste en bekendste lyk. .)
En, dit wil voorkom, sou dit 'n eenvoudige dispuut tussen twee kante van dieselfde munt wees. So sinneloos en genadeloos soos die ewige konfrontasie tussen Win vs Linux, waarin voldoende mense iewers in die middel bestaan. Maar in die geval van containerisering is alles nie so eenvoudig nie. Gewoonlik in sulke dispute is daar geen regterkant nie, maar in die geval van "gebruik" of "nie gebruik" houers vir die stoor van databasisse, draai alles onderstebo. Want in 'n sekere sin is beide ondersteuners en teenstanders van hierdie benadering reg.
Helder kant
The Light Side se argument kan kortliks beskryf word in een frase: "Hallo, 2k19 is buite die venster!" Dit klink natuurlik na populisme, maar as jy in detail in die situasie delf, het dit sy voordele. Kom ons sorteer hulle nou uit.
Kom ons sê jy het 'n groot webprojek. Dit kon aanvanklik gebou gewees het op die basis van 'n mikrodiensbenadering, of op 'n stadium het dit deur 'n evolusionêre pad daartoe gekom - dit is eintlik nie baie belangrik nie. Jy het ons projek in aparte mikrodienste versprei, orkestrasie opgestel, vragbalansering en skaal. En nou, met 'n skoon gewete, teug jy 'n mojito in 'n hangmat tydens habra-effekte in plaas daarvan om gevalle bedieners op te lig. Maar in alle aksies moet jy konsekwent wees. Baie dikwels word slegs die toepassing self - die kode - in 'n houer geplaas. Wat het ons nog behalwe kode?
Dit is reg, data. Die hart van enige projek is sy data: dit kan óf 'n tipiese DBMS wees - MySQL, Postgre, MongoDB, óf berging wat gebruik word vir soek (ElasticSearch), sleutelwaarde-berging vir cache - byvoorbeeld herdis, ens. Tans is ons nie ons sal praat oor krom backend-implementeringsopsies wanneer die databasis ineenstort as gevolg van swak geskrewe navrae, en in plaas daarvan sal ons praat oor die versekering van die fouttoleransie van hierdie einste databasis onder kliëntlading. Na alles, wanneer ons ons toepassing in 'n houer plaas en dit toelaat om vrylik te skaal om enige aantal inkomende versoeke te verwerk, verhoog dit natuurlik die las op die databasis.
Trouens, die kanaal vir toegang tot die databasis en die bediener waarop dit loop, word die oog van die naald in ons pragtige houer-agterkant. Terselfdertyd is die hoofmotief van houervirtualisering die mobiliteit en buigsaamheid van die struktuur, wat ons in staat stel om die verspreiding van piekvragte oor die hele infrastruktuur wat aan ons beskikbaar is so doeltreffend moontlik te organiseer. Dit wil sê, as ons nie al die bestaande elemente van die stelsel oor die cluster hou en uitrol nie, maak ons 'n baie ernstige fout.
Dit is baie meer logies om nie net die toepassing self te groepeer nie, maar ook die dienste wat verantwoordelik is vir die stoor van data. Deur webbedieners te groepeer en te ontplooi wat onafhanklik werk en die las onder mekaar in k8s versprei, los ons reeds die probleem van datasinchronisasie op - dieselfde opmerkings op plasings, as ons een of ander media- of blogplatform as voorbeeld neem. In elk geval, ons het 'n intra-kluster, selfs virtuele, voorstelling van die databasis as 'n eksterne diens. Die vraag is dat die databasis self nog nie gegroepeer is nie - die webbedieners wat in die kubus ontplooi is, neem inligting oor veranderinge van ons statiese gevegsdatabasis, wat afsonderlik roteer.
Voel jy 'n vangs? Ons gebruik k8s of Swarm om die las te versprei en te verhoed dat die hoofwebbediener ineenstort, maar ons doen dit nie vir die databasis nie. Maar as die databasis ineenstort, maak ons hele gegroepeerde infrastruktuur geen sin nie - wat help leë webblaaie wat 'n databasistoegangsfout gee?
Daarom is dit nodig om nie net webbedieners te groepeer nie, soos gewoonlik gedoen word, maar ook die databasis-infrastruktuur. Slegs so kan ons ’n struktuur verseker wat ten volle in een span werk, maar terselfdertyd onafhanklik van mekaar. Boonop, selfs as die helfte van ons agterkant “ineenstort” onder lading, sal die res oorleef, en die stelsel om die databasisse met mekaar binne die groepering te sinchroniseer en die vermoë om eindeloos te skaal en nuwe groepe te ontplooi sal help om vinnig die vereiste kapasiteit te bereik - as daar net rakke in die datasentrum was .
Daarbenewens laat die databasismodel wat in groepe versprei is jou toe om hierdie einste databasis te neem na waar dit nodig is; As ons van 'n globale diens praat, dan is dit nogal onlogies om 'n webgroep iewers in die San Francisco-omgewing op te spin en terselfdertyd pakkies te stuur wanneer u toegang tot 'n databasis in die Moskou-streek en terug kry.
Ook, houerisering van die databasis laat jou toe om alle elemente van die stelsel op dieselfde vlak van abstraksie te bou. Wat dit op sy beurt moontlik maak om hierdie einste stelsel direk vanaf kode te bestuur, deur ontwikkelaars, sonder die aktiewe betrokkenheid van administrateurs. Die ontwikkelaars het gedink dat 'n aparte DBBS nodig is vir die nuwe subprojek - maklik! het 'n yaml-lêer geskryf, dit na die cluster opgelaai en jy is klaar.
En natuurlik, interne werking is baie vereenvoudig. Sê vir my, hoeveel keer het jy jou oë toegemaak wanneer 'n nuwe spanlid sy hande in die gevegsdatabasis gesit het vir werk? Wat, in werklikheid, is die enigste een wat jy het en tans draai? Natuurlik is ons almal grootmense hier, en iewers het ons 'n vars rugsteun, en selfs verder weg - agter die rak met ouma se komkommers en ou ski's - nog 'n rugsteun, miskien selfs in koelkamer, want jou kantoor was al een keer aan die brand. Maar tog, elke bekendstelling van 'n nuwe spanlid met toegang tot die gevegsinfrastruktuur en natuurlik tot die gevegsdatabasis is 'n emmer vol geld vir almal rondom. Wel, wie ken hom, 'n nuweling, miskien is hy dwars? Dit is skrikwekkend, jy sal saamstem.
Houerisering en, in werklikheid, die verspreide fisiese topologie van u projek se databasis help om sulke validerende oomblikke te vermy. Vertrou nie 'n nuweling nie? OK! Kom ons gee hom sy eie groep om mee te werk en ontkoppel die databasis van die ander groepe - sinchronisasie slegs deur handdruk en sinchroniese rotasie van twee sleutels (een vir die spanleier, die ander vir die admin). En almal is gelukkig.
En nou is dit tyd om te verander in teenstanders van databasisgroepering.
Donker kant
As ons redeneer waarom dit nie die moeite werd is om die databasis te hou en voort te gaan om dit op een sentrale bediener te laat loop nie, sal ons nie buig vir die retoriek van ortodoksies en stellings soos "oupa's het databasisse op hardeware bestuur, en ons sal ook nie!" Kom ons probeer eerder om 'n situasie uit te dink waarin houerverpakking eintlik tasbare dividende sal betaal.
Stem saam, die projekte wat regtig 'n basis in 'n houer benodig, kan op die vingers van een hand getel word deur nie die beste freesmasjienoperateur nie. Vir die grootste deel is selfs die gebruik van k8's of Docker Swarm self oorbodig - dikwels word gebruik gemaak van hierdie instrumente as gevolg van die algemene hype van tegnologie en die houdings van die "almagtige" in die persoon van die geslagte om alles in die wolke en houers. Wel, want nou is dit mode en almal doen dit.
In ten minste die helfte van die gevalle is die gebruik van Kubernetis of net Docker op 'n projek oorbodig. Die probleem is dat nie alle spanne of uitkontrakteringsmaatskappye wat gehuur word om die kliënt se infrastruktuur in stand te hou hiervan bewus is nie. Dit is erger wanneer houers opgelê word, want dit kos 'n sekere hoeveelheid munte vir die kliënt.
Oor die algemeen is daar 'n opinie dat die docker/cube mafia dom kliënte verpletter wat hierdie infrastruktuurkwessies uitkontrakteer. Om met klusters te kan werk, het ons immers ingenieurs nodig wat daartoe in staat is en oor die algemeen die argitektuur van die geïmplementeerde oplossing verstaan. Ons het eenkeer reeds ons saak met die Republiekpublikasie beskryf - daar het ons die kliënt se span opgelei om in die realiteite van Kubernetis te werk, en almal was tevrede. En dit was ordentlik. Dikwels neem k8s se "implementeerders" die kliënt se infrastruktuur gyselaar - want nou verstaan net hulle hoe alles daar werk; daar is geen spesialiste aan die kliënt se kant nie.
Stel jou nou voor dat ons op hierdie manier nie net die webbediener-deel uitkontrakteer nie, maar ook die instandhouding van die databasis. Ons het gesê dat BD die hart is, en die verlies van die hart is dodelik vir enige lewende organisme. Kortom, die vooruitsigte is nie die beste nie. Dus, in plaas van 'n hype Kubernetis, moet baie projekte eenvoudig nie moeite doen met die normale tarief vir AWS nie, wat al die probleme met die las op hul webwerf/projek sal oplos. Maar AWS is nie meer modieus nie, en pronkstukke is meer werd as geld – ongelukkig ook in die IT-omgewing.
OK. Miskien het die projek regtig groepering nodig, maar as alles duidelik is met staatlose toepassings, hoe kan ons dan ordentlike netwerkverbinding vir 'n gegroepeerde databasis organiseer?
As ons praat van 'n naatlose ingenieursoplossing, wat die oorgang na k8s is, dan is ons hoofpyn data-replikasie in 'n gegroepeerde databasis. Sommige DBBS'e is aanvanklik redelik lojaal teenoor die verspreiding van data tussen hul individuele gevalle. Baie ander is nie so verwelkomend nie. En dikwels is die hoofargument in die keuse van 'n DBBS vir ons projek nie die vermoë om te repliseer met minimale hulpbron- en ingenieurskoste nie. Veral as die projek nie aanvanklik as 'n mikrodiens beplan is nie, maar bloot in hierdie rigting ontwikkel het.
Ons dink dit is nie nodig om oor die spoed van netwerkaandrywers te praat nie - hulle is stadig. Dié. Ons het steeds nie 'n werklike geleentheid om, as iets gebeur, 'n DBMS-instansie iewers te herbegin waar daar meer is nie, byvoorbeeld verwerkerkrag of vrye RAM. Ons sal baie vinnig die werkverrigting van die gevirtualiseerde skyfsubstelsel raakloop. Gevolglik moet die DBBS vasgespyker word aan sy eie persoonlike stel masjiene wat in die nabyheid geleë is. Of dit is nodig om op een of ander manier afsonderlik voldoende vinnige datasinchronisasie vir die veronderstelde reserwes af te koel.
Om die onderwerp van virtuele lêerstelsels voort te sit: Docker-volumes is ongelukkig nie probleemvry nie. Oor die algemeen, in so 'n saak soos langtermyn betroubare databerging, wil ek graag klaarkom met die tegnies eenvoudigste skemas. En die byvoeging van 'n nuwe abstraksielaag vanaf die houer se FS by die FS van die ouergasheer is 'n risiko op sigself. Maar wanneer die werking van die houer-ondersteuningstelsel ook probleme ondervind met die oordrag van data tussen hierdie lae, dan is dit regtig 'n ramp. Op die oomblik lyk dit of die meeste van die probleme wat aan die progressiewe mensdom bekend is, uitgeroei is. Maar jy verstaan, hoe meer kompleks die meganisme is, hoe makliker breek dit.
In die lig van al hierdie "avonture" is dit baie meer winsgewend en makliker om die databasis op een plek te hou, en selfs al moet jy die toepassing hou, laat dit op sy eie loop en deur die verspreidingspoort ontvang gelyktydige kommunikasie met die databasis, wat slegs een keer en op een plek gelees en geskryf sal word. Hierdie benadering verminder die waarskynlikheid van foute en desinchronisasie tot 'n minimum.
Waarheen lei ons? Boonop is databasishouerisering gepas waar daar 'n werklike behoefte daaraan is. Jy kan nie 'n volledige-toepassing databasis vul en draai dit asof jy twee dosyn mikrodienste het - dit werk nie so nie. En dit moet duidelik verstaan word.
In plaas van uitset
As jy wag vir 'n duidelike gevolgtrekking "om die databasis te virtualiseer of nie," dan sal ons jou teleurstel: dit sal nie hier wees nie. Want wanneer enige infrastruktuuroplossing geskep word, moet 'n mens nie gelei word deur mode en vooruitgang nie, maar eerstens deur gesonde verstand.
Daar is projekte waarvoor die beginsels en gereedskap wat saam met Kubernetis kom, perfek pas, en in sulke projekte is daar ten minste vrede in die backend-area. En daar is projekte wat nie containerisering nodig het nie, maar 'n normale bedienerinfrastruktuur, omdat hulle fundamenteel nie kan herskaal na die mikrodiensklustermodel nie, want hulle sal val.
Bron: will.com