Bedaŭrinde ĉi tiu termino ne havas bonan ruslingvan analogon. Vikipedio donas "multi-tenancy, multobla luado." Tio foje estas nomita "multobla proprieto." Ĉi tiuj terminoj povas esti iom konfuzaj, ĉar la temo ne estas esence rilata al aŭ luado aŭ posedado. Ĉi tio estas demando de programara arkitekturo kaj organizo de ĝia funkciado. Kaj la lasta ne estas malpli grava.
Ni komencis formuli nian komprenon pri plurtenado samtempe kiam ni komencis desegni aliron al la nuba (serva) modelo de laboro en 1C:Enterprise. Ĉi tio estis antaŭ pluraj jaroj. Kaj ekde tiam nia kompreno senĉese plivastiĝis. Ni konstante malkovras pli kaj pli da novaj aspektoj de tiu ĉi temo (profitoj, malavantaĝoj, malfacilaĵoj, trajtoj, ktp.).
Kelkfoje programistoj komprenas plurtenadon kiel tre simpla temo: "por ke la datumoj de pluraj organizoj estu konservitaj en unu datumbazo, vi devas aldoni kolumnon kun la organizidentigilo al ĉiuj tabeloj kaj agordi filtrilon sur ĝi." Ni kompreneble ankaŭ komencis nian studon de la afero ekde ĉi tiu momento. Sed ili rapide komprenis, ke tio estas nur unu maldensejo (ankaŭ, cetere, ne facila). Ĝenerale, ĉi tio estas "tuta lando".
La baza ideo de plurtenado povas esti priskribita kiel ĉi tio. Tipa apliko estas dometo desegnita por gastigi unu familion, kiu uzas sian infrastrukturon (muroj, tegmento, akvoprovizado, hejtado ktp.). Plurtenanta aplikaĵo estas etaĝkonstruaĵo. En ĝi, ĉiu familio uzas la saman infrastrukturon, sed la infrastrukturo mem estas efektivigita por la tuta domo.
Ĉu la plurtena aliro estas bona aŭ malbona? Vi povas trovi tre malsamajn opiniojn pri tio. Ŝajnas, ke tute ne ekzistas "bona aŭ malbona". Vi devas kompari la avantaĝojn kaj malavantaĝojn en la kunteksto de la specifaj taskoj solvitaj. Sed ĉi tio estas aparta temo...
En ĝia plej simpla signifo, la celo de plurtenado estas redukti la koston de konservado de aplikaĵo "socialigante" infrastrukturkostojn. Ĉi tio estas la sama movado kiel redukti la koston de aplikaĵo uzante produktadsolvon (eble kun personigo kaj modifo), anstataŭ skribi ĝin "por mendi". Nur en unu kazo la evoluo socialiĝas, kaj en la alia - la ekspluatado.
Krome, ni ripetas, ne ekzistas rekta ligo al la metodo de vendo. Multluanta arkitekturo ankaŭ povas esti uzata en kompania aŭ departementa IT-infrastrukturo por aŭtomatigi grandan nombron da similaj branĉoj kaj posedentreprenoj.
Ni povas diri, ke plurtenado ne estas nur demando pri organizado de datumstokado. Ĉi tio estas modelo de kiel la aplikaĵo funkcias kiel tutaĵo (inkluzive de signifa parto de sia arkitekturo, ĝia deplojmodelo kaj sia prizorga organizo).
La plej malfacila kaj interesa afero pri la plurtena modelo, ŝajnas al ni, estas, ke la esenco de la aplikaĵo "dubiĝas". Parto de la funkcieco funkcias kun specifaj datumaj areoj (apartamentoj) kaj "ne interesiĝas" pri tio, ke ekzistas loĝantoj en aliaj apartamentoj. Kaj iuj perceptas la domon kiel tuton kaj laboras por ĉiuj loĝantoj samtempe. Samtempe, ĉi-lasta ne povas ignori la fakton, ke ĉi tiuj estas, finfine, apartaj apartamentoj, kaj necesas certigi la necesan nivelon de granulareco kaj sekureco.
En 1C:Enterprise, la plurtena modelo estas efektivigita sur la nivelo de pluraj teknologioj. Ĉi tiuj estas la mekanismoj de la platformo 1C:Enterprise, la mekanismoj de"Kaj"", mekanismoj (bibliotekoj de normaj subsistemoj).
Ĉiu el ĉi tiuj eroj kontribuas al la konstruado de la totala infrastrukturo de etaĝkonstruaĵo. Kial ĉi tio estas efektivigita en pluraj teknologioj, kaj ne en unu, ekzemple, en platformo? Antaŭ ĉio, ĉar iuj el la mekanismoj, laŭ nia opinio, estas sufiĉe taŭgaj por modifi por specifa disfalda opcio. Sed ĝenerale, ĉi tio estas malfacila demando, kaj ni konstante alfrontas elekton - je kiu nivelo estas pli bone efektivigi ĉi tiun aŭ alian aspekton de plurtenado.
Evidente, la baza parto de la mekanismoj devis esti efektivigita en la platformo. Nu, ekzemple, la reala datuma apartigo. Ĉi tie homoj kutime komencas paroli pri plurtenado. Sed finfine, la plurtenanta modelo "vojaĝis" tra signifa parto de la mekanismoj de la platformo kaj postulis ilian rafinadon, kaj en iuj kazoj, repripensi.
Sur la platforma nivelo, ni efektivigis ĝuste la bazajn mekanismojn. Ili permesas al vi krei aplikojn, kiuj funkcias en plurtena modelo. Sed por ke aplikoj "vivu kaj laboru" en tia modelo, vi devas havi sistemon por administri iliajn "vivajn agadojn". 1cFresh-teknologioj kaj unuigita komerca logika tavolo ĉe la BSP-nivelo respondecas pri tio. Same kiel en etaĝkonstruaĵo la infrastrukturo provizas loĝantojn per ĉio, kion ili bezonas, tiel 1cFresh-teknologioj provizas ĉion, kion ili bezonas por aplikoj funkcianta en plurtenanta modelo. Kaj por ke aplikaĵoj povu interagi kun ĉi tiu infrastrukturo (sen signifaj modifoj), la respondaj "konektiloj" estas metitaj en ili en la formo de BSP-subsistemoj.
De la vidpunkto de platformaj mekanismoj, estas facile rimarki, ke dum ni akiras sperton kaj disvolvas la nuban uzkazon "1C:Enterprise", ni pligrandigas la komponadon de la mekanismoj kiuj estas implikitaj en ĉi tiu arkitekturo. Ni donu unu ekzemplon. En la plurtena modelo, la roloj de aplikaĵservopartoprenantoj ŝanĝiĝas signife. La rolo (nivelo de respondeco) de tiuj respondecaj pri funkciigado de aplikaĵoj signife pliiĝas. Iĝis necese, ke ili havu pli potencajn aplikajn kontroliloj. Ĉar aplikaĵuzantoj (loĝantoj) fidas antaŭ ĉio la provizanton kun kiu ili laboras. Por fari tion, ni efektivigis novan . Ĉi tiu mekanismo permesas al administrantoj de provizanto limigi la liberecon de programprogramistoj al la bezonata nivelo de sekureco - esence, izoli la funkciadon de la aplikaĵo por ĉiu luanto ene de certa sablokesto.
Ne malpli interesa estas la arkitekturo por administri aplikaĵojn funkciantajn en plurtena reĝimo (kio estas efektivigita en teknologioj 1cFresh kaj BSP). Ĉi tie, kompare kun la konvencia deplojmodelo, la postuloj por aŭtomatigo de administradprocezoj estas signife pliigitaj. Estas dekoj da tiaj procezoj: krei novajn datumajn areojn ("apartamentoj"), ĝisdatigi aplikojn, ĝisdatigi reguligajn informojn, sekurkopiojn, ktp. Kaj, kompreneble, la postuloj por la nivelo de fidindeco kaj havebleco pliiĝas. Ekzemple, por certigi fidindan interagadon inter aplikaĵoj kaj kontrolsistemaj komponantoj, ni efektivigis nesinkronan vokan sistemon teknologion kun garantiita livero.
Tre subtila punkto estas la maniero socialigi datumojn kaj procezojn. Ĝi ŝajnas simpla (se ŝajnas al iu) nur unuavide. La plej granda defio estas la ekvilibro inter centralizo de datumoj kaj procezoj kaj malcentralizo. Unuflanke, centralizo ebligas redukti kostojn (diskospaco, procesoraj rimedoj, administranto-klopodoj...). Aliflanke, ĝi limigas la liberecon de la "luantoj". Ĉi tio estas ĝuste unu el la momentoj de "forkiĝo" de la aplikaĵo, kiam la programisto devas pensi samtempe pri la aplikaĵo en la mallarĝa signifo (servante unu "loĝejon") kaj en la larĝa signifo (servante ĉiujn "luantoj" samtempe) .
Kiel ekzemplon de tia "dilemo", oni povas citi reguligajn kaj referencajn informojn. Kompreneble, estas granda tento igi ĝin komuna al ĉiuj "luantoj" de la domo. Ĉi tio permesas vin konservi ĝin en unu kopio kaj ĝisdatigi ĝin por ĉiuj samtempe. Sed okazas, ke iuj loĝantoj bezonas specifajn ŝanĝojn. Sufiĉe strange, praktike tio okazas, eĉ por informoj specifitaj de regulistoj (registaraj organoj). Ĉi tio montriĝas malfacila demando: societumi aŭ ne societumi? Tente estas kompreneble igi la informon ĝenerala por ĉiuj kaj privata por tiuj, kiuj volas ĝin. Kaj ĉi tio jam kondukas al tre malfacila efektivigo. Sed ni laboras pri tio...
Alia ekzemplo estas la dezajno de la efektivigo de regulaj procezoj (ekzekutita laŭ horaro, komencita de la kontrolsistemo, ktp.). Unuflanke, ili povas esti efektivigitaj por ĉiu datuma areo aparte. Ĝi estas pli facila kaj pli oportuna. Sed, aliflanke, tia bona granulareco kreas grandan ŝarĝon sur la sistemo. Por redukti la ŝarĝon, vi devas efektivigi sociajn procezojn. Sed ili postulas pli zorgan studon.
Kompreneble, ĉi tio levas tre gravan demandon. Kiel povas programistoj pri aplikaĵo certigi plurluantan? Kion ili devas fari por ĉi tio? Kompreneble, ni strebas certigi, ke la ŝarĝo de teknologiaj kaj infrastrukturaj aferoj falu kiel eble plej multe sur la ŝultrojn de la provizita teknologio, kaj la programisto de aplikaĵoj pensas nur pri komerca logika taskoj. Sed kiel kun aliaj gravaj arkitekturaj aferoj, aplikaĵprogramistoj devas havi iom da kompreno pri laboro en la plurtena modelo kaj iom da peno estos postulata dum evoluigado de aplikoj. Kial? Ĉar estas punktoj, kiujn teknologio ne povas provizi aŭtomate sen konsideri la semantikon de la datumoj. Ekzemple, la sama difino de la limoj de informasociigo. Sed ni provas teni ĉi tiujn malfacilaĵojn malgrandaj. Jam ekzistas ekzemploj de efektivigo de tiaj aplikoj.
Grava punkto en la kunteksto de efektivigado de plurtenado en 1C:Enterprise estas ke ni kreas hibridan modelon en kiu unu aplikaĵo povas funkcii ambaŭ en plurtena reĝimo kaj normala reĝimo. Tio estas tre malfacila tasko kaj temo de aparta diskuto.
fonto: www.habr.com