Kahjuks ei ole selle termini jaoks head eesti keeles vastet. "Vikipeedia" annab "multitenantsus, mitme rentimise". Mõnikord nimetatakse seda "mitme omandi". Need terminid võivad olla pisut segadust tekitavad, kuna teema ei ole põhimõtteliselt seotud ei rentimise ega omamisega. See on küsimus pigem tarkvara arhitektuurist ja selle kasutamise korraldamisest. Viimane on samuti mitte vähem oluline.
Hakkasime moodustama oma arusaama multitenantsusest samaaegselt sellega, kui alustasime lähenemise projekteerimist pilve (teenus) mudeli tööks "1C:Enterprise". See oli mitu aastat tagasi. Ja sellest ajast alates on meie arusaam pidevalt laienenud. Aeg-ajalt avastame selle teema juures uusi ja uusi aspekte (plussid, miinused, keerukused, omadused jne).
Mõnikord mõistavad arendajad multitenantsuse all täiesti lihtsat asja: "et mitme organisatsiooni andmed salvestataks ühes andmebaasis, tuleb lisada kõikidesse tabelitesse organisatsiooni identifikaatori veerg ja panna selle põhjal filter". Me alustasime muidugi ka oma teema käsitlemist sellest hetkest. Kuid üsna kiiresti mõistsime, et see on vaid üks valdkond (ka see pole muide lihtne). Aga tegelikult on see "täielik riik".
Põhiidee multitenantsuse kohta võib kirjeldada enam-vähem nii: Tavaline rakendus on suvila, mis on mõeldud ühe pere elamiseks, kes kasutab selle infrastruktuuri (seinad, katus, veevarustus, küte jne). Ja multitenantsuse rakendus on korterelamu. Selles kasutab iga pere samasugust infrastruktuuri, kuid kogu infrastruktuur on ellu viidud kogu maja jaoks tervikuna.
Kuid lähenemine multitenantsusele – kas see on hea või halb? Sellele võib leida väga erinevaid arvamusi. Tundub, et ei ole üldse "head või halba". Tuleb võrrelda plusse ja miinuseid konkreetsete lahendatavate ülesannete kontekstis. Kuid see on eraldi teema…
Tavalisest arusaamast on multitenantsuse eesmärk vähendada rakenduse hoolduskulusid, "ühiskondlikkuse" kaudu infrastruktuuri kulude jagamise kaudu. See on sama liikumine, mis seisneb rakenduse maksumuse vähendamises seeriakute rakendamise kaudu (võimalik, et konfigureerimise ja täiustamisega), mitte "tellimuse järgi" kirjutamise teel. Ainult ühes juhul on arendamine ühiskondlik, teises – ekspluateerimine.
Oluline on märkida, et siin ei ole otsest seost müügiarhiitktuuriga. Multitenancy arhitektuuri saab rakendada ka ettevõtte või ametiasutuse IT-infrastruktuuris, et automatiseerida suurt hulka sarnaseid filiaale ja kontserni ettevõtteid.
Võib öelda, et multitenancy ei ole pelgalt andmete salvestamise korraldamise küsimus. See on rakenduse töömudel tervikuna (sh olulised arhitektuuri aspektid, juurutusmudel ja hooldusteenindus).
Meie arvates on kõige keerulisem ja huvitavam multitenancy mudelis see, et rakenduse olemus "jaguneb". Osad funktsioonid töötavad konkreetsete andmevaldkondade (korterite) kallal ja ei "huvi" selle üle, kes elab teistes korterites. Teised funktsioonid tajuvad maja tervikuna ja töötavad kohe kõigi elanike heaks. Samas ei saa viimane abstraktselt eemalduda sellest, et tegemist on siiski eraldi korteritega ning tuleb tagada vajalik granulaarsuse ja turvalisuse tase.
„1C:Ettevõttes“ rakendatakse multitenancy mudelit mitmete tehnoloogiate tasandil. Need on „1C:Ettevõtte“ platvormi mehhanismid, mehhanismid „" ja "“ mehhanismid (standardalussüsteemide raamatukogud).
Igaüks neist elementidest panustab korterelamu ühisstruktuuri loomisse. Miks seda rakendatakse mitmete tehnoloogiate kaudu, mitte ühes, näiteks platvormis? Eelkõige seetõttu, et osa mehhanisme on meie arvates täiesti mõistlik modifitseerida konkreetse juurutusvaliku korral. Kuid üldiselt on see keeruline küsimus ning me seisame pidevalt valiku ees – millisel tasemel on parem rakendada ühte või teist multitenancy aspekti.
On ilmselge, et mehhanismide põhiosad oli vaja rakendada platvormis. Näiteks andmete eraldi jagamine. See on see, millega tavaliselt alustatakse juttu multitenancyst. Kuid lõpuks on multitenancy mudel "läbinud" suure osa platvormi mehhanismidest ja nõudnud nende täiustamist, mõnel juhul isegi ümbermõtestamist.
Platvormitasandil oleme rakendanud põhimehhanismid, mis võimaldavad luua multitenancy mudelil töötavaid rakendusi. Kuid et rakendused saaksid selles mudelis "elada ja töötada", on vajalik nende "elutegevust" juhtiv süsteem. Selle eest vastutavad tehnoloogiad 1cFresh ja ühtne äriloogika kiht BSP tasandil. Nii nagu korterelamus tagab infrastruktuur elanikele kõik vajaliku, nii varustavad tehnoloogiad 1cFresh kõik vajalikuga multitenancy mudelis töötavaid rakendusi. Ja et rakendused saaksid suhelda selle infrastruktuuriga (ilma oluliste kohandusteta), sisaldavad nad vastavaid "ühendusi" BSP alamsüsteemide näol.
Platvormi mehhanismide seisukohalt on lihtne märkida, et kogemuste saamise ja 1C:Enterprise'i pilvekasutuse arendamise käigus laiendame mehhanismide koosseisu, mis on kaasatud sellesse arhitektuuri. Toome ühe näite. Multitenancy mudelis muutub rakenduste hooldamise osaliste rollide jaotus oluliselt. Suurenev roll (vastutuse tase) on neil, kes vastutavad rakenduste käitamise eest. Neil on nüüd vaja võimsamaid rakenduste kontrollimisriistu. Sest rakenduse kasutajad (elanikud) usaldavad eelkõige teenusepakkujat, kellega nad töötavad. Sel eesmärgil oleme versioonis 8.3 rakendanud uue . See mehhanism võimaldab teenusepakkujate administraatoritel piirata rakenduste arendajate vabadust vajaliku turvataseme kaudu – tegelikult isoleerida rakenduse töö iga elaniku jaoks teatud "liivakasti" raames.
Suuremat huvi pakub arhitektuur, mis haldab multitenant-seisundis töötavaid rakendusi (mida rakendavad näiteks 1cFresh ja BSP). Siin, võrreldes tavalise juurutusmudeliga, tõusevad oluliselt protsesside haldamise automatiseerimise nõuded. Selliseid protsesse on kümneid: uute andmealade („korterite”) loomine, rakenduste uuendamine, regulatiivse teabe uuendamine, varundamine jne. Ja loomulikult tõusevad nõudmised usaldusväärsuse ja kättesaadavuse tasemele. Näiteks rakendus komponentide vahelise usaldusväärse suhtluse tagamiseks oleme rakendanud garantiiga tarnimisega asünkroonsete kutsesüsteemide tehnoloogia.
Väga õrn hetk on andmete ja protsesside sotsialiseerimise viis. Tundub lihtne (kui keegi arvab), kuid tegelikult on see keerulisem. Suurim väljakutse on tasakaalu leidmine andmete ja protsesside tsentraliseerimise ning detsentraliseerimise vahel. Ühest küljest võimaldab tsentraliseerimine vähendada kulusid (ketta ruumi, protsessorite ressursse, administraatorite pingutusi…). Teisest küljest piirab see „elanikke” vabadust. See on just see, kuidas rakenduse „lahknevuse” küsimus tekib, kui arendaja peab samaaegselt mõtlema rakendusele kitsas mõttes (teenindab ühte „korterit”) ja laiemas mõttes (teenindab kõiki „elanikke” samaaegselt).
Näiteks sellise „dilemma” näitena võib tuua regulatiivse teabe. Loomulikult on suur kiusatus teha see kõigile „elanikest” ühine. See võimaldab hoida seda ühes eksemplaris ja uuendada koheselt kõigile. Kuid juhtub, et mõnele elanikule on vajalikud spetsiifilised muudatused. Kuidas naljakas see ka ei tundu, esineb see praktikas isegi info puhul, mida reguleerivad ametiasutused (riiklikud organid). Tulemuseks on keeruline küsimus: sotsialiseerida või mitte sotsialiseerida? Loomulikult on ahvatlev teha kõigile ühine teave ja eraldi soovijatele. Kuid see viib juba palju keerulisema teostuse juurde. Aga me töötame selle nimel…
Veel ülevaate näide on regulaarsete protsesside (aega astutud, haldussüsteemi algatatud jne) rakendamise projekteerimine. Ühelt poolt saab neid ellu viia eraldi iga andmevaldkonna jaoks. See on lihtsam ja mugavam. Kuid teiselt poolt selline peen granulaarsus koormab süsteemi oluliselt. Koormuse vähendamiseks on vaja rakendada ühiseid protsesse. Kuid need nõuavad hoolikamat väljatöötamist.
Muidugi, tõstatub väga oluline küsimus. Kuidas tagada rakenduste arendajatele töö multitenancy režiimis? Mida nad peavad selleks tegema? Loomulikult püüame, et tehnoloogia ja infrastruktuuri probleemide raskus langeks võimalikult palju tarnitud tehnoloogia õlgadele, mistõttu rakenduse arendaja mõtleks ainult äriloogika ülesannetele. Kuid nagu teiste oluliste arhitektuuriliste küsimuste puhul, peab rakenduste arendajatel olema mingisugune arusaam multitenancy mudelisse töötamisest ja rakenduste arendamisel on vajalikud teatud jõupingutused. Miks? Sest on aspekte, mida tehnoloogia ei saa automaatselt tarnida ilma andmete semantikat arvesse võtmata. Näiteks sama info jagamise piiride määratlemine. Kuid me püüame, et need keerukused oleksid minimaalsed. Taoliste rakenduste elluviimise näiteid on juba olemas.
Oluline aspekt multitenancy rakendamise kontekstis "1C:Enterprise"-is on see, et loome hübriidmudeleid, kus üks rakendus saab töötada nii multitenancy, kui ka tavarežiimis. See on üsna keeruline ülesanne ja eraldi arutelu teema.
Allikas: habr.com
