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

Helaas bestaat er geen goede Nederlandstalige term voor dit begrip. \"Wikipedia\" geeft vertaling<\/a><\/noindex> \"multi-tenant, meervoudige huur\". Soms wordt dit \"meervoudig eigendom\" genoemd. Deze termen kunnen wat verwarrend zijn, omdat het onderwerp eigenlijk niets te maken heeft met huur of eigendom. Het is een kwestie van softwarearchitectuur en de organisatie van het gebruik ervan, waarbij laatstgenoemde niet minder belangrijk is. <\/p>\n

We begonnen ons begrip van multitenancy te vormen op het moment dat we de aanpak voor het cloud (service) model van \"1C:Enterprise\" gingen ontwerpen. Dat was enkele jaren geleden. Sindsdien breidt ons begrip zich voortdurend uit. We ontdekken voortdurend nieuwe aspecten van dit onderwerp (voordelen, nadelen, moeilijkheden, bijzonderheden, enz.). <\/p>\n

\"Over
\n<\/a><\/noindex>
\nSoms begrijpen ontwikkelaars multitenancy als iets heel eenvoudigs: \"om gegevens van verschillende organisaties in \u00e9\u00e9n database op te slaan, moet je een kolom met de organisatie-identifier aan alle tabellen toevoegen en een filter daarop instellen\". Natuurlijk zijn we ook onze aanpak als volgt begonnen. Maar al snel realiseerden we ons dat dit slechts \u00e9\u00e9n aspect is (ook overigens niet gemakkelijk). Het is in feite een \"hele wereld\". <\/p>\n

De belangrijkste idee van multitenancy kan ongeveer als volgt worden beschreven. Een gewone applicatie is een huis dat is ontworpen voor het wonen van \u00e9\u00e9n familie, die gebruikmaakt van de infrastructuur (wanden, dak, watervoorziening, verwarming, enz.). Een multitenancy-applicatie is daarentegen een appartementencomplex. Elke familie maakt gebruik van dezelfde infrastructuur, maar de infrastructuur is gerealiseerd voor het gehele gebouw. <\/p>\n

Is de multitenancy-aanpak goed of slecht? Hierover zijn zeer verschillende meningen te vinden. Het lijkt erop dat er geen \"goed of slecht\" in het algemeen is. Je moet de voor- en nadelen vergelijken in de context van de specifieke taken die moeten worden opgelost. Maar dat is een apart onderwerp... <\/p>\n

In de eenvoudigste zin is het doel van multitenancy om de kosten van het onderhoud van de applicatie te verlagen door de kosten van de infrastructuur \"gemeenschappelijk\" te maken. Dit is vergelijkbaar met de vermindering van de kosten van de applicatie door het gebruik van een schaling oplossing (mogelijk met aanpassing en uitbreiding) in plaats van een \"op maat gemaakte\" oplossing. Alleen in het ene geval wordt de ontwikkeling gemeenschappelijk gemaakt, terwijl in het andere geval het gebruiksgemak wordt gedeeld. <\/p>\n

Wij herhalen dat er hier geen directe koppeling is aan de verkoopmethode. De multitenancy-architectuur kan perfect worden toegepast in een zakelijke of overheids-IT-infrastructuur voor de automatisering van een groot aantal soortgelijke vestigingen, bedrijven van een holding. <\/p>\n

Men kan zeggen dat multitenancy niet alleen een kwestie is van gegevensopslagorganisatie. Het is het hele werkmodel van de applicatie (inclusief een significant deel van de architectuuraspecten, de implementatiemodel en het onderhoudsorganisatie). <\/p>\n

Het meest complexe en interessante aan het multitenancy-model is, zoals wij denken, dat de essentie van de applicatie \"opgedeeld\" wordt. Een deel van de functionaliteit werkt met specifieke datavelden (appartementen) en \"interesseert zich niet\" voor de bewoners in andere appartementen. Een ander deel beschouwt het gebouw als geheel en werkt direct voor alle bewoners. Tegelijkertijd kan de laatste zich niet onttrekken aan het feit dat het toch afzonderlijke appartementen zijn, en het is noodzakelijk om een passend niveau van granulariteit en veiligheid te waarborgen. <\/p>\n

