Kahjuks ei ole sellel terminil head eestikeelset vastet. „Vikipeedia“ annab „mitmeüürilisus, mitme rentimise“. Mõnikord nimetatakse seda ka „mitmeomandiks“. Need terminid võivad olla veidi segadusttekitavad, kuna teema ei ole sisuliselt seotud ei rendiga ega omandiga. See on küsimus just tarkvara arhitektuurist ja selle kasutuse korraldamisest. Samas on viimane vähemalt sama oluline.
Alustasime oma arusaama mitmeüürilisusest samal ajal, kui hakkasime projekteerima lähenemist „1C:Ettevõtte“ pilve (teenuse) töö mudelile. See juhtus paar aastat tagasi. Sellest ajast alates laieneb meie arusaam pidevalt. Avastame pidevalt uusi ja uusi aspekte (plussid, miinused, keerukused, omadused jne).
Mõnikord mõistavad arendajad multitenancy alla üsna lihtsa asja: „et mitme organisatsiooni andmed salvestataks ühte andmebaasi, tuleb kõikidesse tabelitesse lisada organisatsiooni identifikaatori veerg ja selle kaudu filter seadistada“. Meie alustasime samuti oma uurimist tööd just sellest. Kuid üsna kiiresti mõistsime, et see on ainult üks vald (noh, ka mitte lihtne). Aga üldiselt on see „kogu riik“.
Multitenancy põhikirjeldus võiks välja näha umbes selline. Tavaline rakendus on nagu suvila, mis on mõeldud ühe perekonna elamiseks, kes kasutab selle infrastruktuuri (seinad, katus, veevarustus, kütmine jne). Multitenancy-rakendus on aga nagu korterelamu. Selles kasutab iga perekond samu infrastruktuuri elemente, kuid infrastruktuur on teostatud kogu maja jaoks tervikuna.
Aga on see multitenancy lähenemine hea või halb? Selle kohta võib leida väga erinevaid arvamusi. Tundub, et ei ole üldiselt „head või halba“. Tuleb võrrelda plusse ja miinuseid konkreetsete lahendatavate ülesannete kontekstis. Kuid see on eraldi teema...
Multitenancy eesmärk on lihtsas mõttes vähendada rakenduse hoolduskulusid, jagades infrastruktuuri kulud. See on sama põhimõte, mis rakenduse kulude vähendamine, kasutades valmislahendust (millele võib lisanduda kohandamine ja täiustamine) selle asemel, et kirjutada "tellimuse järgi". Ühes juhul jagatakse arenduskulud, teises aga käituskulud.
Oluline märkida, et siin ei ole otsest seost müügiviisiga. Multitenancy arhitektuuri saab rakendada ka ettevõtte või valitsusasutuse IT-infrastruktuuris, et automatiseerida mitmete sarnaste filiaalide või kontserni ettevõtete tegevust.
Võib öelda, et multitenancy ei ole pelgalt andmete salvestamise korraldamise küsimus. See on kogu rakenduse töö mudel (sealhulgas olulised aspektid selle arhitektuurist, juurutusmudel ja hooldamise korraldus).
Multitenancy mudeli kõige keerulisem ja huvitavam aspekt on see, et rakenduse olemus "jaguneb". Osad funktsioonidest töötavad konkreetsete andmevaldkondadega (korterite) ja "ei huvita", et teistes korterites on elanikud. Teine osa näeb maja tervikuna ja töötab kohe kõikide elanike jaoks. Sellegipoolest ei saa viimane ignoreerida, et tegemist on siiski eraldi korteritega, ning tuleb tagada vajalik granulaarsuse ja turvalisuse tase.
1C:Enterprise's on multitenancy mudel reaalselt rakendatud mitmete tehnoloogiate tasandil. Need on 1C:Enterprise platvormi mehhanismid, mehhanismid» ja «mehhanismid (standardsete alamsüsteemide raamatukogud).
Iga selle elemendi panus on oluline korterelamu üldise infrastruktuuri ülesehitamisel. Miks kasutatakse mitmeid tehnoloogiaid, mitte ainult ühte platvormina? Peamiselt seetõttu, et osa mehhanisme on meie arvates väga kohane kohandada vastavalt konkreetsele juurutusvariandile. Kuid üldiselt on see keeruline küsimus ja me seisame pidevalt valiku ees – millisel tasemel on kõige parem teostada ühte või teist multitenancy aspekti.
On selge, et platvormil pidi olema rakendatud põhimehhanismide osa. Näiteks andmete eraldamine. See, millega tavaliselt multitenancy arutelu algab. Kuid lõpuks on multitenancy mudel läbinud märkimisväärse osa platvormi mehhanisme ja nõudnud nende täiustamist ning mõnel juhul isegi ümbermõtestamist.
Platvormi tasandil oleme rakendanud põhimehhanismid. Need võimaldavad luua rakendusi, mis töötavad multitenant mudelil. Kuid et rakendused „elaksid ja töötaksid” sellises mudelis, on vajalik nende „toimetamise“ juhtimissüsteem. Selle eest vastutavad tehnoloogiad 1cFresh ja ühtne äriloogika kiht BSP tasandil. Nii nagu korterelamus tagab infrastruktuur elanikele kõik vajaliku, tagavad tehnoloogiad 1cFresh kõik vajaliku rakendustele, mis töötavad multitenant mudelis. Et rakendused saaksid suhelda selle infrastruktuuriga (ilma oluliste muudatusteta), paigutatakse neisse vastavad „sadamad“ BSP alam süsteemide näol.
Platvormide mehhanismide seisukohalt on lihtne märgata, et kogemuse ja pilve kasutusvõimaluste arendamise käigus laiendame me mehhanismide koosseisu, mis on seotud selle arhitektuuriga. Toome ühe näite. Multitenant mudelis muutub oluliselt rakenduste haldamise osalejate rollide jaotus. Oluliselt suureneb vastutavate isikute roll rakenduste haldamisel. Nende jaoks on muutunud hädavajalikuks omada võimsamaid rakenduste kontrollimise tööriistu. Sest rakenduste kasutajad (üürnike) usaldavad eelkõige teenusepakkujat, kellega nad koos töötavad. Seetõttu oleme versioonis 8.3 rakendanud uue . See mehhanism võimaldab teenusepakkujate administraatoritel piirata rakenduste arendajate vabadust vajaliku turvalisuse tasemega – sisuliselt eraldada rakenduse töö iga üürniku jaoks teatud "liivakasti" (sandbox) raames.
Ainuski ei ole vähem huvitav multitenantsi režiimis töötavate rakenduste haldamise arhitektuur (mida rakendatakse 1cFresh ja BSP tehnoloogiates). Siin on võrreldes tavalise juurutusmudeliga oluliselt tõusnud nõudmised haldusprotsesside automatiseerimisele. Selliseid protsesse on kümneid: uute andmepiirkondade („korterite”) loomine, rakenduste uuendamine, regulatiivse teabe värskendamine, varundamine jne. Ja muidugi suurenevad nõudmised usaldusväärsuse ja kättesaadavuse taseme suhtes. Näiteks rakenduste usaldusväärse suhtlemise tagamiseks haldussüsteemi komponentidega oleme rakendanud garanteeritud kohaletoimetamisega asünkroonse süsteemi kutse tehnoloogiat.
Andmete ja protsesside avalikustamine on äärmiselt delikaatne teema. Esmapilgul võib see tunduda lihtne (kui kellegi jaoks see tõesti nii on). Suurim väljakutse seisneb tasakaalu leidmises andmete ja protsesside tsentraliseerimise ning detsentraliseerimise vahel. Ühest küljest võimaldab tsentraliseerimine vähendada kulusid (ühe ketta ruumi, protsessori ressursse, haldurite vaeva...). Teiselt küljelt piirab see „elanikke“ vabadust. Just see on üks rakenduse „kaksipoole“ aspektidest, kus arendaja peab samal ajal mõtlema rakendusele kitsas mõttes (teenindades ühte „korterit“) ja laiemas mõttes (teenindades kõiki „elanikke“).
Kaasuseks sellisele "dilemmale" võib tuua normatiivse ja viidatud teabe. Muidugi on suur kiusatus teha see kõigile „elanikutele“ ühiseks. See võimaldab seda hoida ühes eksemplaris ja värskendada kohe kõigile. Kuid juhtub, et mõnel elanikul on vajalikud spetsiifilised muudatused. Kummalisel kombel esineb seda praktikas isegi teabe puhul, mis on reguleerivate asutuste (riigiasutuste) poolt specifitseeritud. Tulemuseks on keeruline küsimus: väljastada või mitte? Ahvatlev on muidugi teha ühine teave kõigile ja eraldi soovijatele. Kuid see toob kaasa täiesti keerulise rakenduse. Kuid me töötame selle nimel ...
Teiseks näiteks on regulaarsete protsesside (ajakavaliselt teostatavate, juhtsüsteemi algatatud jne) rakendamise projekteerimine. Ühelt poolt saab neid rakendada iga andmeala jaoks eraldi. See on lihtsam ja mugavam. Kuid teiselt poolt, selline peen granulaarsus loob süsteemile suure koormuse. Koormuse vähendamiseks tuleb ellu viia ühiselt jagatud protsesse. Kuid need nõuavad hoolikamat töötlemist.
Tõepoolest, tekib väga oluline küsimus. Kuidas saavad rakenduste arendajad tagada multitenantsuse režiimi toimimise? Mida peavad nad selleks tegema? Loomulikult püüame suunata tehnoloogiliste ja infrastruktuuri küsimuste koormuse nii palju kui võimalik kasutatavale tehnoloogiale, et rakenduste arendajad saaksid keskenduda vaid äriloogika ülesannetele. Kuid nagu teiste oluliste arhitektuuri küsimustega, peavad rakenduste arendajad olema teadlikud multitenantsuse mudeliga töötamisest ja teatud pingutusi rakenduste arendamisel on vajalik. Miks? Sest on hetki, mida tehnoloogia ei suuda automaatselt tagada, arvestamata andmete semantikat. Näiteks sama teabe jagamise piiride määratlemine. Kuid püüame, et need keerukused oleksid minimaalsed. Selliste rakenduste teostamise näiteid on juba olemas.
Oluline aspekt multitenantsuse rakendamisel "1C:Enterprise" kontekstis on see, et loome hübriidmudeleid, kus üks rakendus võib töötada nii multitenantsuse režiimis kui ka tavarežiimis. See on üsna keeruline ülesanne ja eraldi arutelu teema.
Allikas: habr.com
