Iel, historie, la IT-industrio estas dividita en du kondiĉajn tendarojn ial ajn: tiuj, kiuj estas "por" kaj tiuj, kiuj estas "kontraŭ". Krome, la temo de disputoj povas esti tute arbitra. Kiu OS estas pli bona: Win aŭ Linukso? Sur Android aŭ iOS-poŝtelefono? Ĉu vi devas stoki ĉion en la nuboj aŭ meti ĝin sur malvarman RAID-stokadon kaj meti la ŝraŭbojn en monŝrankon? Ĉu PHP-homoj rajtas esti nomataj programistoj? Tiuj disputoj estas, foje, ekskluzive ekzistecaj en naturo kaj havas neniun bazon krom sportintereso.
Okazis, ke kun la apero de ujoj kaj ĉio ĉi amata kuirarto kun docker kaj kondiĉaj k8s, komenciĝis la debatoj "por" kaj "kontraŭ" la uzo de novaj kapabloj en diversaj areoj de la backend. (Ni anticipe rezervu, ke kvankam Kubernetes plej ofte estos indikita kiel orkestranto en ĉi tiu diskuto, la elekto de ĉi tiu aparta ilo ne havas fundamentan gravecon. Anstataŭe, vi povas anstataŭigi ajnan alian, kiu ŝajnas al vi plej oportuna kaj konata. .)
Kaj, ŝajnus, ĉi tio estus simpla disputo inter du flankoj de la sama monero. Same sensenca kaj senkompata kiel la eterna konfrontiĝo inter Win kontraŭ Linukso, en kiu taŭgaj homoj ekzistas ie en la mezo. Sed en la kazo de kontenerigo, ne ĉio estas tiel simpla. Kutime en tiaj disputoj ne ekzistas dekstra flanko, sed en la kazo de "uzu" aŭ "ne uzi" ujojn por konservi datumbazojn, ĉio renversiĝas. Ĉar en certa signifo, ambaŭ subtenantoj kaj kontraŭuloj de ĉi tiu aliro pravas.
Hela flanko
La argumento de la Luma Flanko povas esti mallonge priskribita en unu frazo: "Saluton, 2k19 estas ekster la fenestro!" Ĝi sonas kiel popolismo, kompreneble, sed se vi detale enprofundiĝas en la situacion, ĝi havas siajn avantaĝojn. Ni ordigu ilin nun.
Ni diru, ke vi havas grandan retprojekton. Ĝi povus esti komence konstruita surbaze de mikroserva aliro, aŭ iam ĝi venis al ĝi per evolua vojo - tio ne estas tre grava, fakte. Vi disigis nian projekton en apartajn mikroservojn, starigis instrumentadon, ŝarĝan ekvilibron kaj skalon. Kaj nun, kun trankvila konscienco, vi trinketas mojiton en hamako dum habra efikoj anstataŭ levi falintajn servilojn. Sed en ĉiuj agoj vi devas esti konsekvenca. Tre ofte, nur la aplikaĵo mem—la kodo—estas kontenerigita. Kion alian ni havas krom kodo?
Ĝuste, datumoj. La koro de iu projekto estas ĝiaj datumoj: ĉi tio povas esti aŭ tipa DBMS - MySQL, Postgre, MongoDB, aŭ stokado uzata por serĉo (ElasticSearch), ŝlosilvalora stokado por kaŝmemoro - ekzemple, redis, ktp. Nuntempe ni ne estas. ni parolos pri malrektaj realigaj opcioj kiam la datumbazo kraŝas pro malbone skribitaj demandoj, kaj anstataŭe ni parolos pri certigado de la misfunkciado de ĉi tiu datumbazo sub klienta ŝarĝo. Post ĉio, kiam ni kontenerigas nian aplikaĵon kaj permesas ĝin libere skali por procesi ajnan nombron da envenantaj petoj, tio nature pliigas la ŝarĝon sur la datumbazo.
Fakte, la kanalo por aliri la datumbazon kaj la servilon, sur kiu ĝi funkcias, fariĝas la okulo de la kudrilo en nia bela kontenerita backend. Samtempe, la ĉefa motivo de ujo-virtualigo estas la movebleco kaj fleksebleco de la strukturo, kio permesas al ni organizi la distribuadon de pintaj ŝarĝoj tra la tuta infrastrukturo disponebla al ni kiel eble plej efike. Tio estas, se ni ne kontenerigas kaj disvolvas ĉiujn ekzistantajn elementojn de la sistemo tra la areto, ni faras tre gravan eraron.
Estas multe pli logike grupigi ne nur la aplikaĵon mem, sed ankaŭ la servojn respondecajn pri stokado de datumoj. Kunigante kaj deplojante retservilojn, kiuj funkcias sendepende kaj distribuas la ŝarĝon inter si en k8s, ni jam solvas la problemon de datumsinkronigo - la samaj komentoj pri afiŝoj, se ni prenas iun amaskomunikilaron aŭ blogplatformon kiel ekzemplon. Ĉiukaze, ni havas intra-areton, eĉ virtualan, reprezenton de la datumbazo kiel Ekstera Servo. La demando estas, ke la datumbazo mem ankoraŭ ne estas amasigita - la retserviloj deplojitaj en la kubo prenas informojn pri ŝanĝoj de nia senmova bataldatumbazo, kiu rotacias aparte.
Ĉu vi sentas kaptaĵon? Ni uzas k8s aŭ Swarm por distribui la ŝarĝon kaj eviti kraŝi la ĉefan retservilon, sed ni ne faras tion por la datumbazo. Sed se la datumbazo kraŝas, tiam nia tuta amasigita infrastrukturo havas neniun sencon - por kio utilas malplenaj retpaĝoj kiuj resendas eraron pri datumbaza aliro?
Tial necesas grupigi ne nur retservilojn, kiel oni kutime faras, sed ankaŭ la datumbazan infrastrukturon. Nur tiel ni povas certigi strukturon kiu funkcias plene en unu teamo, sed samtempe sendependa unu de la alia. Krome, eĉ se duono de nia backend "kolapsas" sub ŝarĝo, la resto pluvivos, kaj la sistemo sinkronigi la datumbazojn unu kun la alia ene de la areto kaj la kapablo senfine grimpi kaj deploji novajn aretojn helpos rapide atingi la bezonatan kapaciton - se nur estus rakoj en la datumcentro.
Krome, la datumbazomodelo distribuita en aretoj permesas vin porti ĉi tiun datumbazon al kie ĝi estas bezonata; Se ni parolas pri tutmonda servo, tiam estas tute mallogike ŝpini retan areton ie en la areo de San-Francisko kaj samtempe sendi pakaĵetojn alirante datumbazon en la Moskva regiono kaj reen.
Ankaŭ, kontenerigo de la datumbazo permesas konstrui ĉiujn elementojn de la sistemo je la sama nivelo de abstraktado. Kiu, siavice, ebligas administri ĉi tiun mem sistemon rekte de kodo, de programistoj, sen la aktiva implikiĝo de administrantoj. La programistoj opiniis, ke necesas aparta DBMS por la nova subprojekto - facile! skribis yaml-dosieron, alŝutis ĝin al la areto kaj vi finis.
Kaj kompreneble, interna funkciado estas tre simpligita. Diru al mi, kiom da fojoj vi fermis la okulojn kiam nova teamano metis siajn manojn en la bataldatumbazon por laboro? Kiu, fakte, estas la sola, kiun vi havas kaj turniĝas nun? Kompreneble, ni ĉiuj estas plenkreskuloj ĉi tie, kaj ie ni havas freŝan sekurkopion, kaj eĉ pli malproksime - malantaŭ la breto kun kukumoj de avino kaj malnovaj skioj - alia sekurkopio, eble eĉ en malvarma konservado, ĉar via oficejo jam unufoje ekbrulis. Sed tute egale, ĉiu enkonduko de nova teamano kun aliro al la batala infrastrukturo kaj, kompreneble, al la batala datumbazo estas sitelo da validol por ĉiuj ĉirkaŭe. Nu, kiu konas lin, novulo, eble li estas krucmana? Estas timiga, vi konsentos.
Kontenigo kaj, fakte, la distribuita fizika topologio de la datumbazo de via projekto helpas eviti tiajn validigajn momentojn. Ĉu vi ne fidas novulon? BONE! Ni donu al li sian propran areton por labori kaj malkonekti la datumbazon de la aliaj aretoj - sinkronigado nur per mana puŝo kaj sinkrona rotacio de du klavoj (unu por la teamestro, la alia por la administranto). Kaj ĉiuj estas feliĉaj.
Kaj nun estas tempo ŝanĝi al kontraŭuloj de datumbaza amasiĝo.
Malluma flanko
Argumentante kial ne indas kontenerigi la datumbazon kaj daŭrigi ruli ĝin sur unu centra servilo, ni ne kliniĝos al la retoriko de ortodoksoj kaj deklaroj kiel "avoj prizorgis datumbazojn sur aparataro, kaj ankaŭ ni!" Anstataŭe, ni provu elpensi situacion en kiu kontenerigo efektive pagus percepteblajn dividendojn.
Konsentu, la projektoj, kiuj vere bezonas bazon en ujo, povas esti kalkulitaj sur la fingroj de unu mano per ne la plej bona frezmaŝino-funkciigisto. Plejparte, eĉ la uzo de k8s aŭ Docker Swarm mem estas superflua - sufiĉe ofte ĉi tiuj iloj estas uzataj pro la ĝenerala ekzaktado de teknologioj kaj la sintenoj de la "ĉiopova" en la persono de la seksoj por puŝi ĉion en la nuboj kaj ujoj. Nu, ĉar nun ĝi estas modo kaj ĉiuj faras ĝin.
En almenaŭ duono de la kazoj, uzi Kubernetis aŭ nur Docker en projekto estas redunda. La problemo estas, ke ne ĉiuj teamoj aŭ subkontraktantaj kompanioj dungitaj por konservi la infrastrukturon de la kliento konscias pri tio. Estas pli malbone kiam ujoj estas truditaj, ĉar ĝi kostas certan kvanton da moneroj al la kliento.
Ĝenerale, estas opinio, ke la docker/kuba mafio stulte disbatas klientojn, kiuj subkontraktas ĉi tiujn infrastrukturajn problemojn. Post ĉio, por labori kun aretoj, ni bezonas inĝenierojn, kiuj kapablas ĉi tion kaj ĝenerale komprenas la arkitekturon de la efektivigita solvo. Ni iam priskribis nian kazon kun la publikigado de la Respubliko - tie ni trejnis la teamon de la kliento por labori en la realaĵoj de Kubernetis, kaj ĉiuj estis kontentaj. Kaj ĝi estis deca. Ofte, k8s "efektivigantoj" prenas la infrastrukturon de la kliento ostaĝon - ĉar nun nur ili komprenas kiel ĉio funkcias tie; ne estas specialistoj flanke de la kliento.
Nun imagu, ke tiamaniere ni subkontraktas ne nur la retservilan parton, sed ankaŭ la datumbazan prizorgadon. Ni diris, ke BD estas la koro, kaj la perdo de la koro estas mortiga por iu ajn vivanta organismo. Mallonge, la perspektivoj ne estas la plej bonaj. Do, anstataŭ hype Kubernetis, multaj projektoj simple ne devas ĝeni la normalan tarifon por AWS, kiu solvos ĉiujn problemojn kun la ŝarĝo sur sia retejo/projekto. Sed AWS ne plu estas moda, kaj montradoj valoras pli ol mono - bedaŭrinde ankaŭ en la IT-medio.
BONE. Eble la projekto vere bezonas clustering, sed se ĉio estas klara kun sennaciaj aplikoj, kiel ni povas organizi decan retan konekteblecon por amasigita datumbazo?
Se ni parolas pri senjunta inĝenieristiko, kio estas la transiro al k8s, tiam nia ĉefa kapdoloro estas reproduktado de datumoj en amasigita datumbazo. Kelkaj DBMSoj estas komence sufiĉe lojalaj al la distribuado de datumoj inter siaj individuaj kazoj. Multaj aliaj ne estas tiel bonvenaj. Kaj sufiĉe ofte la ĉefa argumento en elekto de DBMS por nia projekto ne estas la kapablo reprodukti kun minimumaj rimedoj kaj inĝenieraj kostoj. Precipe se la projekto ne estis komence planita kiel mikroservo, sed simple evoluis en ĉi tiu direkto.
Ni pensas, ke ne necesas paroli pri la rapideco de retaj diskoj - ili estas malrapidaj. Tiuj. Ni ankoraŭ ne havas realan ŝancon, se io okazas, rekomenci DBMS-instancon ie kie estas pli, ekzemple, procesora potenco aŭ libera RAM. Ni tre rapide renkontos la agadon de la virtualigita disksubsistemo. Sekve, la DBMS devas esti najlita al sia propra persona aro de maŝinoj situantaj proksime. Aŭ necesas iel aparte malvarmigi sufiĉe rapidan datumsinkronadon por la supozitaj rezervoj.
Daŭrigante la temon pri virtualaj dosiersistemoj: Docker Volumes, bedaŭrinde, ne estas senproblemaj. Ĝenerale, en tia afero kiel longtempa fidinda datumstokado, mi ŝatus kontentigi la plej teknike simplajn skemojn. Kaj aldoni novan abstraktan tavolon de la FS de la ujo al la FS de la gepatra gastiganto estas risko en si mem. Sed kiam la funkciado de la konteniga subtena sistemo ankaŭ renkontas malfacilaĵojn por transdoni datumojn inter ĉi tiuj tavoloj, tiam ĝi estas vere katastrofo. Nuntempe, la plej multaj el la problemoj konataj de la progresema homaro ŝajnas esti forigitaj. Sed vi komprenas, ju pli kompleksa estas la mekanismo, des pli facile ĝi rompiĝas.
En la lumo de ĉiuj ĉi tiuj "aventuroj", estas multe pli enspezige kaj pli facile konservi la datumbazon en unu loko, kaj eĉ se vi bezonas kontenerigi la aplikaĵon, lasu ĝin funkcii memstare kaj tra la distribua enirejo ricevi samtempan komunikadon kun la datumbazo, kiu estos legita kaj skribita nur unufoje kaj En unu loko. Ĉi tiu aliro reduktas la verŝajnecon de eraroj kaj malsinkronigo al minimumo.
Al kio ni kondukas? Plie, datumbaza kontenigo taŭgas kie estas vera bezono de ĝi. Vi ne povas plenigi plenan aplikan datumbazon kaj turni ĝin kvazaŭ vi havus du dekduojn da mikroservoj - ĝi ne funkcias tiel. Kaj ĉi tio devas esti klare komprenita.
Anstataŭ eligo
Se vi atendas klaran konkludon "por virtualigi la datumbazon aŭ ne", tiam ni seniluziigos vin: ĝi ne estos ĉi tie. Ĉar kiam oni kreas ajnan infrastrukturan solvon, oni devas gvidi ne per modo kaj progreso, sed, antaŭ ĉio, per komuna saĝo.
Estas projektoj, por kiuj la principoj kaj iloj, kiuj venas kun Kubernetis, perfekte taŭgas, kaj en tiaj projektoj estas paco almenaŭ en la backend-areo. Kaj estas projektoj, kiuj ne bezonas kontenerigon, sed normalan servilan infrastrukturon, ĉar ili esence ne povas reskali al la modelo de mikroservo cluster, ĉar ili falos.
fonto: www.habr.com