Desværre har denne term ikke et godt dansk equivalent. "Wikipedia" angiver "multi-leje, multipel leje". Nogle gange kaldes det "multiple ejerskab". Disse termer kan være lidt forvirrende, da emnet ikke i bund og grund handler om hverken leje eller ejerskab. Det er primært et spørgsmål om softwarearkitektur og organiseringen af dens drift. Og det sidste er lige så vigtigt.
Vi begyndte at danne vores forståelse af multitenancy samtidig med, at vi begyndte at designe tilgangen til den cloud-baserede (service) model for "1C:Enterprise". Det var for flere år siden. Og siden da er vores forståelse konstant blevet udvidet. Vi opdager konstant nye aspekter ved dette emne (fordele, ulemper, udfordringer, særegenheder osv.).
Nogle gange forstår udviklere multitenancy som et ganske enkelt emne: "for at data fra flere organisationer gemmes i én database, skal der tilføjes en kolonne med organisations-id til alle tabeller og sættes en filter baseret på det." Vi startede selvfølgelig også vores arbejde med spørgsmålet fra dette punkt. Men vi indså ret hurtigt, at det kun er én lille del af det (som også er ret komplekst). Generelt er det "et helt land".
Hovedideen med multitenancy kan beskrives på denne måde. Et almindeligt program er en hytte, der er designet til at huse én familie, som bruger dens infrastruktur (vægge, tag, vandforsyning, opvarmning osv.). Et multitenancy-program er en lejlighedsbygning. Her bruger hver familie den samme infrastruktur, men selve infrastrukturen er implementeret for hele bygningen som helhed.
Er multitenancy-tilgangen god eller dårlig? Der er mange forskellige meninger om dette. Det forekommer, at der ikke er nogen entydig "godt eller dårligt". Man bør sammenligne fordele og ulemper i konteksten af de specifikke opgaver, der skal løses. Men det er et separat emne...
I sin enkleste forstand er målet med multitenancy at reducere omkostningerne ved at vedligeholde applikationen ved at "dele" omkostningerne til infrastrukturen. Dette svarer til at reducere omkostningerne ved applikationen gennem brug af en standardløsning (muligvis med tilpasning og justering), fremfor at skrive "på bestilling". Kun i den ene situation deles udviklingen, mens der i den anden situation er tale om driften.
Det er vigtigt at gentage, at der ikke er en direkte forbindelse til salgsmetoden her. Multitenancy-arkitekturen kan anvendes i virksomheders eller institutioners IT-infrastruktur for at automatisere mange ensartede filialer og koncernens virksomheder.
Man kan sige, at multitenancy ikke blot handler om organiseringen af datalagring. Det er en hel arbejdsmodel for applikationen (herunder væsentlige aspekter af dens arkitektur, implementeringsmodellen og serviceorganisationen).
Det mest komplekse og interessante ved multitenancy-modellen, som vi ser det, er, at applikationens essens "splitter sig". En del funktionalitet arbejder med specifikke datakategorier (lejligheder) og "interesserer sig ikke for", at der er beboere i andre lejligheder. En anden del opfatter bygningen som helhed og arbejder for alle beboere på én gang. Samtidig kan den sidste del ikke abstrahere fra, at dette trods alt er separate lejligheder, og at der skal sikres et nødvendigt niveau af granularitet og sikkerhed.
I "1C:Enterprise" implementeres multitenancy-modellen på tværs af flere teknologier. Dette er mekanismerne fra "1C:Enterprise"-platformen, mekanismerne "" og "", mekanismerne (bibliotekerne for standardunderholdssystemer).
Hver af disse elementer bidrager til opbygningen af den samlede infrastruktur i en lejlighedsbygning. Hvorfor implementeres dette i flere teknologier og ikke i én, for eksempel på platformen? Først og fremmest fordi nogle af mekanismerne, efter vores mening, med rimelighed kan modificeres i forhold til den specifikke implementeringsvariation. Men generelt set er det ikke et simpelt spørgsmål, og vi står konstant over for valget – på hvilket niveau det er bedst at implementere en given aspekt af multitenancy.
Det er tydeligt, at den grundlæggende del af mekanismerne måtte implementeres på platformen. For eksempel selve adskillelsen af data. Det, som man normalt begynder at tale om, når emnet er multitenancy. Men i sidste ende "kørte" multitenancy-modellen over en betydelig del af platformens mekanismer og krævede deres forbedring, og i nogle tilfælde også en ny overvejelse.
På platformniveau har vi implementeret netop de grundlæggende mekanismer. De gør det muligt at skabe applikationer, der fungerer i multitenancy-modellen. Men for at applikationerne kan "leve og arbejde" i en sådan model, er det nødvendigt at have et system til at administrere deres "livscyklus". Teknologierne 1cFresh og det enhedlige lag af forretningslogik på BSP-niveau er ansvarlige for dette. Ligesom infrastruktur i en lejlighedsbygning sikrer beboerne det, de har brug for, sikrer teknologierne 1cFresh også, at applikationer, der arbejder i multitenancy-modellen, har alt nødvendigt. For at applikationerne kan interagere med denne infrastruktur (uden væsentlige ændringer), placeres de relevante "stik" i form af BSP-subsystemer.
Når man ser på platformens mekanismer, er det let at bemærke, at efterhånden som vi opnår erfaring og udvikler den cloud-baserede brug af "1C:Enterprise", udvider vi sammensætningen af de mekanismer, der er involveret i denne arkitektur. Lad os tage et eksempel. I multitenancy-modellen ændres fordelingen af rollerne blandt deltagerne i applikationsdriften betydeligt. Rollen (ansvarsområderne) for dem, der er ansvarlige for driften af applikationer, øges betydeligt. De har fået brug for mere kraftfulde værktøjer til kontrol af applikationer. Dette er fordi brugerne af applikationer (beboerne) primært stoler på den udbyder, de arbejder med. Til dette implementerede vi i version 8.3 en ny . Denne mekanisme gør det muligt for udbyderens administratorer at begrænse udviklernes frihed i applikationerne til det nødvendige sikkerhedsniveau – i praksis at isolere applikationens drift for hver beboer inden for bestemte rammer af en "sandkasse".
Arkitektur til styring af applikationer i multitenancy-tilstand, som implementeret i teknologierne 1cFresh og BSP, er lige så interessant. Sammenlignet med den normale implementeringsmodel kræver det væsentligt højere krav til automatisering af styringsprocesserne. Der er dusinvis af sådanne processer: oprettelse af nye datadomæner ("lejligheder"), opdatering af applikationer, opdatering af regulativ information, backup osv. Og selvfølgelig stiger kravene til pålidelighed og tilgængelighed. For eksempel har vi implementeret en teknologi til asynkrone opkaldssystemer med garanteret levering for at sikre pålidelig interaktion mellem applikationer og systemstyringskomponenterne.
En meget fin nyanse er måden, hvorpå data og processer gøres fælles. Det virker simpelt (hvis nogen mener det) ved første øjekast. Den største udfordring er balancen mellem centralisering af data og processer og decentralisering. På den ene side reducerer centralisering omkostningerne (diskplads, CPU-ressourcer, administratorindsats…). På den anden side begrænser det "lejerens" frihed. Dette er netop et af de punkter, hvor applikationen "delings" opstår, når udvikleren skal tænke på applikationen i snæver forstand (der betjener én "lejlighed") og i bred forstand (der betjener alle "lejere").
Et eksempel på sådan en "dilemma" er regulativ information. Det er klart, at der er en stor fristelse til at gøre den fælles for alle "lejere" i bygningen. Det muliggør både at opbevare den i én kopi og opdatere den for alle på én gang. Men det kan ske, at en bestemt lejer har brug for specifikke ændringer. Underligt nok ses dette i praksis, selv for informationer, der er specificeret af regulativerne (offentlige organer). Det rejser et vanskeligt spørgsmål: skal man gøre det fælles eller ej? Det er naturligvis fristende at lave information fælles for alle og privat for dem, der ønsker det. Men det fører til en ret kompleks implementering. Men vi arbejder på det...
Et andet eksempel er designet af implementeringen af regelmæssige processer (udført efter en tidsplan, initieret af det styrende system osv.). På den ene side kan de implementeres for hver datadomæne separat. Dette er lettere og mere praktisk. Men på den anden side skaber en så fin granularitet en stor belastning på systemet. For at reducere belastningen skal der implementeres fælles processer. Men de kræver en mere grundig bearbejdning.
Selvfølgelig rejser dette et meget vigtigt spørgsmål. Hvordan kan applikationsudviklerne sikre drift i multitenancy-tilstand? Hvad skal de gøre for dette? Selvfølgelig stræber vi efter, at byrden af tekniske og infrastrukturelle spørgsmål i videst muligt omfang hviler på den leverede teknologi, så applikationsudvikleren kun tænker på forretningslogikkens opgaver. Men ligesom med andre vigtige arkitektoniske spørgsmål, har applikationsudviklere brug for en vis forståelse for arbejdet i en multitenancy-model, og der kræves en vis indsats i udviklingen af applikationer. Hvorfor? Fordi der er aspekter, som teknologien ikke automatisk kan sikre uden at tage hensyn til datasemantikken. For eksempel, selve definitionen af grænserne for informationens deling. Men vi prøver at holde disse kompleksiteter på et minimum. Der findes allerede eksempler på implementering af sådanne applikationer.
Et vigtigt punkt i konteksten af implementeringen af multitenancy i "1C:Enterprise" er, at vi skaber en hybridmodel, hvor én applikation kan fungere både i multitenancy-tilstand og i almindelig tilstand. Dette er en temmelig kompleks opgave og et emne for separat diskussion.
Kilde: habr.com
