Desværre har dette udtryk ikke en god russisk-sproget analog. Wikipedia giver "flerlejemål, flerelejemål." Dette kaldes nogle gange "multiple ownership". Disse vilkår kan være noget forvirrende, da emnet ikke i sagens natur er forbundet med hverken at leje eller eje. Dette er et spørgsmål om softwarearkitektur og organisering af dens drift. Og det sidste er ikke mindre vigtigt.
Vi begyndte at formulere vores forståelse af multitenancy, samtidig med at vi begyndte at designe en tilgang til cloud-(service)-modellen af arbejde i 1C:Enterprise. Dette var flere år siden. Og siden da er vores forståelse konstant blevet udvidet. Vi opdager konstant flere og flere nye aspekter af dette emne (fordele, ulemper, vanskeligheder, funktioner osv.).
Nogle gange forstår udviklere multitenancy som et meget simpelt emne: "for at data fra flere organisationer kan lagres i én database, skal du tilføje en kolonne med organisationsidentifikatoren til alle tabeller og sætte et filter på den." Vi begyndte selvfølgelig også vores undersøgelse af spørgsmålet fra dette øjeblik. Men de indså hurtigt, at dette kun var én lysning (også i øvrigt ikke let). Generelt er dette et "helt land".
Den grundlæggende idé om multitenancy kan beskrives sådan her. En typisk applikation er et sommerhus designet til at rumme en familie, som bruger sin infrastruktur (vægge, tag, vandforsyning, varme osv.). En multilejeansøgning er en lejlighedsbygning. I den bruger hver familie den samme infrastruktur, men selve infrastrukturen er implementeret for hele huset.
Er multitenancy-tilgangen god eller dårlig? Du kan finde meget forskellige meninger om dette. Der synes ikke at være noget "godt eller dårligt" overhovedet. Du skal sammenligne fordele og ulemper i forbindelse med de konkrete opgaver, der løses. Men dette er et særskilt emne...
I sin enkleste forstand er målet med multitenancy at reducere omkostningerne ved at vedligeholde en applikation ved at "socialisere" infrastrukturomkostningerne. Dette er den samme bevægelse som at reducere omkostningerne ved en applikation ved at bruge en produktionsløsning (eventuelt med tilpasning og modifikation) i stedet for at skrive den "på bestilling". Kun i det ene tilfælde er udvikling socialiseret, og i det andet - udnyttelse.
Desuden gentager vi, at der ikke er nogen direkte forbindelse til salgsmetoden. Multitenancy-arkitektur kan også bruges i en virksomheds eller afdelings IT-infrastruktur til at automatisere et stort antal lignende filialer og holdingvirksomheder.
Vi kan sige, at multitenancy ikke kun er et spørgsmål om at organisere datalagring. Dette er en model for, hvordan applikationen fungerer som helhed (herunder en væsentlig del af dens arkitektur, dens implementeringsmodel og dens vedligeholdelsesorganisation).
Det sværeste og mest interessante ved multitenancy-modellen, forekommer det os, er, at essensen af applikationen "fordeler." En del af funktionaliteten arbejder med specifikke dataområder (lejligheder) og er ”ikke interesseret” i, at der er beboere i andre lejligheder. Og nogle opfatter huset som en helhed og arbejder for alle beboere på én gang. Sidstnævnte kan samtidig ikke se bort fra, at der trods alt er tale om separate lejligheder, og det er nødvendigt at sikre det nødvendige niveau af granularitet og sikkerhed.
I 1C:Enterprise er multitenancy-modellen implementeret på niveau med flere teknologier. Det er mekanismerne i 1C:Enterprise platformen, mekanismerne for"Og"", mekanismer (biblioteker af standardundersystemer).
Hver af disse elementer bidrager til opførelsen af den overordnede infrastruktur i en lejlighedsbygning. Hvorfor er dette implementeret i flere teknologier, og ikke i én, for eksempel i en platform? Først og fremmest fordi nogle af mekanismerne efter vores mening er ret passende at modificere til en specifik implementeringsmulighed. Men generelt er dette et svært spørgsmål, og vi står konstant over for et valg - på hvilket niveau er det bedre at implementere dette eller hint aspekt af multitenancy.
Det er klart, at den grundlæggende del af mekanismerne skulle implementeres i platformen. Nå, for eksempel, selve dataadskillelsen. Det er her, folk normalt begynder at tale om multilejemål. Men i sidste ende "rejste" multitenancy-modellen gennem en betydelig del af platformens mekanismer og krævede deres forfining og i nogle tilfælde gentænkning.
På platformsniveau implementerede vi præcis de grundlæggende mekanismer. De giver dig mulighed for at oprette applikationer, der kører i en multitenancy-model. Men for at applikationer kan "leve og arbejde" i en sådan model, skal du have et system til at styre deres "livsaktiviteter". 1cFriske teknologier og et samlet forretningslogiklag på BSP-niveau er ansvarlige for dette. Ligesom i en lejlighedsbygning giver infrastrukturen beboerne alt, hvad de har brug for, så giver 1cFresh-teknologier alt, hvad de har brug for til applikationer, der kører i en multitenancy-model. Og for at applikationer kan interagere med denne infrastruktur (uden væsentlige ændringer), er de tilsvarende "stik" placeret i dem i form af BSP-undersystemer.
Fra platformsmekanismernes synspunkt er det let at bemærke, at efterhånden som vi får erfaring og udvikler cloud use casen "1C:Enterprise", udvider vi sammensætningen af de mekanismer, der er involveret i denne arkitektur. Lad os give et eksempel. I multitenancy-modellen ændres rollerne for applikationstjenestedeltagere betydeligt. Rollen (ansvarsniveauet) for de ansvarlige for drift af applikationer øges markant. Det blev nødvendigt for dem at have mere kraftfulde applikationskontrolværktøjer. Fordi applikationsbrugere (beboere) først og fremmest stoler på den udbyder, de arbejder med. For at gøre dette implementerede vi en ny . Denne mekanisme giver udbyderadministratorer mulighed for at begrænse applikationsudvikleres frihed til det nødvendige sikkerhedsniveau - i det væsentlige for at isolere applikationens drift for hver lejer inden for en bestemt sandkasse.
Ikke mindre interessant er arkitekturen til styring af applikationer, der fungerer i multitenancy-tilstand (hvad der er implementeret i 1cFresh- og BSP-teknologier). Her er kravene til automatisering af ledelsesprocesser væsentligt øget sammenlignet med den konventionelle implementeringsmodel. Der er snesevis af sådanne processer: oprettelse af nye dataområder ("lejligheder"), opdatering af applikationer, opdatering af lovgivningsmæssige oplysninger, sikkerhedskopier osv. Og selvfølgelig er kravene til niveauet af pålidelighed og tilgængelighed stigende. For at sikre pålidelig interaktion mellem applikationer og styresystemkomponenter implementerede vi for eksempel asynkron opkaldssystemteknologi med garanteret levering.
En meget subtil pointe er måden at socialisere data og processer på. Det virker simpelt (hvis det forekommer nogen) kun ved første øjekast. Den største udfordring er balancen mellem centralisering af data og processer og decentralisering. På den ene side giver centralisering dig mulighed for at reducere omkostningerne (diskplads, processorressourcer, administratorindsats...). På den anden side begrænser det "lejernes" frihed. Dette er præcis et af de øjeblikke, hvor applikationen "fordeler" applikationen, hvor udvikleren skal tænke på applikationen samtidigt i snæver forstand (betjener én "lejlighed") og i bred forstand (betjener alle "lejere" på én gang) .
Som et eksempel på et sådant "dilemma" kan man nævne regulerings- og referenceoplysninger. Selvfølgelig er der en stor fristelse til at gøre det fælles for alle husets "lejere". Dette giver dig mulighed for at gemme det i én kopi og opdatere det for alle på én gang. Men det sker, at nogle beboere har brug for specifikke ændringer. Mærkeligt nok sker dette i praksis, selv for oplysninger, der er specificeret af tilsynsmyndigheder (statslige organer). Dette viser sig at være et svært spørgsmål: at socialisere eller ikke at socialisere? Det er selvfølgelig fristende at gøre informationen almen for alle og privat for dem, der ønsker det. Og dette fører allerede til en meget vanskelig implementering. Men vi arbejder på det...
Et andet eksempel er udformningen af implementeringen af almindelige processer (udføres efter en tidsplan, initieret af kontrolsystemet osv.). På den ene side kan de implementeres for hvert dataområde separat. Det er nemmere og mere bekvemt. Men på den anden side skaber en sådan fin granularitet en stor belastning på systemet. For at reducere belastningen skal du implementere socialiserede processer. Men de kræver mere omhyggelig undersøgelse.
Dette rejser naturligvis et meget væsentligt spørgsmål. Hvordan kan applikationsudviklere sikre multitenancy? Hvad skal de gøre for dette? Vi bestræber os naturligvis på at sikre, at byrden af teknologiske og infrastrukturmæssige problemer så meget som muligt falder på skuldrene af den leverede teknologi, og applikationsudvikleren tænker kun i forretningslogiske opgaver. Men som med andre vigtige arkitektoniske spørgsmål, skal applikationsudviklere have en vis forståelse for at arbejde i multitenancy-modellen, og der kræves en vis indsats, når de udvikler applikationer. Hvorfor? For der er punkter, som teknologien ikke kan give automatisk uden at tage hensyn til dataens semantik. For eksempel den samme definition af grænserne for informationssocialisering. Men vi prøver at holde disse vanskeligheder små. Der er allerede eksempler på implementering af sådanne applikationer.
Et vigtigt punkt i forbindelse med implementering af multitenancy i 1C:Enterprise er, at vi skaber en hybridmodel, hvor én applikation kan fungere i både multitenancy-tilstand og normal tilstand. Dette er en meget vanskelig opgave og genstand for en separat diskussion.
Kilde: www.habr.com