Sajnos ennek a kifejezésnek nincs jó magyar megfelelője. A „Wikipédia” a következőt adja „multibérlet, többszörös bérlés”. Néha ezt „többségi ownership”-nek is nevezik. Ezek a kifejezések kissé zavaróak lehetnek, mivel a téma lényegében sem a bérléssel, sem a tulajdonnal nincs összefüggésben. Ez valójában a szoftverarchitektúra és annak üzemeltetése kérdése. Ráadásul az utóbbi nem kevésbé fontos.
Az multitenancy megértésünket egy időben kezdtük el kialakítani, amikor megkezdtük az „1C:Enterprise” felhő (szolgáltatási) modelljének terveit. Ez néhány éve történt. Azóta megértésünk folyamatosan bővül. Folyamatosan felfedezünk újabb és újabb aspektusokat (előnyöket, hátrányokat, nehézségeket, sajátosságokat stb.).
Néha a fejlesztők a multitenancy alatt egy viszonylag egyszerű dolgot értenek: „ahhoz, hogy több szervezet adatai egy adatbázisban tárolódjanak, hozzá kell adni az összes táblához egy oszlopot a szervezeti azonosítóval, és szűrőt kell beállítani rá.” Mi is ezzel a kérdéssel foglalkoztunk. De elég gyorsan rájöttünk, hogy ez csak egy kis terület (ami szintén nem egyszerű). Valójában ez egy „egész ország”.
A multitenancy fő ötletét így lehetne körülírni. A szokványos alkalmazás egy családnak szánt nyaraló, amely a saját infrastruktúráját (falak, tető, vízellátás, fűtés stb.) használja. Egy multitenancy alkalmazás pedig egy társasház. Abban minden család ugyanazokat az infrastruktúrákat használja, de maga az infrastruktúra az egész ház számára van megvalósítva.
De a multitenancy megközelítés jó vagy rossz? Erről nagyon eltérő vélemények léteznek. Úgy tűnik, hogy nincs „jó vagy rossz” egyáltalán. Az előnyöket és hátrányokat a konkrét feladatok kontextusában kell összehasonlítani. De ez egy külön téma…
A legegyszerűbb értelemben a multitenancy célja a költségek csökkentése az alkalmazás fenntartásában az infrastruktúra „közösítése” révén. Ez hasonló mozgás, mint az alkalmazás költségeinek csökkentése egy sorozatmegoldás alkalmazásával (lehet, hogy konfigurálással és módosítással), nem pedig „egyedi” írása. Csak annyiban közösítjük a fejlesztést, a másik esetben pedig az üzemeltetést.
Meg kell említenünk, hogy itt nincs közvetlen kapcsolat az értékesítési móddal. A multitenancy architektúra teljes mértékben alkalmazható vállalati vagy közigazgatási informatikai infrastruktúrákban, lehetővé téve számos hasonló fiók, holdingvállalat automatatizálását.
Azt mondhatjuk, hogy a multitenancy nem csupán az adatmezők szervezésének kérdése. Ez a teljes alkalmazás működési modellje (beleértve annak architektúrájának jelentős részét, a telepítési modellt és a karbantartás megszervezését).
Ami a multitenancy modellben a legbonyolultabb és legérdekesebb, az az, hogy az alkalmazás lényege "megkettőződik". A funkciók egy része konkrét adatmezőkkel (lakásokkal) dolgozik, és "nem érdekli", hogy más lakásokban kik a bérlők. A funkciók egy másik része viszont az egész házat érzékeli, és az összes bérlő számára dolgozik. Utóbbi azonban nem tud elvonatkoztatni attól, hogy ezek mégiscsak különálló lakások, és biztosítani kell a szükséges szintű részletezettséget és biztonságot.
Az "1C:Enterprise" multitenancy modellje több technológia szintjén valósul meg. Ezek az "1C:Enterprise" platform mechanizmusai, mechanizmusaiés a "mechanizmusai (a standard alrendszerek könyvtárai).
Ezek a tételek mind hozzájárulnak a társasház általános infrastruktúrájának kiépítéséhez. Miért valósul meg ez több technológia révén, és nem egyetlen platformban? Elsősorban azért, mert egyes mechanizmusok, véleményünk szerint, teljesen indokoltak a telepítés konkrét változatait illetően. De általánosságban ez nem egyszerű kérdés, és folyamatosan azon a döntés előtt állunk, hogy mely szinten érdemes megvalósítani a multitenancy egyes aspektusait.
Nyilvánvaló, hogy a mechanizmusok alapvető részét a platformon kellett megvalósítani. Például az adatok tényleges szétválasztása. Ez az, amivel általában a multitenancy-ról beszélünk. De végül a multitenancy modell "végigment" a platform mechanizmusainak jelentős részén, és igényelte azok továbbfejlesztését, sőt bizonyos esetekben újragondolását.
A platform szintjén pontosan az alapvető mechanizmusokat valósítottuk meg. Ezek lehetővé teszik olyan alkalmazások létrehozását, amelyek a multitenancy modellben működnek. De ahhoz, hogy az alkalmazások "éljenek és működjenek" egy ilyen modellben, szükség van egy olyan rendszere, amely a "életciklusuk" irányításáért felelős. Ezt a 1cFresh technológiák és a BSP szintjén egységesített üzleti logikára épülő réteg biztosítja. Ahogyan egy lakóház infrastruktúrája minden szükségeset megad a lakóknak, úgy a 1cFresh technológiák is mindent biztosítanak a multitenancy modellben működő alkalmazások számára. Ahhoz, hogy az alkalmazások kapcsolatba léphessenek ezzel az infrastruktúrával (jelentős módosítások nélkül), a megfelelő "csatlakozókat" helyezik el bennük a BSP alrendszereinek formájában.
A platform mechanizmusait tekintve könnyen észlelhető, hogy a "1C: Vállalkozás" felhő alapú alkalmazásának tapasztalatainak és fejlődésének fokozásával bővítjük a mechanizmusok összetételét, amelyek részt vesznek ezen architektúrában. Egy példát hozunk. A multitenancy modellben lényegesen megváltozik az alkalmazások karbantartásában részt vevő szereplők szerepe. Jelentősen nő azok szerepe (felelősségi szintje), akik az alkalmazások üzemeltetésért felelősek. Számukra szükségessé vált, hogy erősebb eszközök álljanak rendelkezésre az alkalmazások ellenőrzésére. Mivel az alkalmazásokat használó felhasználók (bérlők) elsősorban abban bíznak, akivel dolgoznak. E célból a 8.3-as verzióban új valósítottuk meg. Ez a mechanizmus lehetővé teszi a szolgáltató adminisztrátorainak, hogy a fejlesztők munkájának szabadságát a szükséges biztonsági szintre korlátozzák – lényegében az alkalmazás munkáját izolálják minden bérlő számára egy adott "homokozó" keretein belül.
A multitenancy application management architecture, as seen in technologies like 1cFresh and BSP, is of great interest. Compared to a standard deployment model, it significantly raises the requirements for process automation. There are dozens of such processes: creating new data areas ('apartments'), application updates, regulatory information updates, backups, etc. Furthermore, the demands for reliability and availability increase. For example, to ensure reliable interaction between applications and management system components, we have implemented an asynchronous call system with guaranteed delivery.
A very subtle aspect is how to share data and processes. It may seem simple at first glance (if anyone thinks so). The greatest challenge lies in balancing data and process centralization with decentralization. On one hand, centralization reduces costs (disk space, CPU resources, administrator efforts, etc.). On the other hand, it restricts the freedom of 'residents'. This is one of the moments of 'splitting' the application, where developers must think about the application both in a narrow sense (serving one 'apartment') and in a broad sense (serving all 'residents' at once).
A good example of such a 'dilemma' is regulatory reference information. Of course, there is a strong temptation to make it common for all 'residents' of the building. This allows for storage in a single instance and immediate updates for everyone. However, sometimes a specific resident may require unique changes. Surprisingly, this occurs even for information specified by regulators (government bodies). It raises a complex question: to share or not to share? It is tempting to make general information for everyone and private for those who want it. Yet this leads to quite a complicated implementation. But we are working on it...
Egy másik példa a rendszeres folyamatok (ütemezett, a vezérlőrendszer által kezdeményezett stb.) megvalósításának tervezése. Egyrészt elképzelhető, hogy minden adatmezőre külön valósítjuk meg őket. Ez egyszerűbb és kényelmesebb. Másrészt azonban egy ilyen apró granularitás nagyobb terhet ró a rendszerre. A terhelés csökkentése érdekében közös folyamatokat kell megvalósítanunk. De ezek alaposabb kidolgozást igényelnek.
Természetesen felmerül egy nagyon lényeges kérdés. Hogyan biztosíthatják az alkalmazásfejlesztők a multitenancy üzemmódban való működést? Mit kell tenniük ehhez? Nyilvánvaló, hogy arra törekszünk, hogy a technológiai és infrastruktúra kérdések terhe a lehető legnagyobb mértékben a biztosított technológiára háruljon, és az alkalmazásfejlesztő csak az üzleti logika feladataira gondoljon. De, mint más fontos architekturális kérdéseknél, az alkalmazásfejlesztőknek szükségük van valamilyen elképzelésre a multitenancy modell működéséről, és bizonyos erőfeszítésekre az alkalmazások fejlesztése során. Miért? Mert vannak olyan szempontok, amelyeket a technológia nem tud automatikusan biztosítani a adatok szemantikájának figyelembevétel nélkül. Például az információk közösségi határainak meghatározása. De arra törekszünk, hogy ezek a nehézségek kicsik legyenek. Már léteznek példák az ilyen alkalmazások megvalósítására.
A multitenancy megvalósításának fontos szempontja a "1C:Vállalat" keretein belül, hogy hibrid modellt hozunk létre, amelyben egy alkalmazás működhet multitenancy módban és hagyományos módban is. Ez meglehetősen nehéz feladat, és külön megbeszélést igényel.
Forrás: habr.com
