{"id":55231,"date":"2020-01-16T00:00:00","date_gmt":"2020-01-15T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/pro-multitenancy"},"modified":"2020-02-18T14:03:19","modified_gmt":"2020-02-18T11:03:19","slug":"pro-multitenancy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pro-multitenancy","title":{"rendered":"Om multitenancy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Desv\u00e6rre har denne term ikke et godt dansk equivalent. \"Wikipedia\" angiver overs\u00e6ttelse<\/a><\/noindex> \"multi-leje, multipel leje\". Nogle gange kaldes det \"multiple ejerskab\". Disse termer kan v\u00e6re lidt forvirrende, da emnet ikke i bund og grund handler om hverken leje eller ejerskab. Det er prim\u00e6rt et sp\u00f8rgsm\u00e5l om softwarearkitektur og organiseringen af dens drift. Og det sidste er lige s\u00e5 vigtigt. <\/p>\n

Vi begyndte at danne vores forst\u00e5else af multitenancy samtidig med, at vi begyndte at designe tilgangen til den cloud-baserede (service) model for \"1C:Enterprise\". Det var for flere \u00e5r siden. Og siden da er vores forst\u00e5else konstant blevet udvidet. Vi opdager konstant nye aspekter ved dette emne (fordele, ulemper, udfordringer, s\u00e6regenheder osv.). <\/p>\n

\"Om
\n<\/a><\/noindex>
\nNogle gange forst\u00e5r udviklere multitenancy som et ganske enkelt emne: \"for at data fra flere organisationer gemmes i \u00e9n database, skal der tilf\u00f8jes en kolonne med organisations-id til alle tabeller og s\u00e6ttes en filter baseret p\u00e5 det.\" Vi startede selvf\u00f8lgelig ogs\u00e5 vores arbejde med sp\u00f8rgsm\u00e5let fra dette punkt. Men vi inds\u00e5 ret hurtigt, at det kun er \u00e9n lille del af det (som ogs\u00e5 er ret komplekst). Generelt er det \"et helt land\". <\/p>\n

Hovedideen med multitenancy kan beskrives p\u00e5 denne m\u00e5de. Et almindeligt program er en hytte, der er designet til at huse \u00e9n familie, som bruger dens infrastruktur (v\u00e6gge, 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. <\/p>\n

Er multitenancy-tilgangen god eller d\u00e5rlig? Der er mange forskellige meninger om dette. Det forekommer, at der ikke er nogen entydig \"godt eller d\u00e5rligt\". Man b\u00f8r sammenligne fordele og ulemper i konteksten af de specifikke opgaver, der skal l\u00f8ses. Men det er et separat emne... <\/p>\n

I sin enkleste forstand er m\u00e5let 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\u00f8sning (muligvis med tilpasning og justering), fremfor at skrive \"p\u00e5 bestilling\". Kun i den ene situation deles udviklingen, mens der i den anden situation er tale om driften. <\/p>\n

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. <\/p>\n

Man kan sige, at multitenancy ikke blot handler om organiseringen af datalagring. Det er en hel arbejdsmodel for applikationen (herunder v\u00e6sentlige aspekter af dens arkitektur, implementeringsmodellen og serviceorganisationen). <\/p>\n

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\u00e5 \u00e9n gang. Samtidig kan den sidste del ikke abstrahere fra, at dette trods alt er separate lejligheder, og at der skal sikres et n\u00f8dvendigt niveau af granularitet og sikkerhed. <\/p>\n

I \"1C:Enterprise\" implementeres multitenancy-modellen p\u00e5 tv\u00e6rs af flere teknologier. Dette er mekanismerne fra \"1C:Enterprise\"-platformen, mekanismerne \"1C:Teknologi til publicering af l\u00f8sninger 1cFresh<\/a><\/noindex>\" og \"1C:Teknologi til udvikling af l\u00f8sninger 1cFresh<\/a><\/noindex>\", mekanismerne BSP<\/a><\/noindex> (bibliotekerne for standardunderholdssystemer). <\/p>\n

Hver af disse elementer bidrager til opbygningen af den samlede infrastruktur i en lejlighedsbygning. Hvorfor implementeres dette i flere teknologier og ikke i \u00e9n, for eksempel p\u00e5 platformen? F\u00f8rst 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\u00f8rgsm\u00e5l, og vi st\u00e5r konstant over for valget \u2013 p\u00e5 hvilket niveau det er bedst at implementere en given aspekt af multitenancy. <\/p>\n

Det er tydeligt, at den grundl\u00e6ggende del af mekanismerne m\u00e5tte implementeres p\u00e5 platformen. For eksempel selve adskillelsen af data. Det, som man normalt begynder at tale om, n\u00e5r emnet er multitenancy. Men i sidste ende \"k\u00f8rte\" multitenancy-modellen over en betydelig del af platformens mekanismer og kr\u00e6vede deres forbedring, og i nogle tilf\u00e6lde ogs\u00e5 en ny overvejelse. <\/p>\n

P\u00e5 platformniveau har vi implementeret netop de grundl\u00e6ggende mekanismer. De g\u00f8r det muligt at skabe applikationer, der fungerer i multitenancy-modellen. Men for at applikationerne kan \"leve og arbejde\" i en s\u00e5dan model, er det n\u00f8dvendigt at have et system til at administrere deres \"livscyklus\". Teknologierne 1cFresh og det enhedlige lag af forretningslogik p\u00e5 BSP-niveau er ansvarlige for dette. Ligesom infrastruktur i en lejlighedsbygning sikrer beboerne det, de har brug for, sikrer teknologierne 1cFresh ogs\u00e5, at applikationer, der arbejder i multitenancy-modellen, har alt n\u00f8dvendigt. For at applikationerne kan interagere med denne infrastruktur (uden v\u00e6sentlige \u00e6ndringer), placeres de relevante \"stik\" i form af BSP-subsystemer. <\/p>\n

N\u00e5r man ser p\u00e5 platformens mekanismer, er det let at bem\u00e6rke, at efterh\u00e5nden som vi opn\u00e5r erfaring og udvikler den cloud-baserede brug af \"1C:Enterprise\", udvider vi sammens\u00e6tningen af de mekanismer, der er involveret i denne arkitektur. Lad os tage et eksempel. I multitenancy-modellen \u00e6ndres fordelingen af rollerne blandt deltagerne i applikationsdriften betydeligt. Rollen (ansvarsomr\u00e5derne) for dem, der er ansvarlige for driften af applikationer, \u00f8ges betydeligt. De har f\u00e5et brug for mere kraftfulde v\u00e6rkt\u00f8jer til kontrol af applikationer. Dette er fordi brugerne af applikationer (beboerne) prim\u00e6rt stoler p\u00e5 den udbyder, de arbejder med. Til dette implementerede vi i version 8.3 en ny sikkerhedsprofilmekanisme<\/a><\/noindex>. Denne mekanisme g\u00f8r det muligt for udbyderens administratorer at begr\u00e6nse udviklernes frihed i applikationerne til det n\u00f8dvendige sikkerhedsniveau \u2013 i praksis at isolere applikationens drift for hver beboer inden for bestemte rammer af en \"sandkasse\". <\/p>\n

Arkitektur til styring af applikationer i multitenancy-tilstand, som implementeret i teknologierne 1cFresh og BSP, er lige s\u00e5 interessant. Sammenlignet med den normale implementeringsmodel kr\u00e6ver det v\u00e6sentligt h\u00f8jere krav til automatisering af styringsprocesserne. Der er dusinvis af s\u00e5danne processer: oprettelse af nye datadom\u00e6ner (\"lejligheder\"), opdatering af applikationer, opdatering af regulativ information, backup osv. Og selvf\u00f8lgelig stiger kravene til p\u00e5lidelighed og tilg\u00e6ngelighed. For eksempel har vi implementeret en teknologi til asynkrone opkaldssystemer med garanteret levering for at sikre p\u00e5lidelig interaktion mellem applikationer og systemstyringskomponenterne. <\/p>\n

En meget fin nyanse er m\u00e5den, hvorp\u00e5 data og processer g\u00f8res f\u00e6lles. Det virker simpelt (hvis nogen mener det) ved f\u00f8rste \u00f8jekast. Den st\u00f8rste udfordring er balancen mellem centralisering af data og processer og decentralisering. P\u00e5 den ene side reducerer centralisering omkostningerne (diskplads, CPU-ressourcer, administratorindsats\u2026). P\u00e5 den anden side begr\u00e6nser det \"lejerens\" frihed. Dette er netop et af de punkter, hvor applikationen \"delings\" opst\u00e5r, n\u00e5r udvikleren skal t\u00e6nke p\u00e5 applikationen i sn\u00e6ver forstand (der betjener \u00e9n \"lejlighed\") og i bred forstand (der betjener alle \"lejere\"). <\/p>\n

Et eksempel p\u00e5 s\u00e5dan en \"dilemma\" er regulativ information. Det er klart, at der er en stor fristelse til at g\u00f8re den f\u00e6lles for alle \"lejere\" i bygningen. Det muligg\u00f8r b\u00e5de at opbevare den i \u00e9n kopi og opdatere den for alle p\u00e5 \u00e9n gang. Men det kan ske, at en bestemt lejer har brug for specifikke \u00e6ndringer. Underligt nok ses dette i praksis, selv for informationer, der er specificeret af regulativerne (offentlige organer). Det rejser et vanskeligt sp\u00f8rgsm\u00e5l: skal man g\u00f8re det f\u00e6lles eller ej? Det er naturligvis fristende at lave information f\u00e6lles for alle og privat for dem, der \u00f8nsker det. Men det f\u00f8rer til en ret kompleks implementering. Men vi arbejder p\u00e5 det... <\/p>\n

Et andet eksempel er designet af implementeringen af regelm\u00e6ssige processer (udf\u00f8rt efter en tidsplan, initieret af det styrende system osv.). P\u00e5 den ene side kan de implementeres for hver datadom\u00e6ne separat. Dette er lettere og mere praktisk. Men p\u00e5 den anden side skaber en s\u00e5 fin granularitet en stor belastning p\u00e5 systemet. For at reducere belastningen skal der implementeres f\u00e6lles processer. Men de kr\u00e6ver en mere grundig bearbejdning. <\/p>\n

Selvf\u00f8lgelig rejser dette et meget vigtigt sp\u00f8rgsm\u00e5l. Hvordan kan applikationsudviklerne sikre drift i multitenancy-tilstand? Hvad skal de g\u00f8re for dette? Selvf\u00f8lgelig str\u00e6ber vi efter, at byrden af tekniske og infrastrukturelle sp\u00f8rgsm\u00e5l i videst muligt omfang hviler p\u00e5 den leverede teknologi, s\u00e5 applikationsudvikleren kun t\u00e6nker p\u00e5 forretningslogikkens opgaver. Men ligesom med andre vigtige arkitektoniske sp\u00f8rgsm\u00e5l, har applikationsudviklere brug for en vis forst\u00e5else for arbejdet i en multitenancy-model, og der kr\u00e6ves 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\u00e6nserne for informationens deling. Men vi pr\u00f8ver at holde disse kompleksiteter p\u00e5 et minimum. Der findes allerede eksempler p\u00e5 implementering af s\u00e5danne applikationer. <\/p>\n

Et vigtigt punkt i konteksten af implementeringen af multitenancy i \"1C:Enterprise\" er, at vi skaber en hybridmodel, hvor \u00e9n applikation kan fungere b\u00e5de i multitenancy-tilstand og i almindelig tilstand. Dette er en temmelig kompleks opgave og et emne for separat diskussion.
\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0443 \u044d\u0442\u043e\u0433\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430 \u043d\u0435\u0442 \u0445\u043e\u0440\u043e\u0448\u0435\u0433\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u043e\u0433\u043e \u0430\u043d\u0430\u043b\u043e\u0433\u0430. \u00ab\u0412\u0438\u043a\u0438\u043f\u0435\u0434\u0438\u044f\u00bb \u0434\u0430\u0435\u0442 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u00ab\u043c\u0443\u043b\u044c\u0442\u0438\u0430\u0440\u0435\u043d\u0434\u043d\u043e\u0441\u0442\u044c, \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u0430\u0440\u0435\u043d\u0434\u0430\u00bb. \u0418\u043d\u043e\u0433\u0434\u0430 \u044d\u0442\u043e \u043d\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u00ab\u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u043c \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u0435\u043c\u00bb. \u042d\u0442\u0438 \u0442\u0435\u0440\u043c\u0438\u043d\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0443\u0442\u0430\u0442\u044c, \u0442\u0430\u043a \u043a\u0430\u043a \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043d\u0435 \u0441\u0432\u044f\u0437\u0430\u043d \u043f\u043e \u0441\u0443\u0442\u0438 \u043d\u0438 \u0441 \u0430\u0440\u0435\u043d\u0434\u043e\u0439, \u043d\u0438 \u0441 \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u0435\u043c. \u042d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0438\u043c\u0435\u043d\u043d\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u0438 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0435\u0433\u043e \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438. \u041f\u0440\u0438\u0447\u0435\u043c \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u043d\u0435 \u043c\u0435\u043d\u0435\u0435 \u0432\u0430\u0436\u043d\u043e. \u041c\u044b \u043d\u0430\u0447\u0430\u043b\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":55232,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55231","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Om multitenancy | ProHoster","description":"Desv\u00e6rre er der ikke en god dansk overs\u00e6ttelse af dette udtryk.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pro-multitenancy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u043e multitenancy | ProHoster","og:description":"\u041a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0443 \u044d\u0442\u043e\u0433\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430 \u043d\u0435\u0442 \u0445\u043e\u0440\u043e\u0448\u0435\u0433\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u043e\u0433\u043e \u0430\u043d\u0430\u043b\u043e\u0433\u0430.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pro-multitenancy","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-15T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:19+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55231","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:47:39","updated":"2022-09-29 20:30:21","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/55231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=55231"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/55231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/55232"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=55231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=55231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=55231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}