{"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\/sl\/blog\/administrirovanie\/pro-multitenancy","title":{"rendered":"O multitenancy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u017dal, ta termin nima dobrega slovenskega ekvivalenta. \u201eWikipedia\u201c navaja prevod<\/a><\/noindex> \u201emultitenantnost, ve\u010dkratna najemnost\u201c. V\u010dasih to imenujejo \u201eve\u010dkratno lastni\u0161tvo\u201c. Ti termini lahko povzro\u010dajo nekaj zmede, saj tema v bistvu ni povezana niti z najemom niti z lastni\u0161tvom. Gre za vpra\u0161anje arhitekture programske opreme in organizacije njene rabe. Pri \u010demer je slednje prav tako pomembno. <\/p>\n

Na\u0161e razumevanje multitenancy smo za\u010deli oblikovati ravno takrat, ko smo za\u010deli zasnovati pristop k obla\u010dni (storitev) modelu dela \u201e1C: Pred podjetji\u201c. To je bilo pred nekaj leti. In od takrat se na\u0161e razumevanje nenehno \u0161iri. Nenehno odkrivamo nove in nove vidike te teme (prednosti, slabosti, zapletenosti, zna\u010dilnosti itd.). <\/p>\n

\"O
\n<\/a><\/noindex>
\nV\u010dasih razvijalci pod multitenancy razumejo precej preprosto stvar: \u201eda bi podatki ve\u010d organizacij bili shranjeni v eni bazi, je treba v vse tabele dodati stolpec z identifikatorjem organizacije in po njem nastaviti filtriranje\u201c. Tudi mi smo se, seveda, za\u010deli obravnavati to vpra\u0161anje od tega trenutka. A hitro smo spoznali, da je to samo ena majhna povr\u0161ina (ki je tudi precej zahtevna). Na splo\u0161no pa je to \u201ecela de\u017eela\u201c. <\/p>\n

Glavno idejo multitenancy lahko opi\u0161emo takole. Obi\u010dajna aplikacija je kot vikend hi\u0161a, namenjena enemu dru\u017einskemu \u017eivljenju, ki izkori\u0161\u010da njeno infrastrukturo (stene, streha, vodovod, ogrevanje itd.). Multitenancy aplikacija pa je ve\u010dstanovanjska hi\u0161a. V njej vsaka dru\u017eina uporablja enak set infrastrukture, toda sama infrastruktura je zasnovana za celotno hi\u0161o. <\/p>\n

Je pristop multitenancy dober ali slab? Na to vpra\u0161anje lahko najdemo zelo razli\u010dna mnenja. Zdi se, da ni \u201edobro ali slabo\u201c na splo\u0161no. Primerjati je treba prednosti in slabosti v kontekstu specifi\u010dnih re\u0161itev. A to je \u017ee druga tema\u2026 <\/p>\n

V najpreprostej\u0161em razumevanju je cilj multitenancy zmanj\u0161ati stro\u0161ke vzdr\u017eevanja aplikacije z \u201edelitvijo\u201c stro\u0161kov infrastrukture. To je enak proces kot zmanj\u0161anje stro\u0161kov aplikacije z uporabo masovno proizvedenega re\u0161itve (morda z nastavitvami in izbolj\u0161avami), namesto pisanja \u201epo naro\u010dilu\u201c. V enem primeru se deli razvoj, v drugem \u2013 obratovanje. <\/p>\n

Poudarimo, da tu ni neposredne povezave na na\u010din prodaje. Arhitektura multitenancy se lahko popolnoma uporablja tudi v korporativni ali vladni IT-infrastrukturi za avtomatizacijo velikega \u0161tevila enotnih poslovalnic, podjetij holdinga. <\/p>\n

Lahko re\u010demo, da multitenancy ni le vpra\u0161anje organizacije shranjevanja podatkov. To je model delovanja aplikacije kot celote (vklju\u010dno z bistvenimi vidiki njene arhitekture, modelom uvajanja in organizacijo vzdr\u017eevanja). <\/p>\n

Najbolj zapleteno in zanimivo pri modelu multitenancy, kot se nam zdi, je, da se bistvo aplikacije \"razdvoji\". Del funkcionalnosti deluje s specifi\u010dnimi podro\u010dji podatkov (stanovanji) in \"ne zanima\" ga, da v drugih stanovanjih \u017eivijo stanovalci. Drugi del dojema hi\u0161o kot celoto in deluje takoj za vse stanovalce. Pri tem se zadnji ne more abstrahirati od dejstva, da gre vendarle za posamezna stanovanja, in je treba zagotoviti potrebno raven granularnosti in varnosti. <\/p>\n

V \"1C:Podjetju\" se model multitenancy uresni\u010duje na ravni ve\u010d tehnologij. To so mehanizmi platforme \"1C:Podjetja\", mehanizmi \"1C:Tehnologija objavljanja re\u0161itev 1cFresh<\/a><\/noindex>\u00bb and \u00ab1C:Tehnologija razvoja re\u0161itev 1cFresh<\/a><\/noindex>\", mehanizmi BSP<\/a><\/noindex> (knji\u017enice standardnih podsystemov). <\/p>\n

Vsak od teh predmetov prispeva k oblikovanju skupne infrastrukture ve\u010dstanovanjskega doma. Zakaj se to uresni\u010duje v ve\u010d tehnologijah in ne v eni, na primer, na platformi? Predvsem zato, ker se nam zdi, da je del mehanizmov primerno modificirati za specifi\u010dno razli\u010dico uvajanja. Toda v splo\u0161nem je to zapleteno vpra\u0161anje in nenehno smo pred odlo\u010ditvijo \u2013 na kateri ravni je najbolje uresni\u010diti dolo\u010den vidik multitenancy. <\/p>\n

O\u010ditno je, da je bilo osnovni del mehanizmov treba uresni\u010diti na platformi. Na primer, dejansko razdelitev podatkov. To je tisto, od \u010desar se obi\u010dajno za\u010dne pogovor o multitenancy. Toda na koncu je model multitenancy \"pre\u0161el\" skozi veliko \u0161tevilo mehanizmov platforme in zahteval njihovo dopolnitev, v nekaterih primerih pa celo ponovno razmi\u0161ljanje. <\/p>\n

Na ravni platforme smo implementirali osnovne mehanizme. Ti omogo\u010dajo ustvarjanje aplikacij, ki delujejo v modelu multitenancy. Vendar pa, da bi aplikacije '\u017eivele in delovale' v tem modelu, potrebujemo sistem za upravljanje njihove '\u017eivljenjske dobe'. Za to poskrbijo tehnologije 1cFresh in enoten sloj poslovne logike na ravni BSP. Tako kot infrastruktura ve\u010dstanovanjskega objekta skrbi za vse potrebne stvari za prebivalce, tehnologije 1cFresh zagotavljajo vse potrebno aplikacijam, ki delujejo v modelu multitenancy. Da bi aplikacije lahko sodelovale s to infrastrukturo (brez bistvenih izbolj\u0161av), se v njih vnesejo ustrezni 'vti\u010di' v obliki podsystemov BSP. <\/p>\n

Z vidika mehanizmov platforme je lahko opaziti, da s pridobivanjem izku\u0161enj in razvojem obla\u010dnega na\u010dina uporabe '1C:Podjetja' \u0161irimo nabor mehanizmov, ki so vklju\u010deni v to arhitekturo. Pripravimo en primer. V modelu multitenancy se bistveno spreminja razporeditev vlog udele\u017eencev pri vzdr\u017eevanju aplikacij. Bistveno se pove\u010duje vloga (stopnja odgovornosti) tistih, ki so odgovorni za obratovanje aplikacij. Potrebno je, da imajo mo\u010dnej\u0161a orodja za nadzor aplikacij. Uporabniki aplikacij (prebivalci) zaupljajo predvsem ponudniku, s katerim delajo. Zato smo v razli\u010dici 8.3 implementirali nov mehanizem varnostnih profilov<\/a><\/noindex>. Ta mehanizem omogo\u010da administratorjem ponudnika, da omejijo svobodo razvijalcev aplikacij na potrebno stopnjo varnosti \u2013 v bistvu izolirajo delovanje aplikacije za vsakega prebivalca v dolo\u010denih okvirih 'peskovnika' (sandbox). <\/p>\n

Zelo zanimiva je tudi arhitektura za upravljanje aplikacij, ki delujejo v na\u010dinu multitenancy (to, kar se uresni\u010duje v tehnologijah 1cFresh in BSP). Tukaj, v primerjavi s tradicionalnim modelom uvajanja, znatno nara\u0161\u010dajo zahteve po avtomatizaciji procesov upravljanja. Takih procesov je desetine: ustvarjanje novih podatkovnih podro\u010dij (\u201estanovanj\u201c), posodabljanje aplikacij, posodabljanje normativnih informacij, varnostno kopiranje itd. In seveda nara\u0161\u010dajo zahteve po ravni zanesljivosti in dostopnosti. Na primer, za zagotavljanje zanesljive interakcije aplikacij s komponentami sistema upravljanja smo uvedli tehnologijo asinhronih klicnih sistemov z zagotovljeno dostavo. <\/p>\n

Zelo ob\u010dutljiv trenutek je na\u010din souporabe podatkov in procesov. Na prvi pogled se to zdi preprosto (\u010de se komu tako zdi). Najve\u010djo te\u017eavo predstavlja ravnote\u017eje med centralizacijo podatkov in procesov ter decentralizacijo. Po eni strani centralizacija omogo\u010da zmanj\u0161anje stro\u0161kov (diskovnega prostora, procesorskih virov, naporov administratorjev\u2026). Po drugi strani pa omejuje svobodo \u201estanovalcev\u201c. To je prav eden od trenutkov \u201erazdvajanja\u201c aplikacije, ko se mora razvijalec isto\u010dasno ukvarjati z aplikacijo v ozkem pomenu (ki slu\u017ei enemu \u201estanovanju\u201c) in v \u0161irokem pomenu (ki slu\u017ei vsem \u201estanovalcem\u201c). <\/p>\n

Kot primer te \u201edileme\u201c lahko navedemo normativno-informacijske podatke. Seveda je velika sku\u0161njava, da bi jih naredili skupne za vse \u201estanovalce\u201c hi\u0161e. To omogo\u010da, da jih hranimo v enem izvodu in jih posodobimo takoj za vse. A zgodi se, da nekemu stanovalcu potrebne specifi\u010dne spremembe. Kakorkoli \u017ee, v praksi se to pojavlja, celo za informacije, ki jih dolo\u010dajo regulativni organi (dr\u017eavni organi). Pojavi se zapleteno vpra\u0161anje: souporabiti ali ne souporabiti? O\u010ditno je mamljivo ustvariti skupne informacije za vse in zasebne za tiste, ki jih \u017eelijo. A to vodi v precej zapleteno realizacijo. Na tem delamo\u2026 <\/p>\n

Drugim primjerom je projektiranje i implementacija redovitih procesa (izvr\u0161avane prema rasporedu, inicirane upravlja\u010dkim sustavom itd.). S jedne strane, mogu se implementirati za svako podru\u010dje podataka posebno. To je jednostavnije i prakti\u010dnije. No, s druge strane, takva sitna granularnost stvara veliku optere\u0107enost sustava. Kako bismo smanjili optere\u0107enje, potrebno je implementirati zajedni\u010dke procese. No oni zahtijevaju pa\u017eljiviju obradu. <\/p>\n

Naravno, postavlja se vrlo va\u017eno pitanje. Kako osigurati rad aplikacijskih programera u re\u017eimu multitenancy? \u0160to moraju u\u010diniti za to? Naravno, te\u017eimo tome da teret tehnolo\u0161kih i infrastrukturnih pitanja maximo bude na ramenima isporu\u010dene tehnologije, dok bi aplikacijski programer razmi\u0161ljao samo o poslovnoj logici. No kao i s drugim va\u017enim arhitektonskim pitanjima, aplikacijski programeri moraju imati barem neku predstavu o radu u modelu multitenancy i neka napora \u0107e biti potrebna prilikom razvoja aplikacija. Za\u0161to? Zato \u0161to postoje aspekti koje tehnologija ne mo\u017ee automatski osigurati bez razmatranja semantike podataka. Na primjer, definiranje granica zajedni\u010dkog kori\u0161tenja informacija. Me\u0111utim, trudimo se da ti izazovi budu \u0161to manji. Ve\u0107 postoje primjeri implementacije takvih aplikacija. <\/p>\n

Va\u017ena to\u010dka u kontekstu implementacije multitenancy u \"1C:Poduze\u0107u\" je to \u0161to kreiramo hibridni model, u kojem jedna aplikacija mo\u017ee raditi kako u re\u017eimu multitenancy, tako i u obi\u010dnom re\u017eimu. To je prili\u010dno slo\u017een zadatak i predmet je zasebne rasprave.
\n
Izvor: 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\udd47O multitenancy | ProHoster","description":"Na\u017ealost, ovaj izraz nema dobrog ruskog ekvivalenta.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/pro-multitenancy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/55231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=55231"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/55231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/55232"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=55231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=55231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=55231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}