Fatkeqësisht, ky term nuk ka një ekuivalent të mirë në gjuhën shqipe. «Wikipedia» jep «multiarendim, qira e shumfishtë». Ndonjëherë quhet edhe «pronësi e shumfishtë». Këto terma mund të jenë paksa të ngatërruar, sepse subjekti nuk lidhet në thelb as me qiradhënien dhe as me pronësinë. Kjo është një çështje e arkitekturës së softuerit dhe organizatës së tij operuese. Kjo e fundit është po aq e rëndësishme.
Ne filluam të formojmë kuptimin tonë të multitenancy ndërsa filluam të projektin qasjen drejt modelit të punës me shërbim në «1C:Sipërmarrja». Kjo ndodhi disa vite më parë. Dhe që atëherë kuptimi ynë është zgjeruar vazhdimisht. Ne vazhdimisht zbulojmë aspekte të reja (përfitimet, disavantazhet, vështirësitë, veçoritë, etj.) lidhur me këtë temë.
Ndonjëherë zhvilluesit e kuptojnë multitenancy si një çështje mjaft të thjeshtë: «për të ruajtur të dhënat e disa organizatave në një bazë të vetme, është e nevojshme të shtoni një kolonë me identifikuesin e organizatës në të gjitha tabelat dhe të vendosni një filtrin mbi të». Ne gjithashtu, sigurisht, filluam punën tonë mbi këtë çështje nga ky moment. Por shpejt e kuptuam se kjo është vetëm një prej hapësirave (po ashtu, e ndërlikuar). Në të vërtetë, kjo është një «vendi i tërë».
Ideja kryesore e multitenancy mund të përshkruhet në mënyrë të thjeshtë. Një aplikacion i zakonshëm është një shtëpi, e cila është e destinuar për jetesën e një familjeje që përdor infrastrukturën e saj (muret, çatia, furnizimi me ujë, ngrohja, etj.). Një aplikacion multitenancy është një ndërtesë me apartamente. Në të, çdo familje përdor të njëjtën infrastrukturë, por infrastruktura është e ndërtuar për gjithë ndërtesën si një entitet të vetëm.
A është qasja e multitenancy e mirë apo e keqe? Në këtë pikë, mund të gjenden mendime shumë të ndryshme. Duke u dukur, nuk ka «mirë apo keq» në terma absolute. Duhet të krahasohen përfitimet dhe disavantazhet në kontekstin e detyrave specifike që zgjidhen. Por kjo është një temë e veçantë...
Në kuptimin më të thjeshtë, qëllimi i multitenancy është të zvogëlojë 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ë një zgjidhjeje të përdorur (ndoshta me konfigurojë dhe modifikim), në vend të shkruarjes "sipër porosi". Në një rast shoqërohet zhvillimi, e në tjetrin – operimi.
Ndërsa, të përsërisim, këtu nuk ka një lidhje të drejtpërdrejtë me mënyrën e shitjes. Arkitektura e multitenancy mund të aplikohet gjithashtu në infrastrukturën e IT korporative ose të institucioneve për automatizimin e një numri të madh të filialeve, ndërmarrjeve të grupit.
Mund të thuhet se multitenancy është jo vetëm një çështje e organizimit të ruajtjes së të dhënave. Kjo është një model pune i aplikacionit tërësisht (duke përfshirë një pjesë të konsiderueshme të aspekteve të arkitekturës së tij, modelin e implementimit, dhe organizimin e shërbimit).
Ajo që është më e komplikuar dhe interesante në modelin e multitenancy, siç na duket, është se thelbi i aplikacionit "ndahen". Një pjesë e funksionalitetit punon me fusha specifike të të dhënave (apartamentet) dhe "nuk ka interes" për atë që ndodhet në apartamentet e tjera. Ndërsa një pjesë e percepton ndërtesën si një tërësi dhe punon menjëherë për të gjithë banorët. Megjithatë, kjo e fundit nuk mund të abstenojë nga fakti se këto janë apartamente të veçanta, dhe duhet të sigurohet një nivel i nevojshëm granulariteti dhe sigurie.
Në «1C:Sipërmarrja», modeli i multitenancy implementohet në nivelin e disa teknologjive. Këto janë mekanizmat e platformës «1C: Sipërmarrja», mekanizmat e «» dhe «», mekanizmat (bibliotekat e sistemeve standarde).
Çdo një nga këto elemente kontribuon në ndërtimin e infrastrukturës së përgjithshme të ndërtesës me apartamente. Pse implementohet kjo në disa teknologji dhe jo në një të vetme, për shembull, në platformë? Para së gjithash, sepse disa mekanizma, sipas mendimit tonë, janë mjaft të përshtatshëm për t'u modifikuar në varësi të varianti konkret të implementimit. Por në përgjithësi, kjo është një çështje e ndërlikuar dhe ne vazhdimisht kemi përpara zgjedhjen – në cilin nivel është më e mirë të realizohet një aspekt i tillë i multitenancy.
E qartë se pjesa themelore e mekanizmave duhet të implementohet në platformë. Një shembull, ndarja e të dhënave. Kjo është ajo nga e cila zakonisht fillon biseda për multitenancy. Por në fund, modelin e multitenancy "kaloi" në një pjesë të konsiderueshme të mekanizmave të platformës dhe kërkoi përmirësime të tyre, ndonjëherë madje edhe rishqyrtim.
Në nivelin e platformës, ne kemi zhvilluar mekanizmat bazë. Këta lejojnë krijimin e aplikacioneve që funksionojnë në modelin multitenancy. Por për të siguruar që aplikacionet "të jetojnë dhe funksionojnë" në një model të tillë, është e nevojshme të kemi një sistem menaxhimi të "jetës" së tyre. Teknologjitë 1cFresh dhe shtresa e unifikuar e logjikës së biznesit në nivelin e BSP janë përgjegjëse për këtë. Ashtu si infrastruktura që siguron banorët me gjithçka të nevojshme në një ndërtesë shumëkatëshe, teknologjitë 1cFresh ofrojnë gjithçka të nevojshme për aplikacionet që operojnë në modelin multitenancy. Dhe për t'i lejuar aplikacionet të komunikojnë me këtë infrastrukturë (pa nevojën e ndryshimeve të mëdha), ato përfshijnë "portet" përkatëse në formën e subsistemeve BSP.
Nga këndvështrimi i mekanizmave të platformës, është e lehtë të vihet re se ndërsa ne marrim përvojë dhe zhvillojmë versionin cloud të "1C:Enterprise", ne zgjedhim mekanizmat që përfshihen në këtë arkitekturë. Le të japim një shembull. Në modelin multitenancy, rolet e pjesëmarrësve të shërbimit të aplikacioneve ndryshojnë ndjeshëm. Rol më të madh (nivel përgjegjësie) ka ai që përgjigjet për funksionimin e aplikacioneve. Ata tani kanë nevojë për mjete më të fuqishme për kontrollin e aplikacioneve. Sepse përdoruesit e aplikacioneve (banorët) i besojnë para së gjithash ofruesit me të cilin punojnë. Për këtë, ne realizuam në versionin 8.3 një . Ky mekanizëm lejon administratorët e ofruesve të kufizojnë lirinë e zhvilluesve të aplikacioneve me nivelin e nevojshëm të sigurisë – në thelb, të izolojnë punën e aplikacionit për çdo banor brenda kufijve të caktuar të "sandbox".
Arkitektura për menaxhimin e aplikacioneve që funksionojnë në modin multitenancy (çka realizohet në teknologjitë 1cFresh dhe BSP) është gjithashtu shumë interesante. Këtu, krahasuar me modelin e zakonshëm të implementimit, kërkesat për automatizimin e proceseve të menaxhimit rriten ndjeshëm. Ka dhjetëra nga këto procese: krijimi i hapësirave të reja të të dhënave ("apartamente"), përditësimi i aplikacioneve, përditësimi i informacionit rregullator, kopjimi i rezervës etj. Dhe, sigurisht, kërkesat për nivelin e besueshmërisë dhe disponueshmërisë rriten. Për shembull, për të siguruar një komunikim të besueshëm të aplikacioneve me komponentët e sistemit të menaxhimit, ne realizuam teknologjinë e sistemit të thirrjeve asinkrone me dorëzimin e garantuar.
Një moment shumë delikat është mënyra e shoqërimit të të dhënave dhe proceseve. Kjo duket e thjeshtë (nëse dikujt i duket) vetëm në shikim të parë. Balanca midis centralizimit të të dhënave dhe proceseve dhe decentralizimit paraqet vështirësinë më të madhe. Nga njëra anë, centralizimi lejon reduktimin e kostove (hapësirës së diskut, burimeve të procesorëve, përpjekjeve të administratorëve…). Nga ana tjetër, kufizon lirinë e "banorëve". Kjo është pikërisht një nga momentet e "ndarjes" së aplikacionit, kur zhvilluesi duhet të mendojë njëherësh për aplikacionin në kuptimin e ngushtë (për shërbimin e një "apartamenti") dhe në kuptimin e gjerë (për shërbimin e të gjithë "banorëve").
Një shembull i tillë i "dilemës" mund të merret nga informacioni rregullator dhe referues. Sigurisht, ka një tërheqje të madhe për ta bërë atë të përgjithshëm për të gjithë "banorët" e shtëpisë. Kjo lejon të ruhen në një kopje, dhe të përditësohen menjëherë për të gjithë. Por ndodh që një banor i caktuar ka nevojë për ndryshime specifike. Çuditërisht, kjo ndodh në praktikë, madje edhe për informacionin që është specifikuar nga rregullatorët (autoritetet shtetërore). Kështu del një pyetje e vështirë: a duhet të bëhet informacioni i zakonshëm apo jo? Natyrisht, është tërheqëse të bësh informacionin e përbashkët për të gjithë dhe të veçantë për ata që dëshirojnë. Dhe kjo çon në një implementim shumë të komplikuar. Por mbi këtë ne po punojmë...
Një shembull tjetër është projektimi i realizimit të proceseve të rregullta (të kryera sipas një plani, të iniciuara nga sistemi menaxhues etj.). Nga njëra anë, ato mund të realizohen për çdo hapësirë të dhënash veçmas. Kjo është më e thjeshtë dhe më e përshtatshme. Por, nga ana tjetër, granulariteti i tillë i vogël krijon një ngarkesë të madhe për sistemin. Për të zbutur ngarkesën, ne duam të realizojmë procese të përgjithshme. Por ato kërkojnë një punë më të kujdesshme.
Natyrisht, lind një pyetje shumë të rëndësishme. Si mund të sigurojnë zhvilluesit e aplikacioneve funksionimin në një mënyrë multitenance? Çfarë duhet të bëjnë për këtë? Sigurisht, ne synojmë që ngarkesa e çështjeve teknologjike dhe infrastrukturore të bjerë sa më shumë mbi teknologjinë e ofruar, ndërsa zhvilluesi i aplikacionit të mendojë vetëm për detyrat e logjikës biznesore. Por ashtu si me çështje të tjera të rëndësishme arkitekturore, zhvilluesit e aplikacioneve duhet të kenë njëfarë përvoje mbi funksionimin në modelin multitenance dhe disa përpjekje do të kërkohen gjatë zhvillimit të aplikacioneve. Pse? Sepse ekzistojnë momente, të cilat teknologjia nuk mund t'i sigurojë automatikisht pa marrë parasysh semantikën e të dhënave. Për shembull, përcaktimi i kufijve të ndarjes së informacionit. Por ne përpiqemi që këto vështirësi të jenë të vogla. Shembuj të zbatimeve të tilla aplikacionesh ekzistojnë tashmë.
Një aspekt i rëndësishëm në kontekstin e zbatimit të multitenance në «1C:Enterprise» është se ne krijojmë një model hibrid, në të cilin një aplikacion mund të funksionojë si në mënyrë multitenance, ashtu edhe në mënyrë të zakonshme. Kjo është një detyrë mjaft e komplikuar dhe është një temë për një diskutim të veçantë.
Burimi: habr.com
