Zoritxarrez, termino honek ez du errusierazko baliokide onik. Wikipediak ematen du "Alokairu anitza, alokairu anitza". Batzuetan "jabetza anitza" deitzen zaio horri. Termino hauek nahasgarriak izan daitezke, gaia funtsean ez baitago zerikusirik ez alokairuarekin ez jabetzarekin. Software arkitekturaren eta haren funtzionamenduaren antolaketaren kontua da. Azken hau ez da gutxiago garrantzitsua.
1C:Enpresarentzat hodeiko (zerbitzu) eragiketa-ereduaren ikuspegi bat diseinatzen hasi ginen aldi berean, multitenancy-aren ulermena garatzen hasi ginen. Duela urte batzuk izan zen hori. Eta ordutik, gure ulermena etengabe zabaltzen ari da. Gai honen alderdi berriak etengabe aurkitzen ari gara (aldekoak, txarrak, konplexutasunak, berezitasunak, etab.).
Batzuetan, garatzaileek multitenancy kontzeptu oso sinple gisa interpretatzen dute: "Erakunde anitzetako datuak datu-base bakarrean gordetzeko, erakundearen IDa duen zutabe bat gehitu behar diezu taula guztiei eta iragazki bat ezarri". Noski, puntu horretatik hasi ginen gai honi buruzko lana. Baina azkar konturatu ginen eremu bat besterik ez zela (eta konplexua, bide batez). Izan ere, "herrialde oso bat" da.
Maizter anitzen oinarrizko ideia honela deskriba daiteke gutxi gorabehera. Aplikazio tipiko bat familia bakar batentzat diseinatutako etxola bat da, eta familia horrek azpiegitura (hormak, teilatua, ur hornidura, berogailua, etab.) partekatzen du. Maizter anitzeko aplikazio bat, ordea, apartamentu eraikin bat da. Familia bakoitzak azpiegitura bera erabiltzen du, baina azpiegitura bera eraikin osoan ezartzen da.
Multitenancy ikuspegi ona ala txarra al da? Gai honi buruzko iritziak oso desberdinak dira. Badirudi ez dagoela "ona edo txarra" den ezer. Alde onak eta txarrak jorratzen diren erronka espezifikoekin alderatu behar dira. Baina hori beste gai bat da...
Zentzurik sinpleenean, jabekidetza anitzekoaren helburua aplikazioen mantentze-kostuak murriztea da azpiegitura-kostuak "sozializatuz". Aplikazio baten kostua murriztea bezalako ikuspegia da, irtenbide estandar bat erabiliz (agian pertsonalizazioarekin eta fintzearekin), irtenbide pertsonalizatu bat garatu beharrean. Aldea da kasu batean garapena sozializatu egiten dela, eta bestean, funtzionamendua.
Gainera, errepikatu dezagun, hau ez dago zuzenean salmenta-metodoarekin lotuta. Arkitektura multi-mailegu erraz aplika daiteke enpresa edo departamentuko IT azpiegituretan, antzeko sukurtsal edo holding-enpresa ugari automatizatzeko.
Esan liteke multitenancy datuen biltegiratzea antolatzea baino gehiago dela. Aplikazio osoaren funtzionamendurako eredu bat da (bere arkitekturaren alderdi esanguratsuak, bere hedapen eredua eta bere mantentze antolaketa barne).
Gure ustez, maiztasun anitzeko ereduaren alderdirik konplexuena eta interesgarriena aplikazioaren funtzionalitate nagusia bifurkatuta dagoela da. Funtzionalitate batzuek datu-eremu espezifikoekin (apartamentuekin) funtzionatzen dute eta ez dute ohartzen beste apartamentuetako bizilagunen presentziaz. Beste funtzionalitate batzuek eraikina osotasun gisa hautematen dute eta aldi berean bizilagun guztientzat funtzionatzen dute. Hala ere, azken honek ezin du alde batera utzi hauek, azken finean, apartamentu indibidualak direla, eta beharrezko granularitate eta segurtasun maila bermatu behar dela.
1C:Enpresan, maiztasun anitzeko eredua hainbat teknologiaren mailan ezartzen da. Hauek dira 1C:Enpresa plataformaren mekanismoak, mekanismoak"Eta"», mekanismoak (azpisistema estandarren liburutegiak).
Elementu horietako bakoitzak eraikin anitzeko maizter baten azpiegitura orokorrean laguntzen du. Zergatik ezartzen da hau hainbat teknologiatan, plataforma bakar batean baino? Batez ere, uste dugulako mekanismo batzuk egoki alda daitezkeela inplementazio-eszenatoki espezifiko baterako. Baina, oro har, gai konplexua da hau, eta etengabe aurkitzen dugu aukera zein geruza den onena maizter anitzeko alderdi bakoitza ezartzeko.
Argi zegoen oinarrizko mekanismoak plataforman ezarri behar zirela. Adibidez, datuen bereizketa bera —multi-tenantiaz eztabaidak abiarazten dituen motakoa—. Baina, azken finean, multi-tenancy ereduak plataformaren mekanismoen zati handi bat arriskuan jarri zuen eta haien fintzea eta, kasu batzuetan, birpentsatzea eskatu zuen.
Plataforma mailan, oinarrizko mekanismoak inplementatu genituen. Hauek maizter anitzeko eredu batean exekutatzen diren aplikazioak sortzea ahalbidetzen dute. Hala ere, aplikazioek eredu honetan behar bezala funtziona dezaten, haien bizi-zikloa kudeatzeko sistema bat behar da. Horretarako, 1cFresh teknologien eta negozio-logika geruza bateratu baten bidez lortzen da negozio-laguntza sistemaren (BSS) mailan. Apartamentu-eraikin bateko azpiegiturak bizilagunei behar duten guztia ematen dien bezala, 1cFresh teknologiek maizter anitzeko eredu batean exekutatzen diren aplikazioetarako beharrezko guztia eskaintzen dute. Aplikazioek azpiegitura honekin elkarreragin ahal izateko (aldaketa esanguratsurik gabe), "konektore" egokiak txertatzen dira BSS azpisistemen moduan.
Plataforma-mekanismoei dagokienez, erraza da ikustea esperientzia hartzen eta hodeian oinarritutako 1C:Enterprise irtenbidea garatzen dugun heinean, arkitektura honetan parte hartzen duten mekanismoak zabaltzen ari garela. Eman dezagun adibide bat. Multitenancy ereduan, aplikazioen mantentze-lanetako parte-hartzaileen arteko rolen banaketa nabarmen aldatzen da. Aplikazioen funtzionamenduaz arduratzen direnen rola (erantzukizun maila) nabarmen handitu da. Orain aplikazioen kontrol tresna indartsuagoak behar dituzte. Hau da, aplikazioen erabiltzaileek (maizterrek), lehenik eta behin, lan egiten duten hornitzailearengan konfiantza dutelako. Hori konpontzeko, funtzio berri bat ezarri dugu 8.3 bertsioan. Mekanismo honek hornitzaileen administratzaileei aplikazioen garatzaileen askatasuna beharrezko segurtasun mailara mugatzeko aukera ematen die; funtsean, aplikazioaren funtzionamendua maizter bakoitzarentzat sandbox espezifiko batean isolatuz.
Era berean, interesgarria da maizter anitzeko moduan exekutatzen diren aplikazioak kudeatzeko arkitektura (1cFresh eta BSP teknologietan inplementatzen den bezala). Hemen, inplementazio-eredu estandar batekin alderatuta, kudeaketa-prozesuak automatizatzeko eskakizunak nabarmen handiagoak dira. Horrelako dozenaka prozesu daude: datu-eremu berriak sortzea ("apartamentuak"), aplikazioak eguneratzea, arauzko informazioa eguneratzea, babeskopiak, eta abar. Eta, noski, fidagarritasun eta erabilgarritasun eskakizunak handitzen dira. Adibidez, aplikazioen eta kudeaketa-sistemaren osagaien arteko elkarrekintza fidagarria bermatzeko, entrega bermatua duen dei-sistema asinkrono bat inplementatu dugu.
Oso puntu sotila datuak eta prozesuak partekatzeko modua da. Erraza dirudi (inori hala iruditzen bazaio behintzat) lehen begiratuan bakarrik. Erronka handiena datuen eta prozesuen zentralizazioa deszentralizazioarekin orekatzean datza. Alde batetik, zentralizazioak kostuak murrizten ditu (disko espazioa, CPU baliabideak, administratzaileen ahalegina, etab.). Bestetik, "maizterren" askatasuna mugatzen du. Hain zuzen ere, aplikazioaren "bifurkazioaren" alderdietako bat da, garatzaileak aplikazioa zentzu estuan ("apartamentu" bati zerbitzatzen) eta zentzu zabalean ("maizter" guztiei aldi berean zerbitzatzen) kontuan hartu behar duenean.
"Dilema" horren adibide bat araudi- eta erreferentzia-informazioa da. Jakina, tentagarria da eraikin bateko "bizilagun" guztientzat komuna egitea. Horri esker, kopia bakarrean gorde daiteke eta aldi berean eguneratzen da guztiontzat. Baina batzuetan, bizilagun jakin batek aldaketa zehatzak behar ditu. Bitxia bada ere, praktikan gertatzen da hori, baita erregulatzaileek (gobernu-agentziak) zehaztutako informaziorako ere. Horrek galdera zail bat sortzen du: orokortu ala ez orokortu? Tentagarria da, noski, informazioa guztiontzat orokorra eta nahi dutenentzat pribatua egitea. Baina horrek inplementazio nahiko konplexua dakar. Baina lanean ari gara horretan...
Beste adibide bat ohiko prozesuen diseinua da (programatuak, kontrol-sistema batek abiarazitakoak, etab.). Alde batetik, datu-eremu bakoitzerako bereizita inplementatu daitezke. Hau errazagoa eta erosoagoa da. Hala ere, bestetik, inplementazio zehatz horrek karga handia sortzen du sisteman. Karga hori murrizteko, prozesu partekatuak inplementatu behar dira. Hala ere, hauek diseinu zainduagoa behar dute.
Jakina, honek galdera erabakigarri bat sortzen du. Nola berma dezakete aplikazioen garatzaileek multitenancy-a? Zer egin behar dute? Noski, ahaleginak egiten ditugu teknologia eta azpiegitura arazoen zama ahalik eta gehien hornitutako teknologiaren gain erortzen dela ziurtatzeko, aplikazioen garatzaileari negozio logika soilik pentsatzea utziz. Baina beste arkitektura arazo garrantzitsu batzuekin gertatzen den bezala, aplikazioen garatzaileek multitenancy-a nola funtzionatzen duen ulertu behar dute, eta ahalegin batzuk beharko dira aplikazioen garapenean. Zergatik? Datuen semantika kontuan hartu gabe teknologiak automatikoki konpondu ezin dituen alderdiak daudelako. Adibidez, partekatutako informazioaren mugak definitzea. Baina erronka horiek ahalik eta txikienak mantentzen saiatzen gara. Aplikazioen inplementazio horien adibideak badaude dagoeneko.
1C:Enpresan multitenancy ezartzeko alderdi garrantzitsu bat da aplikazio bakar batek multitenancy eta modu estandarrean funtziona dezakeen eredu hibrido bat sortzen ari garela. Zeregin oso konplexua da eta eztabaida bereizi baten gaia.
Iturria: www.habr.com
