Bohužiaľ, tento výraz nemá dobrý analóg v ruskom jazyku. Wikipedia dáva "viacnásobný nájom, viacnásobný nájom." Toto sa niekedy nazýva „viacnásobné vlastníctvo“. Tieto výrazy môžu byť trochu mätúce, pretože predmet nie je vo svojej podstate spojený ani s prenájmom, ani s vlastníctvom. To je otázka architektúry softvéru a organizácie jeho fungovania. A to posledné je nemenej dôležité.
Naše chápanie multiprenájmu sme začali formulovať v rovnakom čase, ako sme začali navrhovať prístup ku cloudovému (službovému) modelu práce v 1C:Enterprise. Bolo to pred niekoľkými rokmi. A odvtedy sa naše chápanie neustále rozširuje. Neustále objavujeme stále nové a nové aspekty tejto témy (klady, zápory, ťažkosti, vlastnosti atď.).
Vývojári niekedy chápu multinájomstvo ako veľmi jednoduchú tému: „aby sa údaje niekoľkých organizácií uložili do jednej databázy, musíte do všetkých tabuliek pridať stĺpec s identifikátorom organizácie a nastaviť naň filter.“ Od tohto momentu sme, samozrejme, začali aj so štúdiom problematiky. Rýchlo si však uvedomili, že je to len jedna čistinka (mimochodom tiež nie ľahká). Vo všeobecnosti ide o „celú krajinu“.
Základná myšlienka multitenancie sa dá opísať asi takto. Typickou aplikáciou je chata určená na ubytovanie jednej rodiny, ktorá využíva svoju infraštruktúru (steny, strecha, vodovod, kúrenie a pod.). Aplikácia spoločného nájmu je bytový dom. V ňom každá rodina využíva rovnakú infraštruktúru, no samotná infraštruktúra je realizovaná pre celý dom.
Je viacnájomný prístup dobrý alebo zlý? Dá sa na to nájsť veľmi rozdielne názory. Zdá sa, že neexistuje vôbec žiadne „dobré alebo zlé“. Treba si porovnať klady a zápory v kontexte konkrétnych riešených úloh. Ale toto je samostatná téma...
V najjednoduchšom zmysle je cieľom multiprenájmu znížiť náklady na údržbu aplikácie „socializáciou“ nákladov na infraštruktúru. Je to rovnaký pohyb ako znižovanie nákladov na aplikáciu pomocou produkčného riešenia (prípadne s prispôsobením a modifikáciou), a nie písaním „na objednávku“. Iba v jednom prípade je rozvoj socializovaný av druhom prípade vykorisťovanie.
Navyše, opakujeme, neexistuje žiadna priama súvislosť so spôsobom predaja. Multitenancy architektúru možno použiť aj v podnikovej alebo oddelenej IT infraštruktúre na automatizáciu veľkého počtu podobných pobočiek a holdingových podnikov.
Môžeme povedať, že multitenancy nie je len záležitosťou organizácie ukladania dát. Toto je model fungovania aplikácie ako celku (vrátane významnej časti jej architektúry, modelu nasadenia a organizácie údržby).
Zdá sa nám, že najťažšia a najzaujímavejšia vec na modeli viacerých nájmov je, že podstata aplikácie sa „rozdvojuje“. Časť funkcionality pracuje s konkrétnymi dátovými oblasťami (bytmi) a „nezaujíma“ sa o to, že v iných bytoch sú obyvatelia. A niektorí vnímajú dom ako celok a fungujú pre všetkých obyvateľov naraz. Tá zároveň nemôže ignorovať skutočnosť, že ide predsa o samostatné byty a je potrebné zabezpečiť potrebnú úroveň granularity a bezpečnosti.
V 1C:Enterprise je multitenancy model implementovaný na úrovni niekoľkých technológií. Toto sú mechanizmy platformy 1C:Enterprise, mechanizmy o"A"“, mechanizmy (knižnice štandardných podsystémov).
Každá z týchto položiek prispieva k vybudovaniu celkovej infraštruktúry bytového domu. Prečo je to implementované vo viacerých technológiách a nie v jednej, napríklad v platforme? V prvom rade preto, že niektoré mechanizmy je podľa nášho názoru celkom vhodné upraviť pre konkrétnu možnosť nasadenia. Ale vo všeobecnosti je to ťažká otázka a neustále stojíme pred voľbou - na akej úrovni je lepšie implementovať ten alebo ten aspekt multiprenájmu.
Je zrejmé, že základnú časť mechanizmov bolo potrebné implementovať do platformy. No napríklad samotné oddelenie dát. Tu ľudia zvyčajne začínajú hovoriť o multiprenájme. Nakoniec však multinájomný model „precestoval“ významnú časť mechanizmov platformy a vyžadoval si ich zdokonalenie a v niektorých prípadoch aj prehodnotenie.
Na úrovni platformy sme implementovali presne tie základné mechanizmy. Umožňujú vám vytvárať aplikácie, ktoré bežia v modeli viacerých nájomcov. Aby však aplikácie „žili a fungovali“ v takomto modeli, musíte mať systém na riadenie ich „životných aktivít“. Sú za to zodpovedné technológie 1cFresh a jednotná vrstva obchodnej logiky na úrovni BSP. Tak ako v bytovom dome infraštruktúra poskytuje obyvateľom všetko, čo potrebujú, tak technológie 1cFresh poskytujú všetko, čo potrebujú pre aplikácie bežiace v multiprenájomovom modeli. A aby aplikácie mohli interagovať s touto infraštruktúrou (bez výrazných úprav), sú v nich umiestnené zodpovedajúce „konektory“ vo forme subsystémov BSP.
Z hľadiska mechanizmov platformy je ľahké si všimnúť, že ako získavame skúsenosti a vyvíjame cloudový prípad použitia „1C:Enterprise“, rozširujeme zloženie mechanizmov, ktoré sú zahrnuté v tejto architektúre. Uveďme jeden príklad. V multitenancy modeli sa výrazne menia roly účastníkov aplikačných služieb. Významne sa zvyšuje úloha (úroveň zodpovednosti) zodpovedných za prevádzkovanie aplikácií. Bolo pre nich nevyhnutné mať výkonnejšie nástroje na ovládanie aplikácií. Pretože používatelia aplikácie (rezidenti) dôverujú predovšetkým poskytovateľovi, s ktorým spolupracujú. Za týmto účelom sme implementovali nový . Tento mechanizmus umožňuje správcom poskytovateľov obmedziť slobodu vývojárov aplikácií na požadovanú úroveň zabezpečenia – v podstate izolovať prevádzku aplikácie pre každého nájomcu v rámci určitého sandboxu.
Nemenej zaujímavá je architektúra pre správu aplikácií fungujúcich v multitenancy režime (tá je implementovaná v technológiách 1cFresh a BSP). Tu sa oproti klasickému modelu nasadenia výrazne zvyšujú požiadavky na automatizáciu procesov riadenia. Týchto procesov sú desiatky: vytváranie nových dátových oblastí („apartmánov“), aktualizácia aplikácií, aktualizácia regulačných informácií, zálohovanie atď. A samozrejme sa zvyšujú požiadavky na úroveň spoľahlivosti a dostupnosti. Napríklad na zabezpečenie spoľahlivej interakcie medzi aplikáciami a komponentmi riadiaceho systému sme implementovali technológiu asynchrónneho volacieho systému s garantovaným doručením.
Veľmi jemným bodom je spôsob socializácie dát a procesov. Zdá sa to jednoduché (ak sa to niekomu zdá) len na prvý pohľad. Najväčšou výzvou je rovnováha medzi centralizáciou údajov a procesov a decentralizáciou. Na jednej strane centralizácia umožňuje znížiť náklady (miesto na disku, zdroje procesora, úsilie správcu...). Na druhej strane obmedzuje slobodu „nájomníkov“. Toto je presne jeden z momentov „rozdvojenia“ aplikácie, keď vývojár potrebuje myslieť súčasne na aplikáciu v užšom zmysle (obsluha jedného „bytu“) aj v širšom zmysle (obsluha všetkých „nájomníkov“ naraz) .
Ako príklad takejto „dilemy“ možno uviesť regulačné a referenčné informácie. Samozrejme, existuje veľké pokušenie, aby to bolo spoločné pre všetkých „nájomníkov“ domu. To vám umožní uložiť ho v jednej kópii a aktualizovať ho pre všetkých naraz. Stáva sa ale, že niektorí obyvatelia potrebujú konkrétne zmeny. Napodiv, v praxi k tomu dochádza aj pri informáciách, ktoré špecifikujú regulačné orgány (vládne orgány). To sa ukazuje ako ťažká otázka: socializovať sa alebo nesocializovať? Je samozrejme lákavé urobiť informácie všeobecné pre každého a súkromné pre tých, ktorí ich chcú. A to už vedie k veľmi ťažkej realizácii. Ale pracujeme na tom...
Ďalším príkladom je návrh implementácie pravidelných procesov (realizovaných podľa plánu, iniciovaných riadiacim systémom a pod.). Na jednej strane môžu byť implementované pre každú dátovú oblasť samostatne. Je to jednoduchšie a pohodlnejšie. Ale na druhej strane takáto jemná zrnitosť vytvára veľké zaťaženie systému. Ak chcete znížiť zaťaženie, musíte implementovať socializované procesy. Vyžadujú si však dôkladnejšie štúdium.
Samozrejme, toto vyvoláva veľmi závažnú otázku. Ako môžu vývojári aplikácií zabezpečiť multitenancy? Čo pre to musia urobiť? Samozrejme, snažíme sa o to, aby bremeno technologických a infraštruktúrnych záležitostí padlo čo najviac na plecia dodávanej technológie a vývojár aplikácie myslel len na úlohy obchodnej logiky. Ale ako pri iných dôležitých architektonických problémoch, vývojári aplikácií musia mať určité pochopenie pre prácu v modeli viacerých nájomníkov a pri vývoji aplikácií bude potrebné určité úsilie. prečo? Pretože existujú body, ktoré technológia nemôže poskytnúť automaticky bez zohľadnenia sémantiky údajov. Napríklad rovnaké vymedzenie hraníc informačnej socializácie. Ale snažíme sa, aby tieto ťažkosti boli čo najmenšie. Príklady implementácie takýchto aplikácií už existujú.
Dôležitým bodom v kontexte implementácie multiprenájmu v 1C:Enterprise je, že vytvárame hybridný model, v ktorom môže jedna aplikácia fungovať v režime multiprenájmu aj v normálnom režime. Je to veľmi náročná úloha a je predmetom samostatnej diskusie.
Zdroj: hab.com