Tyvärr har denna term ingen bra ryskspråkig motsvarighet. Wikipedia ger "flerhyresrätt, flerbostadsrätt". Detta kallas ibland "multiple ownership". Dessa termer kan vara något förvirrande, eftersom ämnet inte i huvudsak är relaterat till vare sig hyra eller ägande. Detta är en fråga om mjukvaruarkitektur och organisationen av dess verksamhet. Dessutom är det senare inte mindre viktigt.
Vi började bilda oss en förståelse för multitenancy samtidigt som vi började designa ett tillvägagångssätt för 1C:Enterprises molnmodell (tjänstemodell). Det var flera år sedan. Och sedan dess har vår förståelse ständigt utökats. Vi upptäcker ständigt nya och nya aspekter av detta ämne (fördelar, nackdelar, svårigheter, funktioner, etc.).
Ibland förstår utvecklare multitenancy som en mycket enkel sak: "för att lagra data från flera organisationer 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årt arbete med frågan från och med detta ögonblick. Men vi insåg snabbt att detta bara var en röjning (också förresten ingen lätt sådan). I allmänhet är detta "ett helt land".
Grundtanken med multitenancy kan beskrivas ungefär så här. En typisk applikation är en stuga designad för en familj att bo i, som använder sin infrastruktur (väggar, tak, vattenförsörjning, värme, etc.). Och en flerbostadsansökan är ett hyreshus. I den använder varje familj samma infrastruktur, men själva infrastrukturen är implementerad för hela huset som helhet.
Är multitenancy-metoden bra eller dålig? Det finns väldigt olika åsikter om detta. Det verkar som att det inte finns 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 ä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 massproducerad lösning (eventuellt med anpassning och revidering), istället för att skriva den "på beställning". Endast i det ena fallet socialiseras utvecklingen och i det andra exploateringen.
Dessutom, låt oss upprepa, det finns ingen direkt koppling till försäljningsmetoden. Multitenancy-arkitekturen kan användas i företags- eller avdelnings IT-infrastruktur för att automatisera ett stort antal liknande filialer och holdingbolag.
Man kan säga att multitenancy inte bara är en fråga om att organisera datalagring. Detta är en modell för applikationens funktion som helhet (inklusive en betydande del av dess arkitekturaspekter, och distributionsmodellen och organisationen av underhåll).
Det svåraste och mest intressanta med multitenancy-modellen, som det verkar för oss, är att kärnan i applikationen är "delad". En del av funktionaliteten fungerar 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 abstrahera sig 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 helt 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 uppdelningen av data. Det här är vad man brukar börja med när man pratar om flerboende. Men i slutändan "körde" multitenancy-modellen över en betydande del av plattformens mekanismer och krävde deras revidering, och i vissa fall, omtanke.
På plattformsnivå implementerade vi 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 krävs det ett system för att hantera sin "livsaktivitet". 1cFärska teknologier och ett enhetligt lager av 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å förser 1cFresh-teknologier applikationer som arbetar i multitenancy-modellen med allt de behöver. Och så att applikationer kan interagera med denna infrastruktur (utan betydande ändringar), är de utrustade med lämpliga "anslutningar" i form av BSP-delsystem.
Ur plattformsmekanismernas synvinkel är det lätt att se att när vi får erfarenhet och utvecklar molnversionen av att använda 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 arrangemanget av roller för deltagare i applikationsunderhåll avsevärt. Rollen (ansvarsnivån) för de ansvariga för driften av applikationer utökas avsevärt. De behövde kraftfullare applikationskontrollverktyg. Eftersom applikationsanvändare (invånare) litar först och främst på den leverantör de arbetar med. För detta ändamål har vi implementerat en ny funktion i version 8.3 . Denna mekanism gör det möjligt för leverantörsadministratörer att begränsa friheten för applikationsutvecklare till den erforderliga säkerhetsnivån - i huvudsak för att isolera applikationens funktion för varje hyresgäst inom den specifika ramen för "sandlådan".
Av inte mindre intresse är arkitekturen för att hantera applikationer som arbetar i multitenancy-läge (som är implementerat i 1cFresh- och BSP-teknologier). Här, jämfört med den vanliga implementeringsmodellen, höjs kraven på automatisering av förvaltningsprocesser avsevärt. Det finns dussintals sådana processer: skapande av nya dataområden ("lägenheter"), applikationsuppdateringar, uppdateringar 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 en asynkron samtalssystemteknik med garanterad leverans.
En mycket subtil punkt är sättet på vilket data och processer delas. Det verkar enkelt (om det verkar så 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 etc.). Å andra sidan begränsar det "invånarnas" frihet. Detta är just 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 bred bemärkelse (betjänar alla "invånare" på en gång).
Som exempel på ett sådant ”dilemma” kan vi nämna normativ referensinformation. Naturligtvis finns det en stor frestelse att göra det gemensamt för alla "invånare" 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 någon hyresgäst behöver specifika förändringar. Konstigt nog sker detta i praktiken även för information som specificeras av tillsynsmyndigheter (statliga myndigheter). Det visar sig vara en svår fråga: att umgås eller inte att umgås? Det är naturligtvis lockande att göra allmän information för alla och privat för den som vill ha det. Och detta leder redan till ett mycket svårt genomförande. Men vi jobbar på det...
Ett annat exempel är utformningen av implementeringen av vanliga processer (exekveras enligt ett schema, initierat av ett kontrollsystem, 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 är det nödvändigt att implementera socialiserade processer. Men de kräver mer noggrann övervägande.
Detta väcker naturligtvis en mycket viktig fråga. Hur kan applikationsutvecklare säkerställa att de fungerar i multitenancy-läge? 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 arkitektoniska frågor är viss förståelse för hur multitenancy fungerar något som applikationsutvecklare måste ha, och en viss ansträngning kommer att krävas när de utvecklar applikationer. Varför? För det finns saker som tekniken inte kan tillhandahålla automatiskt utan att ta hänsyn till datas semantik. Till exempel samma definition av gränserna för informationsdelning. 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 att implementera multitenancy i 1C:Enterprise är att vi skapar en hybridmodell där en applikation kan fungera både i multitenancy-läge och i normalt läge. Detta är en mycket svår uppgift och ett ämne för separat diskussion.
Källa: will.com
