Bohužel tento termín nemá dobrý ruskojazyčný analog. Wikipedie dává "multi-nájem, vícenásobný nájem." Někdy se tomu říká „vícenásobné vlastnictví“. Tyto termíny mohou být poněkud matoucí, protože předmět není neodmyslitelně spojen ani s pronájmem, ani s vlastnictvím. To je otázka softwarové architektury a organizace jeho provozu. A to poslední je neméně důležité.
Naše chápání multitenancy jsme začali formulovat ve stejnou dobu, kdy jsme začali navrhovat přístup ke cloudovému (servisnímu) modelu práce v 1C:Enterprise. To bylo před několika lety. A od té doby se naše porozumění neustále rozšiřuje. Neustále objevujeme stále nové a nové aspekty tohoto předmětu (klady, zápory, potíže, vlastnosti atd.).
Někdy vývojáři chápou multitenancy jako velmi jednoduchý předmět: „aby byla data několika organizací uložena v jedné databázi, musíte do všech tabulek přidat sloupec s identifikátorem organizace a nastavit na něj filtr.“ Od tohoto okamžiku jsme samozřejmě také začali se studiem této problematiky. Rychle si ale uvědomili, že je to jen jedna paseka (mimochodem také ne snadná). Obecně se jedná o „celou zemi“.
Základní myšlenku multitenance lze popsat asi takto. Typickou aplikací je chata určená pro ubytování jedné rodiny, která využívá její infrastrukturu (zdi, střecha, vodovod, topení atd.). Multinájemní aplikací je bytový dům. V něm každá rodina využívá stejnou infrastrukturu, ale infrastruktura samotná je implementována pro celý dům.
Je multinájemní přístup dobrý nebo špatný? Na to se můžete setkat s velmi odlišnými názory. Zdá se, že neexistuje vůbec žádné „dobré nebo špatné“. Je potřeba porovnat klady a zápory v kontextu konkrétních řešených úkolů. Ale to je samostatné téma...
Ve svém nejjednodušším smyslu je cílem multitenancy snížit náklady na údržbu aplikace „socializací“ nákladů na infrastrukturu. Je to stejný pohyb jako snížení nákladů na aplikaci pomocí produkčního řešení (případně s přizpůsobením a úpravami), spíše než psaní „na objednávku“. Pouze v jednom případě je rozvoj socializovaný a ve druhém - vykořisťování.
Navíc, opakujeme, neexistuje žádná přímá vazba na způsob prodeje. Architektura multitenancy může být také použita v podnikové nebo oddělení IT infrastruktury k automatizaci velkého počtu podobných poboček a holdingových společností.
Můžeme říci, že multitenancy není jen záležitostí organizace ukládání dat. Toto je model toho, jak aplikace funguje jako celek (včetně významné části její architektury, modelu nasazení a organizace údržby).
Zdá se nám, že nejobtížnější a nejzajímavější na modelu multinájmu je to, že podstata aplikace se „rozdvojuje“. Část funkcionality pracuje s konkrétními datovými oblastmi (byty) a „nezajímá“ se o to, že v jiných bytech jsou obyvatelé. A někteří vnímají dům jako celek a fungují pro všechny obyvatele najednou. Ten přitom nemůže pominout, že jde přeci o samostatné byty a je potřeba zajistit potřebnou úroveň členitosti a bezpečnosti.
V 1C:Enterprise je multitenancy model implementován na úrovni několika technologií. Toto jsou mechanismy platformy 1C:Enterprise, mechanismy"A"“, mechanismy (knihovny standardních subsystémů).
Každá z těchto položek přispívá k vybudování celkové infrastruktury bytového domu. Proč je to implementováno v několika technologiích a ne v jedné, například v platformě? Za prvé proto, že některé mechanismy je podle našeho názoru docela vhodné upravit pro konkrétní možnost nasazení. Ale obecně je to těžká otázka a neustále stojíme před volbou - na jaké úrovni je lepší implementovat ten či onen aspekt multitenancy.
Je zřejmé, že základní část mechanismů bylo potřeba implementovat do platformy. No, například skutečné oddělení dat. Zde se obvykle začíná mluvit o vícenájmu. Nakonec však multinájemní model „procestoval“ významnou část mechanismů platformy a vyžadoval jejich zdokonalení a v některých případech i přehodnocení.
Na úrovni platformy jsme implementovali přesně základní mechanismy. Umožňují vám vytvářet aplikace, které běží v multitenancy modelu. Ale aby aplikace v takovém modelu „žily a fungovaly“, musíte mít systém pro řízení jejich „životních aktivit“. Mohou za to technologie 1cFresh a jednotná vrstva business logiky na úrovni BSP. Stejně jako v bytovém domě poskytuje infrastruktura obyvatelům vše, co potřebují, tak technologie 1cFresh poskytují vše, co potřebují pro aplikace běžící v multitenancy modelu. A aby aplikace mohly interagovat s touto infrastrukturou (bez výrazných úprav), jsou do nich umístěny odpovídající „konektory“ v podobě subsystémů BSP.
Z hlediska mechanismů platformy je snadné si všimnout, že jak získáváme zkušenosti a vyvíjíme cloudový případ použití „1C:Enterprise“, rozšiřujeme složení mechanismů, které jsou součástí této architektury. Uveďme jeden příklad. V modelu multitenancy se role účastníků aplikačních služeb výrazně mění. Významně se zvyšuje role (úroveň odpovědnosti) odpovědných za provoz aplikací. Bylo pro ně nutné mít výkonnější nástroje pro řízení aplikací. Protože uživatelé (rezidenti) aplikací důvěřují především poskytovateli, se kterým spolupracují. Za tímto účelem jsme implementovali nový . Tento mechanismus umožňuje správcům poskytovatelů omezit svobodu vývojářů aplikací na požadovanou úroveň zabezpečení – v podstatě izolovat provoz aplikace pro každého nájemce v rámci určitého sandboxu.
Neméně zajímavá je architektura pro správu aplikací pracujících v multitenancy režimu (co je implementováno v technologiích 1cFresh a BSP). Zde se oproti klasickému modelu nasazení výrazně zvyšují požadavky na automatizaci procesů řízení. Těchto procesů jsou desítky: vytváření nových datových oblastí („bytů“), aktualizace aplikací, aktualizace regulačních informací, zálohování atd. A samozřejmě se zvyšují požadavky na úroveň spolehlivosti a dostupnosti. Abychom například zajistili spolehlivou interakci mezi aplikacemi a komponentami řídicího systému, implementovali jsme technologii asynchronního volacího systému s garantovaným doručením.
Velmi jemným bodem je způsob socializace dat a procesů. Zdá se to jednoduché (pokud se to někomu zdá) jen na první pohled. Největší výzvou je rovnováha mezi centralizací dat a procesů a decentralizací. Centralizace umožňuje na jedné straně snížit náklady (místo na disku, zdroje procesoru, úsilí administrátorů...). Na druhou stranu omezuje svobodu „nájemníků“. To je přesně jeden z momentů „rozdvojení“ aplikace, kdy vývojář potřebuje myslet současně na aplikaci v užším slova smyslu (obsluhující jeden „byt“) i v širším smyslu (obsluhující všechny „nájemníky“ najednou) .
Jako příklad takového „dilematu“ lze uvést regulační a referenční informace. Samozřejmě existuje velké pokušení, aby to bylo společné pro všechny „nájemníky“ domu. To vám umožní uložit ji v jedné kopii a aktualizovat ji pro všechny najednou. Stává se ale, že někteří obyvatelé potřebují konkrétní změny. Kupodivu k tomu v praxi dochází i u informací, které jsou specifikovány regulátory (vládními orgány). To se ukazuje jako těžká otázka: socializovat se, nebo nesocializovat? Je samozřejmě lákavé učinit informace obecné pro všechny a soukromé pro toho, kdo je chce. A to již vede k velmi obtížné implementaci. Ale pracujeme na tom...
Dalším příkladem je návrh implementace pravidelných procesů (prováděných podle plánu, iniciovaných řídicím systémem atd.). Jednak je lze implementovat pro každou datovou oblast zvlášť. Je to jednodušší a pohodlnější. Ale na druhou stranu taková jemná granularita vytváří velké zatížení systému. Chcete-li snížit zátěž, musíte implementovat socializované procesy. Ale vyžadují pečlivější studium.
To samozřejmě vyvolává velmi závažnou otázku. Jak mohou vývojáři aplikací zajistit multitenancy? Co pro to musí udělat? Snažíme se samozřejmě o to, aby tíha technologických a infrastrukturních záležitostí dopadla co nejvíce na bedra dodávané technologie a vývojář aplikací myslel pouze na úkoly obchodní logiky. Ale stejně jako u jiných důležitých architektonických problémů, vývojáři aplikací musí mít určité znalosti o práci v modelu multitenancy a při vývoji aplikací bude zapotřebí určité úsilí. Proč? Protože existují body, které technologie nemohou poskytnout automaticky bez zohlednění sémantiky dat. Například stejné vymezení hranic informační socializace. Ale snažíme se, aby tyto obtíže byly co nejmenší. Příklady implementace takových aplikací již existují.
Důležitým bodem v kontextu implementace multitenancy v 1C:Enterprise je to, že vytváříme hybridní model, ve kterém může jedna aplikace fungovat jak v režimu multitenancy, tak v normálním režimu. To je velmi obtížný úkol a je předmětem samostatné diskuse.
Zdroj: www.habr.com