Spitigernôch, dizze term hat gjin goede Russyske-taal analoge. Wikipedia jout "multy-tenancy, meardere tenancy." Dit wurdt soms "meardere eigendom" neamd. Dizze betingsten kinne wat betiizjend wêze, om't it ûnderwerp net ynherint assosjeare is mei ferhier of besit. Dit is in kwestje fan software-arsjitektuer en organisaasje fan har wurking. En dat lêste is net minder wichtich.
Wy begûn te formulearjen ús begryp fan multitenancy tagelyk as wy begûn te ûntwerpen in oanpak foar it wolk (tsjinst) model fan 1C: Enterprise wurk. Dit wie ferskate jierren lyn. En sûnt dy tiid is ús begryp hieltyd útwreide. Wy ûntdekke hieltyd mear nije aspekten fan dit ûnderwerp (foardielen, neidielen, swierrichheden, funksjes, ensfh.).
Soms begripe ûntwikkelders multitenancy as in heul ienfâldich ûnderwerp: "Om de gegevens fan ferskate organisaasjes yn ien databank te bewarjen, moatte jo in kolom mei de organisaasje-identifikaasje tafoegje oan alle tabellen en dêr in filter op ynstelle." Wy, fansels, ek begûn ús stúdzje fan de kwestje fan dit momint. Mar se realisearre gau dat dit wie mar ien clearing (ek, troch de wei, net maklik). Yn 't algemien is dit in "hiele lân".
It basisidee fan multitenancy kin soksawat wurde beskreaun. In typyske tapassing is in húske ûntworpen om ien famylje te behertigjen, dy't har ynfrastruktuer brûkt (muorren, dak, wetterfoarsjenning, ferwaarming, ensfh.). In multitenancy-applikaasje is in appartemintegebou. Dêryn brûkt elke famylje deselde ynfrastruktuer, mar de ynfrastruktuer sels wurdt útfierd foar it heule hûs.
Is de multitenancy oanpak goed of min? Jo kinne fine hiel ferskillende mieningen oer dit. D'r liket hielendal gjin "goed of min" te wêzen. Jo moatte de foar- en neidielen fergelykje yn 'e kontekst fan' e spesifike taken dy't wurde oplost. Mar dit is in apart ûnderwerp ...
Yn syn ienfâldichste sin is it doel fan multitenancy om de kosten fan it ûnderhâlden fan in applikaasje te ferminderjen troch "sosjalisearjen" ynfrastruktuerkosten. Dit is deselde beweging as it ferminderjen fan de kosten fan in applikaasje troch it brûken fan in produksje-oplossing (mooglik mei oanpassing en modifikaasje), ynstee fan it skriuwen "op bestelling." Allinnich yn ien gefal wurdt ûntwikkeling sosjalisearre, en yn it oare - eksploitaasje.
Boppedat, wy werhelje, der is gjin direkte keppeling nei de metoade fan ferkeap. Multitenancy-arsjitektuer kin ek brûkt wurde yn in bedriuws- as ôfdielings IT-ynfrastruktuer om in grut oantal ferlykbere tûken en bedriuwen te automatisearjen.
Wy kinne sizze dat multitenancy net allinich in kwestje is fan it organisearjen fan gegevensopslach. Dit is in model fan hoe't de applikaasje as gehiel wurket (ynklusyf in wichtich part fan 'e aspekten fan syn arsjitektuer, en it ynsetmodel, en de organisaasje fan ûnderhâld).
It dreechste en nijsgjirrigste fan it multitenancy-model, liket ús, is dat de essinsje fan 'e applikaasje "ferdield is." In part fan de funksjonaliteit wurket mei spesifike gegevens gebieten (apparteminten) en is "net ynteressearre" yn it feit dat der bewenners yn oare apparteminten. En guon sjogge it hûs as in gehiel en wurkje tagelyk foar alle ynwenners. Tagelyk kin de lêste it feit net negearje dat dit ommers aparte apparteminten binne, en it is needsaaklik om it needsaaklike nivo fan granulariteit en feiligens te garandearjen.
Yn 1C: Enterprise wurdt it multitenancy-model ymplementearre op it nivo fan ferskate technologyen. Dit binne de meganismen fan it 1C: Enterprise platfoarm, de meganismen fan"En"", meganismen (biblioteken fan standert subsystemen).
Elk fan dizze items draacht by oan de bou fan 'e totale ynfrastruktuer fan in appartemintegebou. Wêrom wurdt dit ymplementearre yn ferskate technologyen, en net yn ien, bygelyks yn in platfoarm? Earst fan alles, om't guon fan 'e meganismen, nei ús miening, hiel passend binne om te wizigjen foar in spesifike ynsetopsje. Mar yn 't algemien is dit in drege fraach, en wy wurde hieltyd konfrontearre mei in kar - op hokker nivo is it better om dit of dat aspekt fan multitenancy út te fieren.
Fansels moast it basisdiel fan 'e meganismen wurde ymplementearre yn it platfoarm. No, bygelyks, de eigentlike gegevensskieding. Dit is wêr't minsken gewoanlik begjinne te praten oer multitenancy. Mar op it lêst "reizge" it multitenancy-model troch in wichtich part fan 'e meganismen fan it platfoarm en easke har ferfining, en yn guon gefallen, opnij tinke.
Op it platfoarmnivo hawwe wy krekt de basismeganismen ymplementearre. Se kinne jo applikaasjes meitsje dy't rinne yn in multitenancy-model. Mar om applikaasjes te "libje en wurkje" yn sa'n model, moatte jo in systeem hawwe foar it behearen fan har "libbensaktiviteiten". 1cFresh technologyen en in unifoarme bedriuwslogyske laach op it BSP-nivo binne dêr ferantwurdlik foar. Krekt as yn in appartemintegebou de ynfrastruktuer ynwenners alles leveret wat se nedich binne, sa leverje 1cFresh-technologyen alles wat se nedich binne foar applikaasjes dy't rinne yn in multitenancy-model. En sadat applikaasjes kinne ynteraksje mei dizze ynfrastruktuer (sûnder signifikante oanpassingen), wurde de oerienkommende "ferbiningen" yn har pleatst yn 'e foarm fan BSP-subsystemen.
Fanút it eachpunt fan 'e platfoarmmeganismen is it maklik te merken dat as wy ûnderfining krije en de wolk gebrûksgefal "1C: Enterprise" ûntwikkelje, wreidzje wy de gearstalling fan 'e meganismen út dy't belutsen binne by dizze arsjitektuer. Litte wy ien foarbyld jaan. Yn it multitenancy-model feroarje de rollen fan dielnimmers oan applikaasjestsjinsten signifikant. De rol (ferantwurdlikensnivo) fan dyjingen dy't ferantwurdlik binne foar it operearjen fan applikaasjes nimt signifikant ta. It waard foar harren nedich om machtiger ark foar applikaasjekontrôle te hawwen. Om't brûkers fan applikaasjes (ynwenners) foarearst de provider fertrouwe wêrmei't se wurkje. Om dit te dwaan, hawwe wy in nij ynfierd . Dit meganisme lit providerbehearders de frijheid fan applikaasjeûntwikkelders beheine ta it fereaske nivo fan feiligens - yn essinsje om de wurking fan 'e applikaasje foar elke hierder binnen in bepaalde sânbak te isolearjen.
Net minder nijsgjirrich is de arsjitektuer foar it behearen fan applikaasjes dy't wurkje yn multitenancy-modus (wat wurdt ymplementearre yn 1cFresh- en BSP-technologyen). Hjir, yn ferliking mei it konvinsjonele ynsetmodel, wurde de easken foar automatisearring fan behearprosessen signifikant ferhege. D'r binne tsientallen sokke prosessen: it meitsjen fan nije gegevensgebieten ("apparteminten"), aktualisearjen fan applikaasjes, aktualisearjen fan regeljouwingynformaasje, backups, ensfh. En fansels wurde de easken foar it nivo fan betrouberens en beskikberens tanimmend. Bygelyks, om betroubere ynteraksje tusken applikaasjes en komponinten fan kontrôlesysteem te garandearjen, hawwe wy asynchrone opropsysteemtechnology ymplementearre mei garandearre levering.
In heul subtyl punt is de manier fan sosjalisearjen fan gegevens en prosessen. It liket ienfâldich (as it ien liket) allinich op it earste each. De grutste útdaging is it lykwicht tusken sintralisaasje fan gegevens en prosessen en desintralisaasje. Oan 'e iene kant lit sintralisaasje jo kosten ferminderje (skiifromte, prosessorboarnen, administrator ynspannings ...). Oan 'e oare kant beheint it de frijheid fan 'e "hierders". Dit is krekt ien fan 'e mominten fan "bifurcation" fan 'e applikaasje, as de ûntwikkelder tagelyk moat tinke oer de applikaasje yn' e smelle sin (betsjinje ien "appartement") en yn 'e brede sin (betsjinje alle "hierders" tagelyk) .
As foarbyld fan sa'n "dilemma" kin men regeljouwing en referinsjeynformaasje neame. Fansels is d'r in grutte ferlieding om it mienskiplik te meitsjen foar alle "hierders" fan it hûs. Hjirmei kinne jo it yn ien kopy opslaan en it tagelyk foar elkenien bywurkje. Mar it komt foar dat guon ynwenners spesifike feroarings nedich hawwe. Frjemd genôch komt dit yn 'e praktyk foar, sels foar ynformaasje dy't bepaald wurdt troch tafersjochhâlders (oerheidsorganen). Dit blykt in drege fraach te wêzen: sosjalisearje of net sosjalisearje? It is fansels ferleidend om algemiene ynformaasje foar elkenien te meitsjen en privee foar dyjingen dy't it wolle. En dit liedt al ta in tige drege útfiering. Mar wy wurkje hjir oan ...
In oar foarbyld is it ûntwerp fan 'e ymplemintaasje fan reguliere prosessen (útfierd op in skema, inisjearre troch it kontrôlesysteem, ensfh.). Oan 'e iene kant kinne se foar elk gegevensgebiet apart ymplementearre wurde. It is makliker en handiger. Mar, oan 'e oare kant, soarget sa'n fyn granulariteit in grutte lading op it systeem. Om de lading te ferminderjen, moatte jo sosjalisearre prosessen ymplementearje. Mar se fereaskje mear soarchfâldige stúdzje.
Fansels ropt dit in heul wichtige fraach op. Hoe kinne applikaasje-ûntwikkelders multitenancy garandearje? Wat moatte se dêrfoar dwaan? Fansels stribje wy om te soargjen dat de lêst fan technologyske en ynfrastruktuerproblemen safolle mooglik falt op 'e skouders fan' e levere technology, en de applikaasjeûntwikkelder tinkt allinich yn termen fan saaklike logikataken. Mar lykas by oare wichtige arsjitektoanyske problemen, moatte applikaasje-ûntwikkelders wat begryp hawwe fan wurkjen yn it multitenancy-model en wat ynspanning sil nedich wêze by it ûntwikkeljen fan applikaasjes. Wêrom? Om't d'r punten binne dy't technology net automatysk kin leverje sûnder rekken te hâlden mei de semantyk fan 'e gegevens. Bygelyks, deselde definysje fan 'e grinzen fan ynformaasje sosjalisaasje. Mar wy besykje dizze swierrichheden lyts te hâlden. Der binne al foarbylden fan ymplemintaasje fan sokke applikaasjes.
In wichtich punt yn 'e kontekst fan it útfieren fan multitenancy yn 1C: Enterprise is dat wy in hybride model meitsje wêryn ien applikaasje kin operearje yn sawol multitenancy-modus as normale modus. Dit is in tige drege taak en it ûnderwerp fan in aparte diskusje.
Boarne: www.habr.com
