Dessverre har ikke dette begrepet en god russiskspråklig analog. Wikipedia gir "flerleieforhold, flereleieforhold." Dette kalles noen ganger «flere eierskap». Disse begrepene kan være noe forvirrende, siden emnet ikke er iboende forbundet med verken leie eller eie. Dette er et spørsmål om programvarearkitektur og organisering av driften. Og det siste er ikke mindre viktig.
Vi begynte å formulere vår forståelse av multitenancy samtidig som vi begynte å designe en tilnærming til sky(tjeneste)modellen for arbeid i 1C:Enterprise. Dette var flere år siden. Og siden den gang har vår forståelse kontinuerlig utvidet seg. Vi oppdager stadig flere og flere nye aspekter ved dette emnet (fordeler, ulemper, vanskeligheter, funksjoner, etc.).
Noen ganger forstår utviklere multitenancy som et veldig enkelt emne: "for at dataene til flere organisasjoner skal lagres i én database, må du legge til en kolonne med organisasjonsidentifikatoren til alle tabeller og sette et filter på den." Vi begynte selvfølgelig også vår studie av problemet fra dette øyeblikket. Men de skjønte raskt at dette kun var én lysning (også forresten ikke lett). Generelt er dette et "helt land".
Den grunnleggende ideen om multitenancy kan beskrives noe slikt. En typisk applikasjon er en hytte designet for å huse en familie, som bruker sin infrastruktur (vegger, tak, vannforsyning, oppvarming, etc.). En flerleiesøknad er en bygård. I den bruker hver familie samme infrastruktur, men selve infrastrukturen er implementert for hele huset.
Er multitenancy-tilnærmingen god eller dårlig? Du kan finne veldig forskjellige meninger om dette. Det ser ikke ut til å være noe "godt eller dårlig" i det hele tatt. Du må sammenligne fordeler og ulemper i sammenheng med de spesifikke oppgavene som løses. Men dette er et eget tema...
I sin enkleste forstand er målet med multitenancy å redusere kostnadene ved å vedlikeholde en applikasjon ved å "sosialisere" infrastrukturkostnadene. Dette er den samme bevegelsen som å redusere kostnadene for en applikasjon ved å bruke en produksjonsløsning (muligens med tilpasning og modifikasjon), i stedet for å skrive den "på bestilling." Bare i det ene tilfellet sosialiseres utviklingen, og i det andre - utnyttelse.
Dessuten, vi gjentar, er det ingen direkte kobling til salgsmetoden. Multitenancy-arkitektur kan også brukes i en bedrifts- eller avdelings IT-infrastruktur for å automatisere et stort antall lignende filialer og holdingbedrifter.
Vi kan si at multitenancy ikke bare er et spørsmål om å organisere datalagring. Dette er en modell for hvordan applikasjonen fungerer som helhet (inkludert en betydelig del av arkitekturen, distribusjonsmodellen og vedlikeholdsorganisasjonen).
Det vanskeligste og mest interessante med multitenancy-modellen, virker det for oss, er at essensen av applikasjonen "fordeler seg." En del av funksjonaliteten fungerer med spesifikke dataområder (leiligheter) og er «ikke interessert» i at det er beboere i andre leiligheter. Og noen oppfatter huset som en helhet og jobber for alle beboere på en gang. Samtidig kan sistnevnte ikke se bort fra det faktum at dette tross alt er separate leiligheter, og det er nødvendig å sikre det nødvendige nivået av granularitet og sikkerhet.
I 1C:Enterprise er multitenancy-modellen implementert på nivå med flere teknologier. Dette er mekanismene til 1C:Enterprise-plattformen, mekanismene til"Og"", mekanismer (biblioteker av standard delsystemer).
Hver av disse elementene bidrar til byggingen av den overordnede infrastrukturen til en bygård. Hvorfor er dette implementert i flere teknologier, og ikke i én, for eksempel i en plattform? Først av alt, fordi noen av mekanismene, etter vår mening, er ganske passende å modifisere for et spesifikt distribusjonsalternativ. Men generelt er dette et vanskelig spørsmål, og vi står stadig overfor et valg - på hvilket nivå er det bedre å implementere dette eller det aspektet av multitenancy.
Det er klart at den grunnleggende delen av mekanismene måtte implementeres i plattformen. Vel, for eksempel selve dataseparasjonen. Det er her folk vanligvis begynner å snakke om flerleieforhold. Men til slutt "reiste" multitenancy-modellen gjennom en betydelig del av plattformens mekanismer og krevde deres foredling, og i noen tilfeller, nytenkning.
På plattformnivå implementerte vi nøyaktig de grunnleggende mekanismene. De lar deg lage applikasjoner som kjører i en multitenancy-modell. Men for at applikasjoner skal "leve og fungere" i en slik modell, må du ha et system for å administrere deres "livsaktiviteter". 1cFriske teknologier og et enhetlig forretningslogikklag på BSP-nivå er ansvarlige for dette. Akkurat som i en leilighetsbygning gir infrastrukturen beboerne alt de trenger, så gir 1cFresh-teknologier alt de trenger for applikasjoner som kjører i en multitenancy-modell. Og slik at applikasjoner kan samhandle med denne infrastrukturen (uten vesentlige modifikasjoner), er de tilsvarende "koblingene" plassert i dem i form av BSP-undersystemer.
Fra plattformmekanismers synspunkt er det lett å legge merke til at etter hvert som vi får erfaring og utvikler skybrukssaken «1C:Enterprise», utvider vi sammensetningen av mekanismene som er involvert i denne arkitekturen. La oss gi ett eksempel. I multitenancy-modellen endres rollene til applikasjonstjenestedeltakere betydelig. Rollen (ansvarsnivået) til de ansvarlige for drift av applikasjoner øker betydelig. Det ble nødvendig for dem å ha kraftigere applikasjonskontrollverktøy. Fordi applikasjonsbrukere (beboere) stoler først og fremst på leverandøren de jobber med. For å gjøre dette implementerte vi en ny . Denne mekanismen lar leverandøradministratorer begrense friheten til applikasjonsutviklere til det nødvendige sikkerhetsnivået - i hovedsak for å isolere driften av applikasjonen for hver leietaker innenfor en bestemt sandkasse.
Ikke mindre interessant er arkitekturen for å administrere applikasjoner som opererer i multitenancy-modus (det som er implementert i 1cFresh- og BSP-teknologier). Her, sammenlignet med den konvensjonelle distribusjonsmodellen, økes kravene til automatisering av styringsprosesser betydelig. Det finnes dusinvis av slike prosesser: opprettelse av nye dataområder ("leiligheter"), oppdatering av applikasjoner, oppdatering av forskriftsinformasjon, sikkerhetskopier, osv. Og selvfølgelig øker kravene til nivået på pålitelighet og tilgjengelighet. For å sikre pålitelig interaksjon mellom applikasjoner og kontrollsystemkomponenter, implementerte vi for eksempel asynkron anropssystemteknologi med garantert levering.
Et veldig subtilt poeng er måten å sosialisere data og prosesser på. Det virker enkelt (hvis det virker for noen) bare ved første øyekast. Den største utfordringen er balansen mellom sentralisering av data og prosesser og desentralisering. På den ene siden lar sentralisering deg redusere kostnadene (diskplass, prosessorressurser, administratorinnsats...). På den annen side begrenser det friheten til «leietakerne». Dette er akkurat et av øyeblikkene med "bifurkasjon" av applikasjonen, når utvikleren trenger å tenke samtidig på applikasjonen i snever forstand (betjener en "leilighet") og i vid forstand (betjener alle "leietakere" samtidig) .
Som et eksempel på et slikt «dilemma» kan man sitere regulatorisk og referanseinformasjon. Selvfølgelig er det en stor fristelse å gjøre det felles for alle "leietakere" i huset. Dette lar deg lagre det i én kopi og oppdatere det for alle samtidig. Men det hender at noen beboere trenger konkrete endringer. Merkelig nok skjer dette i praksis, selv for informasjon som er spesifisert av regulatorer (statlige organer). Dette viser seg å være et vanskelig spørsmål: å sosialisere eller ikke å sosialisere? Det er selvsagt fristende å gjøre informasjonen generell for alle og privat for de som ønsker det. Og dette fører allerede til en svært vanskelig implementering. Men vi jobber med dette...
Et annet eksempel er utformingen av implementeringen av vanlige prosesser (utført på en tidsplan, initiert av kontrollsystemet, etc.). På den ene siden kan de implementeres for hvert dataområde separat. Det er enklere og mer praktisk. Men på den annen side skaper en slik fin granularitet en stor belastning på systemet. For å redusere belastningen må du implementere sosialiserte prosesser. Men de krever mer nøye studier.
Dette reiser selvfølgelig et veldig viktig spørsmål. Hvordan kan applikasjonsutviklere sikre multitenancy? Hva må de gjøre for dette? Selvfølgelig streber vi etter å sikre at byrden av teknologiske og infrastrukturspørsmål faller så mye som mulig på skuldrene til den leverte teknologien, og applikasjonsutvikleren tenker kun i form av forretningslogikkoppgaver. Men som med andre viktige arkitekturspørsmål, må applikasjonsutviklere ha en viss forståelse for å jobbe i multitenancy-modellen, og det vil kreves en viss innsats når de utvikler applikasjoner. Hvorfor? For det er punkter som teknologien ikke kan gi automatisk uten å ta hensyn til dataenes semantikk. For eksempel den samme definisjonen av grensene for informasjonssosialisering. Men vi prøver å holde disse vanskelighetene små. Det finnes allerede eksempler på implementering av slike applikasjoner.
Et viktig poeng i sammenheng med implementering av multitenancy i 1C:Enterprise er at vi lager en hybridmodell der én applikasjon kan operere i både multitenancy-modus og normal modus. Dette er en svært vanskelig oppgave og gjenstand for en separat diskusjon.
Kilde: www.habr.com