In \"1C:Enterprise\" wordt het multitenancy-model ge\u00efmplementeerd op het niveau van verschillende technologie\u00ebn. Dit zijn mechanismen van het \"1C:Enterprise\" platform, de mechanismen van \"1C:Technologie voor het publiceren van oplossingen 1cFresh<\/a><\/noindex>\u00bb en \u00ab1C:Technologie voor de ontwikkeling van oplossingen 1cFresh<\/a><\/noindex>\" mechanismen BSP<\/a><\/noindex> (bibliotheken van standaard subsystemen). <\/p>\n

Elk van deze elementen draagt bij aan de opbouw van de algemene infrastructuur van het appartementencomplex. Waarom wordt dit in verschillende technologie\u00ebn ge\u00efmplementeerd en niet in \u00e9\u00e9n, bijvoorbeeld in het platform? Vooral omdat een deel van de mechanismen, naar onze mening, heel goed kan worden aangepast aan de specifieke implementatievariant. Maar in algemene termen is dit een complexe kwestie en staan we voortdurend voor de keuze \u2013 op welk niveau we het beste een bepaald aspect van multitenancy kunnen implementeren. <\/p>\n

Het is duidelijk dat de basismechanismen in het platform moesten worden ge\u00efmplementeerd. Bijvoorbeeld, de eigenlijke scheiding van data. Dat is waar het gesprek over multitenancy meestal mee begint. Maar uiteindelijk heeft het multitenancy-model een aanzienlijk deel van de mechanismen van het platform doorlopen en eisen tot verbetering, en in sommige gevallen heroverweging, gesteld. <\/p>\n

Op het niveau van het platform hebben we precies de basismechanismen ge\u00efmplementeerd. Deze maken de creatie van applicaties mogelijk die werken in een multitenancy-model. Maar om ervoor te zorgen dat applicaties \u2018leven en functioneren\u2019 in zo'n model, is een systeem voor het beheer van hun \u2018levenscyclus\u2019 nodig. Dit wordt verzorgd door technologie\u00ebn zoals 1cFresh en de verenigde laag van bedrijfslogica op het niveau van BSP. Zoals de infrastructuur in een appartementencomplex de bewoners van alles voorziet wat ze nodig hebben, zo voorzien de technologie\u00ebn 1cFresh alle benodigde middelen voor applicaties die in het multitenancy-model werken. En om ervoor te zorgen dat applicaties met deze infrastructuur kunnen interageren (zonder significante aanpassingen), worden er passende \u2018aansluitingen\u2019 in de vorm van BSP-subsystemen in hen geplaatst. <\/p>\n

Vanuit het perspectief van de mechanismen van het platform is het gemakkelijk op te merken dat naarmate we ervaring opdoen en de cloudvariant van \u20181C:Enterprise\u2019 ontwikkelen, we het aantal mechanismen dat bij deze architectuur is betrokken uitbreiden. We geven een voorbeeld. In het multitenancy-model verandert de rolverdeling van de deelnemers aan het onderhoud van applicaties aanzienlijk. De rol (verantwoordelijkheidsniveau) van degenen die verantwoordelijk zijn voor de exploitatie van applicaties neemt aanzienlijk toe. Het is voor hen noodzakelijk geworden om krachtigere controle-instrumenten voor applicaties te hebben. Dit komt omdat de gebruikers van applicaties (bewoners) vooral vertrouwen op de provider waarmee ze samenwerken. Daarom hebben we in versie 8.3 een nieuwe mechanisme voor beveiligingsprofielen<\/a><\/noindex>. Dit mechanisme stelt beheerders van de provider in staat om de vrijheid van applicatieontwikkelaars te beperken tot het noodzakelijke beveiligingsniveau \u2013 in wezen het werk van de applicatie voor elke bewoner binnen bepaalde kaders van een \u2018sandbox\u2019 (sandbox) te isoleren. <\/p>\n

