Fatkeq, ky term nuk ka një ekuivalent të mirë në gjuhën shqipe. "Wikipedia" e jep "multi-qiradhënie, qira e shumëfishtë". Ndonjëherë quhet "pronësi e shumëfishtë". Këto terma mund të jenë disi të ngatërrueshme, pasi subjekti nuk lidhet për nga thelbi as me qiranë, as me pronësinë. Është një çështje e arkitekturës së softuerit dhe organizimit të përdorimit të tij. Dhe në të vërtetë, kjo e fundit është po kaq e rëndësishme.
Kemi filluar të formojmë kuptimin tonë për multitenancy në të njëjtën kohë kur filluam të projektojmë qasje në modelin e punës cloud (shërbim) të "1C:Enterprise". Kjo ka ndodhur disa vite më parë. Që atëherë, kuptimi ynë është zgjeruar vazhdimisht. Po zbulojmë vazhdimisht aspekte të reja (përfitime, disavantazhe, vështirësi, veçori, etj.) të këtij subjekti.
Ndonjëherë zhvilluesit e kuptojnë multitenancy si një nënshkallë të thjeshtë: "për të ruajtur të dhënat e disa organizatave në një bazë të vetme, duhet të shtoni në të gjitha tabelat një kolonë me identifikuesin e organizatës dhe të vendosni një filter sipas saj". Natyrisht, ne gjithashtu kemi filluar punën tonë nga ky moment. Por shpesh e kuptuam shpejt që kjo është vetëm një fushë (po ashtu, ndonjëherë, e komplikuar). Në të vërtetë, kjo është një "vendet e tërë".
Ideja kryesore e multitenancy mund të përshkruhet përafërsisht kështu. Një aplikacion normal është një vilë e destinuar për një familje, e cila përdor infrastrukturën e saj (muret, çatia, ujësjellësi, ngrohja, etj.). Ndërsa një aplikacion multitenancy është një ndërtesë me disa apartamente. Aty, çdo familje përdor të njëjtin set infrastrukturash, por vetë infrastruktura është realizuar për të gjithë ndërtesën si një tërësi.
A është qëndrim i mirë apo i keq multitenancy? Mund të gjenden mendime shumë të ndryshme për këtë. Duke marrë parasysh, duket se nuk ka "mirë ose keq" në përgjithësi. Duhet të krahasohen përfitimet dhe disavantazhet në kontekstin e detyrave specifike që zgjidhen. Po, kjo është një temë e veçantë...
Në kuptimin më të thjeshtë, qëllimi i multitenancy është të ulet shpenzimet për mbështetje të aplikacionit përmes "shpërndarjes" së shpenzimeve për infrastrukturën. Kjo është një lëvizje e ngjashme me uljen e kostos së aplikacionit përmes përdorimit të zgjidhjeve të standardizuara (ndoshta, me konfigurim dhe modifikime), e jo me zhvillimin "në porosi". Në një rast, shpenzimet e zhvillimit shoqërohen, ndërsa në rastin tjetër, shfrytëzimi.
Janë të shumta, siç e theksuam, nuk ka një lidhje të drejtpërdrejtë me mënyrën e shitjes. Arkitektura multitenancy mund të aplikohet edhe në infrastrukturën IT korporative ose qeveritare për automatizimin e një numri të madh të degëve ose kompanive të ngjashme.
Mund të thuhet se multitenancy nuk është thjesht një çështje e organizimit të ruajtjes së të dhënave. Kjo është një model i punës së aplikacioneve në tërësi (duke përfshirë edhe një pjesë të konsiderueshme të aspekteve të arkitekturës së tij, modelin e deploy-it dhe organizimin e shërbimit).
E vështira dhe interesante në modelin multitenancy, sipas mendimit tonë, është se thelbi i aplikacionit “përçarë” në dy. Një pjesë e funksionalitetit punon me fusha të caktuara të të dhënave (apartamentet) dhe “nuk merret me” ata që kanë banesat në apartamente të tjera. Ndërsa një pjesë e tjetër e percepton shtëpinë në tërësi dhe punon menjëherë për të gjithë banorët. Në të njëjtën kohë, e fundit nuk mund të abstrahohet nga fakti që megjithatë ato janë apartamente të veçanta dhe është e nevojshme të sigurohet niveli i nevojshëm i granularitetit dhe sigurisë.
Në "1C: Ndërmarrja" modelin multitenancy e implementohet në nivelin e disa teknologjive. Këto janë mekanizmat e platformës "1C: Ndërmarrja", mekanizmat "» dhe ""; mekanizmat (bibliotekat e sistemeve standarde).
Çdo një nga këto objekte kontribuon në ndërtimin e infrastrukturës së përgjithshme të një ndërtese shumë apartamentesh. Pse kjo realizohet në disa teknologji dhe jo në një, p.sh. në platformë? Para së gjithash, sepse disa nga mekanizmat, sipas mendimit tonë, është plotësisht e përshtatshme t'i modifikosh në varësi të variantit të veprimit. Por në përgjithësi, ky është një çështje e ndërlikuar dhe ne vazhdimisht përballemi me vendimin – në cilin nivel është më mirë të realizohet një aspekt i caktuar i multitenancy.
Është e qartë se pjesa bazë e mekanizmave duhej të realizohej në platformë. Për shembull, ndarja e vetë të dhënave, e cila është zakonisht fillimi i bisedës për multitenancy. Por në fund, modeli multitenancy "kaloi" në një pjesë të konsiderueshme të mekanizmave të platformës dhe kërkoi përmirësimin e tyre, dhe në disa raste edhe rirëndim.
Në nivelin e platformës, ne kemi implementuar pikërisht mekanizmat bazë. Ata lejojnë krijimin e aplikacioneve që funksionojnë në modelin multitenancy. Por për të siguruar që aplikacionet "të jetojnë dhe të punojnë" në një model të tillë, është e nevojshme të kemi një sistem menaxhimi të "jetësimit" të tyre. Për këtë janë përgjegjës teknologjitë 1cFresh dhe shtresa e unifikuar e logjikës biznesore në nivelin e BSP. Ashtu si infrastruktura në një ndërtesë me shumë apartamente ofron të gjithë nevojat për banorët, kështu edhe teknologjitë 1cFresh sigurojnë të gjitha nevojat për aplikacionet që funksionojnë në modelin multitenancy. Dhe për të siguruar që aplikacionet mund të ndërveprojnë me këtë infrastrukturë (pa nevojën për ndërhyrje të konsiderueshme), në to vendosen "portat" përkatëse në formën e nënsistemeve të BSP.
Nga perspektiva e mekanizmave të platformës, është e lehtë të vëreni se me kalimin e kohës dhe zhvillimin e variantit të përdorimit në cloud të "1C:Ndërmarrjes", ne zgjerim përbërjen e mekanizmave që janë të angazhuar në këtë arkitekturë. Le të japim një shembull. Në modelin multitenancy, ndjeshëm ndryshon shpërndarja e rolave të participantëve në shërbimin e aplikacioneve. Roli (niveli i përgjegjësisë) i atyre që janë përgjegjës për funksionimin e aplikacioneve rritet ndjeshëm. Atëherë ata kanë nevojë për mjete më të fuqishme për kontrollin e aplikacioneve. Sepse përdoruesit e aplikacioneve (banorët) i besojnë para se gjithash ofruesit me të cilin ata punojnë. Për këtë arsye, ne kemi implementuar në versionin 8.3 një . Ky mekanizëm u jep administratorëve të ofruesit mundësinë për të kufizuar lirinë e zhvilluesve të aplikacioneve në nivelin e nevojshëm të sigurisë - në thelb, për të izoluar punën e aplikacionit për çdo banor brenda kornizave të caktuara të "sandbox-it".
Po një interes të madh përbën arkitektura për menaxhimin e aplikacioneve që punojnë në mënyrë multitenancy (e cila implementohet në teknologjitë 1cFresh dhe BSP). Këtu, krahasuar me modelin e zakonshëm të implementimit, kërkesat për automatizimin e proceseve të menaxhimit rriten dukshëm. Ka dhjetëra procese të tillë: krijimi i fushave të reja të të dhënave (“apartamenteve”), përditësimi i aplikacioneve, përditësimi i informacionit rregullator, kopjimi rezervë, etj. Dhe, sigurisht, kërkesat për nivelin e besueshmërisë dhe disponueshmërisë rriten. Për shembull, për të siguruar një bashkëpunim të besueshëm midis aplikacioneve dhe komponenteve të sistemit të menaxhimit, ne kemi implementuar një teknologji të sistemit asinkron të thirrjeve me shpërndarje të garantuar.
Një moment shumë delikat është mënyra e shpërndarjes së të dhënave dhe proceseve. Dukshëm, ndihmon të duket i thjeshtë (nëse dikujt i duket) vetëm në pamjen e parë. Vështirësinë më të madhe e paraqet balanca midis centralizimit të të dhënave dhe proceseve dhe decentralizimit. Nga njëra anë, centralizimi lejon të reduktojë shpenzimet (hapësirën e përkushtuar, burimet e procesorit, përpjekjet e administratorëve…). Nga ana tjetër, kufizon lirinë e “banorëve”. Pikërisht kjo është një nga pika e “ndarjes” së aplikacionit, kur zhvilluesi duhet të mendojë njëkohësisht për aplikacionin në kuptim të ngushtë (që shërben një “apartamenti”) dhe në kuptim të gjerë (që shërben të gjithë “banorët” në të njëjtën kohë).
Si një shembull i këtij “dileme” mund të paraqiten informatat rregullatore. Natyrisht, ka një joshje të madhe për ta bërë atë të zakonshëm për të gjithë “banorët” e shtëpisë. Kjo lejon gjithashtu ruajtjen e saj në një kopje dhe përditësimin e saj menjëherë për të gjithë. Por ndonjëherë ndodh që një banor ka nevojë për ndryshime specifike. Siç duket e çuditshme, por në praktikë kjo ndodh, madje për informacionin që është specifikuar nga rregullatorët (organet shtetërore). Së bashku, rezulton një pyetje e vështirë: a duhet të bëjmë të zakonshme apo jo? Sigurisht, është joshëse të krijojmë një informacion të përbashkët për të gjithë dhe një privat për ata që e duan. Por kjo të çon në një realizim të vështirë. Por mbi këtë ne punojmë…
Një shembull tjetër është projektimi i implementimit të proceseve të rregullta (të kryera sipas një programi, të iniciuara nga sistemi menaxhues, etj.). Nga njëra anë, ato mund të realizohen për çdo fushë të dhënash veçmas. Kjo është më e thjeshtë dhe më e rehatshme. Por, nga ana tjetër, kjo hollësi e vogël krijon një ngarkesë të madhe në sistem. Për të reduktuar ngarkesën, është e nevojshme të realizohen procese të centralizuara. Por ato kërkojnë një përpunim më të kujdesshëm.
Sigurisht, lind një pyetje ajo ndoshta mjaft e rëndësishme. Si mund t'u sigurohet zhvillueseve të aplikacioneve puna në mënyrë multitenancy? Çfarë duhet të bëjnë ata për këtë? Natyrisht, synojmë që peshat e pyetjeve teknologjike dhe infrastrukturore të bien sa më shumë mbi teknologjinë e ofruar, ndërsa zhvilluesi i aplikacionit të mendojë vetëm për problemet e logjikës biznesore. Por siç ndodh me çështje të tjera të rëndësishme arkitektonike, është e nevojshme që zhvilluesit e aplikacioneve të kenë njëfarë ideje mbi punën në modelin multitenancy dhe disa përpjekje gjatë zhvillimit të aplikacioneve do të kërkohen. Pse? Sepse ka momente që teknologjia nuk mund t'i sigurojë automatikisht pa marrë parasysh semantikën e të dhënave. Për shembull, po e njëjta përcaktim i kufijve të centralizimit të informacionit. Por ndihmojmë që këto vështirësi të jenë sa më të vogla. Shembuj të realizimit të tillë aplikacionesh tashmë ekzistojnë.
Një moment i rëndësishëm në kontekstin e implementimit të multitenancy në "1C: Ndërmarrja" është se ne krijojmë një model hibrid, në të cilin një aplikacion mund të punojë si në mënyrë multitenancy ashtu edhe në një mënyrë të zakonshme. Kjo është një detyrë mjaft e vështirë dhe një subjekt diskutimi të veçantë.
Burimi: habr.com
