Tyvärr har denna term inte en bra ryskspråkig analog. Wikipedia ger "flerhyresrätt, flerbostadsrätt." Detta kallas ibland "multiple ownership". Dessa termer kan vara något förvirrande, eftersom ämnet inte i sig är förknippat med vare sig hyra eller ägande. Detta är en fråga om mjukvaruarkitektur och organisation av dess verksamhet. Och det senare är inte mindre viktigt.
Vi började formulera vår förståelse för multitenancy samtidigt som vi började designa ett förhållningssätt till molnmodellen (tjänste) för arbetet i 1C:Enterprise. Detta var flera år sedan. Och sedan dess har vår förståelse ständigt utökats. Vi upptäcker ständigt fler och fler nya aspekter av detta ämne (fördelar, nackdelar, svårigheter, funktioner, etc.).
Ibland förstår utvecklare multitenancy som ett mycket enkelt ämne: "för att data från flera organisationer ska lagras i en databas måste du lägga till en kolumn med organisationsidentifieraren i alla tabeller och ställa in ett filter på den." Vi började naturligtvis också vår studie av frågan från detta ögonblick. Men de insåg snabbt att detta bara var en röjning (också förresten inte lätt). I allmänhet är detta ett "helt land".
Grundidén med multitenancy kan beskrivas ungefär så här. En typisk applikation är en stuga designad för att rymma en familj, som använder sin infrastruktur (väggar, tak, vattenförsörjning, värme, etc.). En flerbostadsansökan är ett hyreshus. I den använder varje familj samma infrastruktur, men själva infrastrukturen är implementerad för hela huset.
Är multitenancy-metoden bra eller dålig? Du kan hitta väldigt olika åsikter om detta. Det verkar inte finnas något "bra eller dåligt" alls. Du måste jämföra för- och nackdelar i samband med de specifika uppgifter som ska lösas. Men det här är ett separat ämne...
I sin enklaste mening är målet med multitenancy att minska kostnaderna för att underhålla en applikation genom att "socialisera" infrastrukturkostnaderna. Detta är samma rörelse som att minska kostnaden för en applikation genom att använda en produktionslösning (eventuellt med anpassning och modifiering), istället för att skriva den "på beställning". Endast i ett fall socialiseras utvecklingen, och i det andra - exploatering.
Dessutom, vi upprepar, det finns ingen direkt koppling till försäljningsmetoden. Multitenancy-arkitektur kan också användas i en företags- eller avdelnings IT-infrastruktur för att automatisera ett stort antal liknande filialer och holdingföretag.
Vi kan säga att multitenancy inte bara är en fråga om att organisera datalagring. Detta är en modell för hur applikationen fungerar som helhet (inklusive en betydande del av dess arkitektur, dess implementeringsmodell och dess underhållsorganisation).
Det svåraste och mest intressanta med multitenancy-modellen, verkar det för oss, är att kärnan i applikationen "förgrenar sig." En del av funktionaliteten arbetar med specifika dataområden (lägenheter) och är ”inte intresserade” av att det finns boende i andra lägenheter. Och vissa uppfattar huset som en helhet och fungerar för alla boende på en gång. Samtidigt kan den senare inte bortse från det faktum att dessa trots allt är separata lägenheter, och det är nödvändigt att säkerställa den nödvändiga nivån av granularitet och säkerhet.
I 1C:Enterprise är multitenancy-modellen implementerad på nivån för flera teknologier. Dessa är mekanismerna för 1C:Enterprise-plattformen, mekanismerna för"Och"", mekanismer (bibliotek med standarddelsystem).
Var och en av dessa poster bidrar till konstruktionen av den övergripande infrastrukturen i ett hyreshus. Varför implementeras detta i flera teknologier, och inte i en, till exempel i en plattform? Först och främst eftersom vissa av mekanismerna, enligt vår mening, är ganska lämpliga att modifiera för ett specifikt distributionsalternativ. Men i allmänhet är detta en svår fråga, och vi står ständigt inför ett val - på vilken nivå är det bättre att implementera den här eller den aspekten av multitenancy.
Uppenbarligen behövde den grundläggande delen av mekanismerna implementeras i plattformen. Jo, till exempel, själva dataseparationen. Det är här folk brukar börja prata om flerboende. Men i slutändan "färdades" multitenancy-modellen genom en betydande del av plattformens mekanismer och krävde deras förfining, och i vissa fall omtänkande.
På plattformsnivå implementerade vi exakt de grundläggande mekanismerna. De låter dig skapa applikationer som körs i en multitenancy-modell. Men för att applikationer ska "leva och arbeta" i en sådan modell måste du ha ett system för att hantera deras "livsaktiviteter". 1cFärska teknologier och ett enhetligt lager för affärslogik på BSP-nivå är ansvariga för detta. Precis som i ett hyreshus infrastrukturen förser invånarna med allt de behöver, så tillhandahåller 1cFresh-teknologier allt de behöver för applikationer som körs i en multitenancy-modell. Och så att applikationer kan interagera med denna infrastruktur (utan betydande ändringar), placeras motsvarande "anslutningar" i dem i form av BSP-delsystem.
Ur plattformsmekanismernas synvinkel är det lätt att märka att när vi får erfarenhet och utvecklar molnanvändningsfallet "1C:Enterprise", utökar vi sammansättningen av de mekanismer som är involverade i denna arkitektur. Låt oss ge ett exempel. I multitenancy-modellen förändras rollerna för applikationstjänstdeltagare avsevärt. Rollen (ansvarsnivån) för de som ansvarar för driften av applikationer ökar avsevärt. Det blev nödvändigt för dem att ha kraftfullare applikationskontrollverktyg. Eftersom applikationsanvändare (invånare) litar först och främst på leverantören de arbetar med. För att göra detta implementerade vi en ny . Denna mekanism gör det möjligt för leverantörsadministratörer att begränsa friheten för applikationsutvecklare till den nödvändiga säkerhetsnivån - i huvudsak för att isolera driften av applikationen för varje hyresgäst inom en viss sandlåda.
Inte mindre intressant är arkitekturen för att hantera applikationer som arbetar i multitenancy-läge (det som är implementerat i 1cFresh- och BSP-teknologier). Här, jämfört med den konventionella implementeringsmodellen, ökar kraven på automatisering av förvaltningsprocesser avsevärt. Det finns dussintals sådana processer: skapa nya dataområden ("lägenheter"), uppdatering av applikationer, uppdatering av regelinformation, säkerhetskopior etc. Och naturligtvis ökar kraven på tillförlitlighet och tillgänglighet. Till exempel, för att säkerställa tillförlitlig interaktion mellan applikationer och styrsystemkomponenter, implementerade vi asynkron samtalssystemteknik med garanterad leverans.
En mycket subtil poäng är sättet att socialisera data och processer. Det verkar enkelt (om det verkar för någon) bara vid första anblicken. Den största utmaningen är balansen mellan centralisering av data och processer och decentralisering. Å ena sidan låter centralisering dig minska kostnaderna (diskutrymme, processorresurser, administratörsinsatser...). Å andra sidan begränsar det "hyresgästernas" frihet. Detta är exakt ett av ögonblicken av "fördelning" av applikationen, när utvecklaren måste tänka samtidigt på applikationen i snäv mening (betjänar en "lägenhet") och i vid mening (betjänar alla "hyresgäster" på en gång) .
Som ett exempel på ett sådant "dilemma" kan man nämna reglerande och referensinformation. Naturligtvis finns det en stor frestelse att göra det gemensamt för alla "hyresgäster" i huset. Detta gör att du kan lagra den i en kopia och uppdatera den för alla på en gång. Men det händer att vissa boende behöver specifika förändringar. Konstigt nog sker detta i praktiken, även för information som specificeras av tillsynsmyndigheter (statliga organ). Detta visar sig vara en svår fråga: att umgås eller inte att umgås? Det är förstås lockande att göra informationen generell för alla och privat för den som vill ha den. Och detta leder redan till ett mycket svårt genomförande. Men vi jobbar på det här...
Ett annat exempel är utformningen av implementeringen av ordinarie processer (exekveras enligt ett schema, initierat av kontrollsystemet, etc.). Å ena sidan kan de implementeras för varje dataområde separat. Det är enklare och bekvämare. Men å andra sidan skapar en sådan fin granularitet en stor belastning på systemet. För att minska belastningen måste du implementera socialiserade processer. Men de kräver mer noggranna studier.
Naturligtvis väcker detta en mycket viktig fråga. Hur kan applikationsutvecklare säkerställa multitenancy? Vad behöver de göra för detta? Naturligtvis strävar vi efter att se till att bördan av tekniska och infrastrukturella frågor så mycket som möjligt faller på axlarna av den levererade tekniken, och applikationsutvecklaren tänker bara i termer av affärslogikuppgifter. Men som med andra viktiga arkitekturfrågor måste applikationsutvecklare ha viss förståelse för att arbeta i multitenancy-modellen och en viss ansträngning kommer att krävas när de utvecklar applikationer. Varför? För det finns punkter som tekniken inte kan ge automatiskt utan att ta hänsyn till datas semantik. Till exempel samma definition av gränserna för informationssocialisering. Men vi försöker hålla dessa svårigheter små. Det finns redan exempel på implementering av sådana applikationer.
En viktig punkt i samband med implementering av multitenancy i 1C:Enterprise är att vi skapar en hybridmodell där en applikation kan fungera i både multitenancy-läge och normalt läge. Detta är en mycket svår uppgift och föremål för en separat diskussion.
Källa: will.com