De architectuur voor het beheren van applicaties in een multitenancy-modus (zoals ge\u00efmplementeerd in 1cFresh en BSP) is ook bijzonder interessant. In vergelijking met een traditionele implementatiemodel, zijn de vereisten voor procesautomatisering hier aanzienlijk hoger. Er zijn tientallen dergelijke processen: het aanmaken van nieuwe datasets (\"appartementen\"), het bijwerken van applicaties, het actualiseren van normatieve informatie, back-ups, enzovoort. En natuurlijk stijgen de eisen voor betrouwbaarheid en beschikbaarheid. Bijvoorbeeld, om een betrouwbare interactie van toepassingen met de beheersystemen te waarborgen, hebben we een technologie voor asynchrone oproepsystemen met gegarandeerde bezorging ge\u00efmplementeerd. <\/p>\n

Een zeer subtiel punt is de manier waarop gegevens en processen worden gedeeld. Het lijkt misschien eenvoudig (voor degenen die dat denken) bij eerste aanblik. De grootste uitdaging is het vinden van een balans tussen centralisatie van gegevens en processen en decentralisatie. Aan de ene kant vermindert centralisatie de kosten (schijfruimte, CPU-resources, de inspanningen van beheerders\u2026). Aan de andere kant beperkt het de vrijheid van de \"huurders\". Dit is precies een van de momenten van de \"splitsing\" van de applicatie, waarbij de ontwikkelaar tegelijkertijd moet nadenken over de applicatie in enge zin (die \u00e9\u00e9n \"appartement\" bedient) en in brede zin (die alle \"huurders\" bedient). <\/p>\n

Een voorbeeld van zo'n \"dilemma\" is normatieve en referentie-informatie. Uiteraard is de verleiding groot om deze gemeenschappelijk te maken voor alle \"huurders\" van het gebouw. Dit maakt het mogelijk om het in \u00e9\u00e9n exemplaar op te slaan en het onmiddellijk voor iedereen bij te werken. Maar soms heeft een bepaalde huurder specifieke aanpassingen nodig. Vreemd genoeg komt dit in de praktijk voor, zelfs voor informatie die door regelgevers (overheidsinstanties) is gespecificeerd. Dit leidt tot een complexe vraag: moeten we delen of niet? Natuurlijk is het verleidelijk om algemene informatie voor iedereen en specifieke informatie voor degenen die dat willen te cre\u00ebren. Maar dat leidt tot een zeer complexe implementatie. Daar werken we aan... <\/p>\n

Een ander voorbeeld is het ontwerpen van de implementatie van reguliere processen (uitgevoerd volgens een schema, ge\u00efnitieerd door het beheersysteem, enz.). Aan de ene kant kunnen ze voor elk gegevensgebied afzonderlijk worden ge\u00efmplementeerd. Dit is eenvoudiger en handiger. Maar aan de andere kant cre\u00ebert zo'n fijne granulariteit een grote belasting voor het systeem. Om de belasting te verlagen, moeten gemeenschappelijke processen worden ge\u00efmplementeerd. Maar deze vereisen een zorgvuldiger uitwerking. <\/p>\n

Er rijst vanzelfsprekend een belangrijke vraag. Hoe kunnen applicatieontwikkelaars multitenancy implementeren? Wat moeten ze hiervoor doen? Natuurlijk streven we ernaar dat de lasten van technische en infrastructuurkwesties zoveel mogelijk op de schouders van de geleverde technologie komen te liggen, terwijl de applicatieontwikkelaar zich alleen bezighoudt met businesslogica. Maar net als bij andere belangrijke architecturale kwesties, is het nodig dat applicatieontwikkelaars enige kennis hebben van hoe multitenancy werkt en dat er inspanningen vereist zijn bij de ontwikkeling van applicaties. Waarom? Omdat er zaken zijn die de technologie niet automatisch kan waarborgen zonder rekening te houden met de semantiek van gegevens. Bijvoorbeeld het bepalen van de grenzen van informatieverdeling. Maar we proberen ervoor te zorgen dat deze complicaties minimaal zijn. Er zijn al voorbeelden van dergelijke applicaties. <\/p>\n

Een belangrijk aspect in de context van multitenancy-implementatie in '1C:Enterprise' is dat we een hybride model cre\u00ebren waarin \u00e9\u00e9n applicatie zowel in multitenancy-modus als in normale modus kan werken. Dit is een vrij complexe taak en vereist afzonderlijke bespreking.
\n
Bron: 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\udd47Over multitenancy | ProHoster","description":"Helaas heeft dit begrip geen goede Nederlandse equivalent.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/pro-multitenancy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/55231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=55231"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/55231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/55232"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=55231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=55231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=55231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}