Zoritxarrez, termino honek ez du errusierazko analogiko ona. Wikipediak ematen du "errentamendu anitzeko, alokairu anitzeko". Batzuetan "jabetza anitza" deitzen zaio. Termino hauek nahasgarriak izan daitezke, gaia ez baitago berez lotuta ez alokairuarekin ez jabetzarekin. Hau software-arkitekturaren eta bere funtzionamenduaren antolaketaren kontua da. Eta azken hau ez da gutxiagorako.
1C:Enterprisen hodeiko (zerbitzu) lan-ereduaren ikuspegia diseinatzen hasi ginen aldi berean, maiztasun anitzeko ulermena formulatzen hasi ginen. Hau duela urte batzuk izan zen. Eta ordutik gure ulermena etengabe hedatu da. Etengabe deskubritzen ari gara gai honen alderdi berri gehiago (alde onak, txarrak, zailtasunak, ezaugarriak, etab.).
Batzuetan, garatzaileek askotarikotasuna oso gai sinple gisa ulertzen dute: "hainbat erakunderen datuak datu-base batean gordetzeko, erakundearen identifikatzailea duen zutabe bat gehitu behar duzu taula guztietan eta iragazki bat ezarri behar duzu". Guk ere, noski, une honetatik hasi ginen gaiaren azterketa egiten. Baina azkar konturatu ziren hori soilgune bakarra zela (gainera, bide batez, ez da erraza). Oro har, "herrialde osoa" da.
Anitzaren oinarrizko ideia honela deskriba daiteke. Aplikazio tipiko bat familia bat hartzeko diseinatutako txabola da, bere azpiegiturak erabiltzen dituena (hormak, teilatua, ur hornidura, berogailua, etab.). Maiztasun anitzeko aplikazioa etxebizitza eraikin bat da. Bertan, familia bakoitzak azpiegitura bera erabiltzen du, baina azpiegitura bera etxe osorako ezartzen da.
Maiztasun anitzeko planteamendua ona ala txarra da? Honen inguruan oso iritzi desberdinak aurki ditzakezu. Badirudi ez dagoela batere "ona edo txarrik". Ebazten diren ataza zehatzen testuinguruan alde onak eta txarrak alderatu behar dituzu. Baina hau aparteko gaia da...
Bere zentzurik sinpleenean, maiztasun anitzeko helburua aplikazio bat mantentzearen kostua murriztea da, azpiegituren kostuak "sozializatuz". Aplikazio baten kostua murriztearen mugimendu bera da ekoizpen-soluzio bat erabiliz (baliteke pertsonalizazio eta aldaketarekin), "eskaerara" idatzi beharrean. Kasu batean soilik gizarteratzen da garapena, eta, bestean, esplotazioa.
Gainera, errepikatzen dugu, ez dago lotura zuzenik salmenta metodoarekin. Maizte anitzeko arkitektura korporatibo edo departamentuetako IT azpiegitura batean ere erabil daiteke antzeko sukurtsal eta holding-enpresa ugari automatizatzeko.
Esan dezakegu maiztasun anitzekoa ez dela datuen biltegiratzea antolatzea soilik. Hau aplikazioak bere osotasunean funtzionatzen duen eredu bat da (bere arkitekturaren zati esanguratsu bat, inplementazio eredua eta mantentze-antolamendua barne).
Multitenancy ereduaren gauzarik zailena eta interesgarriena, iruditzen zaigu, aplikazioaren funtsa "biforkatu egiten da". Funtzionalitatearen zati batek datu-eremu zehatzekin (apartamentuak) funtzionatzen du eta beste apartamentu batzuetan bizilagunak egoteak "ez du interesatzen". Eta batzuek etxea osotasunean hautematen dute eta bizilagun guztientzat lan egiten dute aldi berean. Aldi berean, azken honek ezin du alde batera utzi, azken finean, apartamentu bereiziak direla, eta beharrezkoa da beharrezkoa den granularitate eta segurtasun maila bermatzea.
1C:Enterprisen, maiztasun anitzeko eredua hainbat teknologiaren mailan ezartzen da. Hauek dira 1C:Enterprise plataformaren mekanismoak, mekanismoak"Eta"", mekanismoak (azpisistema estandarren liburutegiak).
Elementu horietako bakoitzak etxebizitza-eraikin baten azpiegitura orokorraren eraikuntzan laguntzen du. Zergatik ezartzen da hori hainbat teknologiatan, eta ez batean, adibidez, plataforma batean? Lehenik eta behin, mekanismo batzuk, gure ustez, nahiko egokiak direlako hedapen-aukera zehatz baterako aldatzeko. Baina, oro har, galdera zaila da, eta etengabe aukera baten aurrean gaude: zein mailatan den hobe alokairu anitzeko alderdi hau edo beste ezartzea.
Jakina, mekanismoen oinarrizko zatia plataforman ezarri behar zen. Beno, adibidez, benetako datuen bereizketa. Hemen hasten da jendea normalean alokairu anitzari buruz hitz egiten. Baina, azkenean, maiztasun anitzeko ereduak plataformaren mekanismoen zati esanguratsu batean zehar "bidaiatu" zuen eta hobetu egin behar izan zuen, eta kasu batzuetan, birpentsatzea.
Plataforma mailan, zehazki, oinarrizko mekanismoak ezarri genituen. Maiztasun anitzeko ereduan exekutatzen diren aplikazioak sortzeko aukera ematen dute. Baina aplikazioak halako eredu batean "bizi eta lan egin" ahal izateko, haien "bizitzako jarduerak" kudeatzeko sistema bat izan behar duzu. 1cFresh teknologiak eta BSP mailan negozio logika geruza bateratua dira horren erantzule. Apartamentu-eraikin batean azpiegiturak bizilagunei behar duten guztia eskaintzen die bezala, 1cFresh teknologiek behar duten guztia eskaintzen dute maiztasun anitzeko ereduan exekutatzen diren aplikazioetarako. Eta aplikazioak azpiegitura honekin elkarreragin ahal izateko (aldaketa esanguratsurik gabe), dagozkien “konektoreak” jartzen dira horietan BSP azpisistema moduan.
Plataformen mekanismoen ikuspuntutik, erraza da ohartzea esperientzia lortu eta “1C:Enterprise” hodeiaren erabilera kasua garatzen dugun heinean, arkitektura honetan parte hartzen duten mekanismoen osaera zabaltzen ari garela. Eman dezagun adibide bat. Maiztasun anitzeko ereduan, aplikazio-zerbitzuetako parte-hartzaileen rolak nabarmen aldatzen dira. Aplikazioak ustiatzeko arduradunen rola (ardura-maila) nabarmen handitzen da. Beharrezkoa egin zitzaien aplikazioak kontrolatzeko tresna indartsuagoak izatea. Aplikazioen erabiltzaileek (egoiliarrek) lan egiten duten hornitzailearengan konfiantza dutelako. Horretarako, berri bat ezarri dugu . Mekanismo horri esker, hornitzaileen administratzaileei aplikazioen garatzaileen askatasuna behar den segurtasun-mailara mugatzea ahalbidetzen dute, funtsean, aplikazioaren funtzionamendua maizter bakoitzarentzat sandbox jakin batean isolatzeko.
Ez da gutxiagorako interesgarria maiztasun anitzeko moduan funtzionatzen duten aplikazioak kudeatzeko arkitektura (1cFresh eta BSP teknologietan ezartzen dena). Hemen, ohiko hedapen-ereduarekin alderatuta, kudeaketa-prozesuen automatizazio-eskakizunak nabarmen handitzen dira. Halako prozesu dozenaka daude: datu-eremu berriak sortzea (“apartamentuak”), aplikazioak eguneratzea, arauzko informazioa eguneratzea, segurtasun-kopiak... Eta, noski, fidagarritasun- eta erabilgarritasun-mailaren eskakizunak gero eta handiagoak dira. Esaterako, aplikazioen eta kontrol-sistemaren osagaien arteko interakzio fidagarria bermatzeko, dei-sistema asinkronoaren teknologia ezarri dugu entrega bermatuta.
Oso puntu sotila datuak eta prozesuak sozializatzeko modua da. Sinplea dirudi (norbaiti iruditzen bazaio) lehen begiratuan bakarrik. Erronka handiena datuen eta prozesuen zentralizazioaren eta deszentralizazioaren arteko oreka da. Alde batetik, zentralizazioak kostuak murrizteko aukera ematen du (diskoko espazioa, prozesadorearen baliabideak, administratzaileen ahaleginak...). Bestalde, “maizterren” askatasuna mugatzen du. Hau da, hain zuzen, aplikazioaren "bifurkazio" uneetako bat, garatzaileak aplikazioari buruz aldi berean pentsatu behar duenean zentzu estuan ("apartamentu bat" zerbitzatzen du) eta zentzu zabalean ("maizter guztiak" aldi berean zerbitzatzen ditu) .
"Dilema" horren adibide gisa, arauzko eta erreferentziazko informazioa aipa daiteke. Noski, tentazio handia dago etxeko “maizter” guztientzat komuna izateko. Horri esker, kopia batean gorde dezakezu eta guztiontzat aldi berean eguneratu. Baina gertatzen da bizilagun batzuek aldaketa zehatzak behar dituztela. Bitxia bada ere, praktikan hori gertatzen da, baita erregulatzaileek (gobernu erakundeek) zehazten duten informaziorako ere. Galdera zaila bihurtzen da hau: sozializatzea ala ez sozializatzea? Tentagarria da, noski, informazioa ororentzat orokor eta pribatua nahi duenarentzat. Eta honek dagoeneko oso zaila den ezarpena dakar. Baina horretan ari gara...
Beste adibide bat ohiko prozesuen ezarpenaren diseinua da (egutegi batean exekutatuta, kontrol sistemak hasitakoa, etab.). Alde batetik, datu-eremu bakoitzerako bereizita inplementa daitezke. Errazagoa eta erosoagoa da. Baina, bestalde, halako granularitate finak karga handia sortzen du sisteman. Karga murrizteko, prozesu sozializatuak ezarri behar dituzu. Baina azterketa zehatzagoa eskatzen dute.
Jakina, horrek galdera oso esanguratsu bat sortzen du. Nola berma dezakete aplikazioen garatzaileek maiztasun anitzeko? Zer egin behar dute horretarako? Jakina, ahalegin teknologikoen eta azpiegituren arazoen zama hornitutako teknologiaren sorbaldetan erortzen dela ziurtatzen dugu, eta aplikazioen garatzaileak negozio-logikako zereginetan bakarrik pentsatzen du. Baina beste arkitektura-gai garrantzitsu batzuekin gertatzen den bezala, aplikazioen garatzaileek nolabaiteko ulermena izan behar dute maiztasun anitzeko ereduan lan egiteko eta aplikazioak garatzerakoan ahalegin batzuk beharko dira. Zergatik? Teknologiak datuen semantika kontuan hartu gabe automatikoki eman ezin dituen puntuak daudelako. Adibidez, informazioaren sozializazioaren mugen definizio bera. Baina zailtasun horiek txikiak izaten saiatzen gara. Dagoeneko badaude aplikazio horien ezarpenaren adibideak.
1C:Enterprise-n maizte askoren ezarpenaren testuinguruan puntu garrantzitsu bat eredu hibrido bat sortzen ari garela da, zeinetan aplikazio batek maiztasun anitzeko moduan eta modu normalean funtziona dezakeen. Oso lan zaila da eta eztabaida berezi baten gaia da.
Iturria: www.habr.com