Sajnos ennek a kifejezésnek nincs jó orosz nyelvű analógja. A Wikipédia ad "többbérlet, többszörös bérlés." Ezt néha "többszörös tulajdonjognak" nevezik. Ezek a kifejezések kissé zavaróak lehetnek, mivel a tárgy nem kapcsolódik eredendően sem a bérléshez, sem a tulajdonjoghoz. Ez szoftverarchitektúra és működésének megszervezése kérdése. És ez utóbbi nem kevésbé fontos.
Egyszerre kezdtük megfogalmazni a többbérléssel kapcsolatos értelmezésünket, amikor elkezdtük a felhő (szolgáltatás) munkamodell megközelítését az 1C:Enterprise-ben. Ez néhány éve volt. És azóta a megértésünk folyamatosan bővült. Folyamatosan újabb és újabb aspektusokat fedezünk fel ebben a témában (előnyök, hátrányok, nehézségek, jellemzők stb.).
A fejlesztők néha nagyon egyszerű tárgyként értelmezik a több bérleményt: „Ahhoz, hogy több szervezet adatait egy adatbázisban tároljuk, minden táblához hozzá kell adni egy oszlopot a szervezet azonosítójával, és be kell állítani rajta egy szűrőt.” Természetesen mi is ettől a pillanattól kezdtük el a kérdés tanulmányozását. De hamar rájöttek, hogy ez csak egy tisztás (egyébként szintén nem könnyű). Általában véve ez egy „egész ország”.
A multitenancy alapötlete valahogy így írható le. Tipikus alkalmazás egy család elhelyezésére tervezett házikó, amely az infrastruktúráját (falak, tető, vízellátás, fűtés stb.) használja. A többbérletes alkalmazás egy bérház. Ebben minden család ugyanazt az infrastruktúrát használja, de maga az infrastruktúra az egész házra van megvalósítva.
A többbérletes megközelítés jó vagy rossz? Erről nagyon eltérő véleményeket lehet találni. Úgy tűnik, hogy egyáltalán nincs „jó vagy rossz”. Össze kell hasonlítania az előnyöket és hátrányokat a konkrét megoldandó feladatok összefüggésében. De ez egy külön téma...
A legegyszerűbb értelmében a többbérlet célja az alkalmazás fenntartási költségeinek csökkentése az infrastrukturális költségek „szocializálásával”. Ez ugyanaz, mint az alkalmazás költségeinek csökkentése egy éles megoldás használatával (esetleg testreszabással és módosítással), ahelyett, hogy „rendelésre” írnák. Csak az egyik esetben a fejlesztés szocializálódik, a másikban pedig a kizsákmányolás.
Sőt, ismételjük, nincs közvetlen kapcsolat az értékesítés módjával. A többbérlős architektúra vállalati vagy részleg IT-infrastruktúrában is használható nagyszámú hasonló fióktelep és holdingvállalat automatizálására.
Kijelenthetjük, hogy a multibérlés nem csupán az adattárolás megszervezésének kérdése. Ez egy modell az alkalmazás egészének működésére (beleértve az architektúra jelentős részét, a telepítési modellt és a karbantartási szervezetet).
Számunkra az a legnehezebb és legérdekesebb a többbérleti modellben, hogy az alkalmazás lényege „elágazik”. A funkcionalitás egy része meghatározott adatterületekkel (lakásokkal) működik, és „nem érdekli”, hogy más lakásokban is vannak lakók. És néhányan a házat egészként érzékelik, és egyszerre dolgoznak az összes lakosnak. Utóbbiak ugyanakkor nem hagyhatják figyelmen kívül azt a tényt, hogy ezek végül is különálló lakások, és biztosítani kell a szükséges részletességi és biztonsági szintet.
Az 1C:Enterprise-ben a többbérleti modellt számos technológia szintjén valósítják meg. Ezek az 1C:Enterprise platform mechanizmusai, a mechanizmusok"És"", mechanizmusok (szabványos alrendszerek könyvtárai).
Ezen elemek mindegyike hozzájárul egy bérház teljes infrastruktúrájának kiépítéséhez. Miért valósítják meg ezt több technológiában, és miért nem egyben, például egy platformon? Mindenekelőtt azért, mert véleményünk szerint a mechanizmusok egy része igencsak megfelelő egy adott telepítési lehetőséghez. De általában ez egy nehéz kérdés, és folyamatosan választás előtt állunk - milyen szinten jobb megvalósítani a többbérleti szerződés egyik vagy másik aspektusát.
Nyilvánvalóan a mechanizmusok alapvető részét kellett implementálni a platformon. Nos, például a tényleges adatleválasztás. Általában itt kezdenek beszélni a többbérletről. De végül a többbérleti modell „beutazta” a platform mechanizmusainak jelentős részét, és ezek finomítását, egyes esetekben újragondolását igényelte.
Platform szinten pontosan az alapvető mechanizmusokat valósítottuk meg. Lehetővé teszik olyan alkalmazások létrehozását, amelyek több bérlési modellben futnak. De ahhoz, hogy az alkalmazások „éljenek és működjenek” egy ilyen modellben, rendelkeznie kell egy rendszerrel az „élettevékenységeik” kezelésére. Az 1cFresh technológiák és a BSP szinten egységes üzleti logikai réteg felelős ezért. Ahogy egy társasházban az infrastruktúra mindennel ellátja a lakókat, amire szükségük van, úgy az 1cFresh technológiák is mindent biztosítanak, ami a többbérletes modellben futó alkalmazásokhoz szükséges. És hogy az alkalmazások kölcsönhatásba léphessenek ezzel az infrastruktúrával (jelentős módosítások nélkül), a megfelelő „csatlakozók” BSP alrendszerek formájában kerülnek bennük.
A platformmechanizmusok szempontjából könnyen észrevehető, hogy a tapasztalatszerzéssel és az „1C:Enterprise” felhőhasználati eset fejlesztésével bővítjük az ebben az architektúrában szereplő mechanizmusok összetételét. Mondjunk egy példát. A többbérletes modellben az alkalmazásszolgáltatásban résztvevők szerepei jelentősen megváltoznak. Jelentősen megnő az alkalmazások üzemeltetéséért felelősök szerepe (felelősségi szintje). Szükségessé vált, hogy erősebb alkalmazásvezérlő eszközökkel rendelkezzenek. Mert az alkalmazás felhasználói (rezidensei) elsősorban abban a szolgáltatóban bíznak, amellyel dolgoznak. Ennek érdekében újat vezettünk be . Ez a mechanizmus lehetővé teszi a szolgáltatói rendszergazdák számára, hogy a szükséges biztonsági szintre korlátozzák az alkalmazásfejlesztők szabadságát – lényegében az alkalmazás működését minden bérlő számára egy bizonyos sandboxon belül elkülönítsék.
Nem kevésbé érdekes a többbérletes módban működő alkalmazások kezelésének architektúrája (amit az 1cFresh és a BSP technológiák implementálnak). Itt a hagyományos telepítési modellhez képest jelentősen megnövekednek az irányítási folyamatok automatizálásának követelményei. Több tucat ilyen folyamat létezik: új adatterületek („lakások”) létrehozása, alkalmazások frissítése, hatósági információk frissítése, biztonsági mentések stb. És természetesen a megbízhatósági és rendelkezésre állási követelmények is növekszenek. Például az alkalmazások és a vezérlőrendszer összetevői közötti megbízható interakció biztosítása érdekében aszinkron hívásrendszer-technológiát vezettünk be garantált kézbesítéssel.
Egy nagyon finom pont az adatok és folyamatok szocializálásának módja. Csak első pillantásra tűnik egyszerűnek (ha valakinek úgy tűnik). A legnagyobb kihívást az adatok és folyamatok centralizálása és a decentralizáció közötti egyensúly jelenti. A központosítás egyrészt lehetővé teszi a költségek csökkentését (lemezterület, processzor erőforrások, rendszergazdai erőfeszítések...). Másrészt korlátozza a „bérlők” szabadságát. Pontosan ez az alkalmazás „elágazásának” egyik pillanata, amikor a fejlesztőnek egyszerre kell gondolkodnia a szűk értelemben vett alkalmazásról (egy „lakás kiszolgálása”) és tág értelemben (az összes „bérlőt” egyszerre kiszolgálva) .
Egy ilyen „dilemma” példájaként a szabályozási és referenciainformációkat említhetjük. Természetesen nagy a kísértés, hogy a ház minden „bérlője” számára közös legyen. Ez lehetővé teszi, hogy egy példányban tárolja, és mindenki számára egyszerre frissítse. De előfordul, hogy egyes lakosoknak konkrét változtatásokra van szükségük. Furcsa módon ez a gyakorlatban előfordul, még a szabályozók (kormányzati szervek) által meghatározott információk esetében is. Ez nehéz kérdésnek bizonyul: szocializálódni vagy nem szocializálódni? Természetesen csábító, hogy az információkat mindenki számára általánossá, és priváttá tegyük azok számára, akik szeretnék. Ez pedig már nagyon nehéz megvalósításhoz vezet. De ezen dolgozunk...
Egy másik példa a szabályos folyamatok megvalósításának megtervezése (ütemezett, vezérlőrendszer által kezdeményezett stb.). Egyrészt minden adatterületre külön-külön is megvalósíthatók. Egyszerűbb és kényelmesebb. Másrészt azonban az ilyen finom részletesség nagy terhelést jelent a rendszeren. A terhelés csökkentése érdekében szocializált folyamatokat kell megvalósítani. De alaposabb tanulmányozást igényelnek.
Természetesen ez egy nagyon lényeges kérdést vet fel. Hogyan biztosíthatják az alkalmazásfejlesztők a több bérleményt? Mit kell ehhez tenniük? Természetesen törekszünk arra, hogy a technológiai és infrastrukturális kérdések terhe a lehető legnagyobb mértékben a szállított technológia vállára háruljon, és az alkalmazásfejlesztő csak üzleti logikai feladatokban gondolkodjon. Más fontos építészeti problémákhoz hasonlóan azonban az alkalmazásfejlesztőknek is meg kell érteniük a többbérletes modellben való munkát, és némi erőfeszítésre lesz szükség az alkalmazások fejlesztése során. Miért? Mert vannak olyan pontok, amelyeket a technológia nem tud automatikusan biztosítani anélkül, hogy figyelembe venné az adatok szemantikáját. Például az információs szocializáció határainak ugyanaz a meghatározása. De megpróbáljuk ezeket a nehézségeket kicsiben tartani. Már van példa ilyen alkalmazások megvalósítására.
Az 1C:Enterprise többbérlős megvalósításának egyik fontos pontja, hogy egy hibrid modellt hozunk létre, amelyben egy alkalmazás több bérlési módban és normál módban is működhet. Ez nagyon nehéz feladat, és külön megbeszélés tárgya.
Forrás: will.com