TyvÀrr har den hÀr termen inget bra svenskt motsvarighet. "Wikipedia" ger "multitenancy, flera hyresgÀster". Ibland kallas det "flervalsÀgarform". Dessa termer kan vara nÄgot förvirrande, eftersom Àmnet egentligen inte har att göra med varken hyra eller Àgande. Det handlar helt enkelt om mjukvaruarkitektur och hur den underhÄlls, vilket Àr minst lika viktigt.
Vi började formulera vÄr förstÄelse för multitenancy samtidigt som vi började designa vÄr strategi för den molnbaserade (tjÀnstebaserade) modellen för "1C:Enterprise". Det var för flera Är sedan, och sedan dess har vÄr förstÄelse stÀndigt utvidgats. Vi upptÀcker hela tiden nya aspekter av detta Àmne (fördelar, nackdelar, utmaningar, sÀrskildheter etc.).
Ibland ser utvecklare multitenancy som nÄgot ganska enkelt: "För att data frÄn flera organisationer ska lagras i en och samma databas, behöver vi lÀgga till en kolumn med organisationens ID i alla tabeller och sÀtta en filter baserat pÄ det." Det var ocksÄ hur vi började utforska frÄgan. Men vi insÄg ganska snabbt att detta bara Àr en del av ett mycket större omrÄde (som ocksÄ Àr ganska komplext). Detta Àr egentligen "ett helt land".
Huvididén bakom multitenancy kan beskrivas pÄ följande sÀtt. En vanlig applikation Àr ett hus, avsett för en enda familj som anvÀnder dess infrastruktur (vÀggar, tak, vattenförsörjning, uppvÀrmning etc.). Men en multitenancy-applikation Àr en flerfamiljsbyggnad. I den anvÀnder varje familj samma infrastruktur, men infrastrukturen har utformats för hela byggnaden.
Ăr metoden multitenancy bra eller dĂ„lig? Det finns mĂ„nga olika Ă„sikter om detta. Det verkar som om det inte finns nĂ„got som Ă€r "bra eller dĂ„ligt" i allmĂ€nhet. Man mĂ„ste jĂ€mföra fördelar och nackdelar i kontexten av specifika problem som ska lösas. Men det Ă€r ett separat Ă€mne...
I sin enklaste förstÄelse Àr syftet med multitenancy att minska kostnaderna för att upprÀtthÄlla applikationen genom att "dela" infrastrukturen. Detta Àr en liknande rörelse som att minska kostnaden för en applikation genom att anvÀnda en standardlösning (eventuellt med anpassning och förbÀttring), snarare Àn att skriva "pÄ bestÀllning". I det första fallet delas utvecklingen, medan det i det andra fallet handlar om driften.
För att upprepa, det finns ingen direkt koppling hÀr till försÀljningsmetoden. Multitenancy-arkitekturen kan mycket vÀl tillÀmpas i företags- eller myndighets-IT-infrastruktur för att automatisera ett stort antal liknande filialer eller dotterbolag.
Man kan sÀga att multitenancy inte bara handlar om hur man organiserar datalagring. Det Àr en helhetsmodell för applikationens arbete (inklusive en betydande del av dess arkitektur, distributionsmodellen och servicerutinerna).
Det som Àr mest komplext och intressant i multitenancy-modellen, som vi ser det, Àr att sjÀlva applikationens essens "delas upp". En del av funktionaliteten arbetar med specifika datadomÀner (lÀgenheter) och "bryr sig inte" om att det finns boende i andra lÀgenheter. Medan en annan del uppfattar hela byggnaden och arbetar för alla boende samtidigt. Samtidigt kan den senare inte abstrahera frÄn att det faktiskt Àr separata lÀgenheter och att man mÄste sÀkerstÀlla den nödvÀndiga nivÄn av granularitet och sÀkerhet.
I "1C:Enterprise" implementeras multitenancy-modellen pÄ flera nivÄer av teknologier. Det handlar om mekanismerna i plattformen "1C:Enterprise", mekanismerna "" och "", mekanismerna (bibliotek med standardundersystem).
Varje av dessa föremĂ„l bidrar till att bygga den gemensamma infrastrukturen för ett flerbostadshus. Varför realiseras detta med flera teknologier istĂ€llet för en, till exempel, i plattformen? Framför allt för att vissa mekanismer, enligt vĂ„r mening, Ă€r helt rimliga att modifiera vid ett specifikt distributionsalternativ. Men som helhet Ă€r detta en komplex frĂ„ga, och vi stĂ€lls stĂ€ndigt inför val â pĂ„ vilken nivĂ„ det Ă€r bĂ€st att implementera varje aspekt av multitenancy.
Det Àr uppenbart att den grundlÀggande delen av mekanismerna mÄste implementeras i plattformen. Till exempel, sjÀlva uppdelningen av data. Det som man vanligtvis börjar diskutera nÀr det handlar om multitenancy. Men i slutÀndan har multitenancy-modellen "kört" genom en betydande del av plattformens mekanismer och krÀvt deras förbÀttringar, och i vissa fall Àven omprövningar.
PÄ plattformsnivÄ har vi implementerat grunderna. De möjliggör skapandet av applikationer som fungerar i en multitenancy-modell. Men för att applikationerna "ska leva och fungera" i en sÄdan modell behövs ett system för att hantera deras "livscykel". Det ansvarar teknologierna 1cFresh och det standardiserade lagret för affÀrslogik pÄ BSP-nivÄ. Precis som i ett flerfamiljshus ser infrastrukturen till att hyresgÀsterna fÄr allt de behöver, sÄ ser teknologierna 1cFresh till att applikationerna, som fungerar i multitenancy-modellen, fÄr allt sitt nödvÀndiga. För att applikationerna ska kunna interagera med denna infrastruktur (utan större anpassningar) placeras lÀmpliga "kontaktpunkter" i form av BSP-system.
NĂ€r det gĂ€ller plattforms mekanismer Ă€r det lĂ€tt att se att i takt med att vi fĂ„r mer erfarenhet och utvecklar den molnbaserade anvĂ€ndningen av "1C:Enterprise" utökar vi uppsĂ€ttningen av de mekanismer som ingĂ„r i denna arkitektur. LĂ„t oss ge ett exempel. I multitenancy-modellen förĂ€ndras rollfördelningen mellan deltagarna i applikationsunderhĂ„llet avsevĂ€rt. AnsvarsnivĂ„n för dem som ansvarar för driften av applikationerna ökar betydligt. De har nu ett större behov av kraftfulla verktyg för applikationsövervakning. Eftersom applikationsanvĂ€ndarna (hyresgĂ€sterna) frĂ€mst litar pĂ„ den leverantör de arbetar med. För detta har vi implementerat en ny i version 8.3. . Denna mekanism gör det möjligt för tjĂ€nsteleverantörens administratörer att begrĂ€nsa applikationsutvecklarnas frihet till en nödvĂ€ndig sĂ€kerhetsnivĂ„ â i praktiken att isolera applikationens arbete för varje hyresgĂ€st inom vissa ramar av en "sandlĂ„da".
Arkitekturen för att hantera applikationer som körs i ett multitenancy-lÀge (vilket realiseras i teknologier som 1cFresh och BSP) Àr ocksÄ av stort intresse. HÀr, jÀmfört med en vanlig distributionsmodell, ökar kraven pÄ automatiseringen av hanteringsprocesser betydligt. Det finns tiotals sÄdana processer: att skapa nya datadomÀner ("lÀgenheter"), uppdatera applikationer, uppdatera regulatory information, sÀkerhetskopiering, etc. Och sjÀlvklart ökar kraven pÄ pÄlitlighet och tillgÀnglighet. Till exempel har vi implementerat en teknik för asynkron anropssystem med garanterad leverans för att sÀkerstÀlla tillförlitlig interaktion mellan applikationerna och systemhanteringskomponenterna.
Ett mycket subtilt moment Ă€r sĂ€ttet att dela upp data och processer. Det kan verka enkelt (om nĂ„gon tycker sĂ„) bara vid första pĂ„seende. Den största svĂ„righeten Ă€r balansen mellan centralisering av data och processer och decentralisering. Ă ena sidan tillĂ„ter centralisering att minska kostnader (diskutrymme, processorresurser, insatser frĂ„n administratörerâŠ). Ă andra sidan begrĂ€nsar det "invĂ„narnas" frihet. Det Ă€r just en av punkterna för "klyvningen" av applikationen, nĂ€r utvecklaren mĂ„ste tĂ€nka pĂ„ applikationen bĂ„de i en snĂ€v mening (som betjĂ€nar en "lĂ€genhet") och i en bred mening (som betjĂ€nar alla "invĂ„nare" pĂ„ en gĂ„ng).
Ett exempel pÄ en sÄdan "dilemma" kan vara normativ information. Det Àr naturligtvis frestande att göra den gemensam för alla "invÄnare" i huset. Det tillÄter bÄde att lagra den i ett exemplar och att uppdatera den direkt för alla. Men det kan hÀnda att nÄgon invÄnare behöver specifika Àndringar. Konstigt nog, men i praktiken Àr detta vanligt, Àven för information som specificeras av regulatorer (statliga organ). Det stÀller en svÄr frÄga: att dela upp eller inte dela upp? Det Àr förvisso lockande att göra information gemensam för alla och privat för dem som vill ha det. Men det leder verkligen till en komplex implementering. Men vi arbetar med detta...
Ett annat exempel Àr utformningen av implementation av regelbundna processer (som utförs efter schema, initieras av styrsystemet, etc.). à ena sidan kan de implementeras för varje datakategori separat. Det Àr enklare och mer bekvÀmt. Men Ä andra sidan skapar en sÄdan fin granularitet en stor belastning pÄ systemet. För att minska belastningen bör gemensamma processer implementeras. Men de krÀver en mer noggrann bearbetning.
SjÀlvklart vÀcks en ganska betydande frÄga. Hur ska applikationsutvecklare sÀkerstÀlla drift i multitenancy-lÀge? Vad behöver de göra för det? Naturligtvis strÀvar vi efter att den tekniska och infrastrukturella belastningen i största möjliga utstrÀckning ligger pÄ den levererade teknologin, sÄ att applikationsutvecklaren enbart koncentrerar sig pÄ affÀrslogikens uppgifter. Men precis som med andra viktiga arkitekturella frÄgor behöver applikationsutvecklare ha en viss förstÄelse för hur multitenancy-modellen fungerar och vissa anstrÀngningar kommer att krÀvas vid utvecklingen av applikationer. Varför? För det finns aspekter som teknologin inte kan hantera automatiskt utan att ta hÀnsyn till datans semantik. Till exempel definitionen av grÀnserna för informationsgemenskap. Men vi strÀvar efter att dessa svÄrigheter ska vara smÄ. Exempel pÄ implementation av sÄdana applikationer finns redan.
En viktig punkt i samband med genomförandet av multitenancy i "1C:Enterprise" Àr att vi skapar en hybridmodell dÀr en applikation kan fungera sÄvÀl i multitenancy-lÀge som i vanligt lÀge. Detta Àr en ganska komplicerad uppgift och ett Àmne för separat diskussion.
KĂ€lla: habr.com
