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

Sfortunatamente, questo termine non ha un buon equivalente in russo. \u00abWikipedia\u00bb fornisce traduzione<\/a><\/noindex> \u00abmulti-affitto, affitto multiplo\u00bb. A volte \u00e8 chiamato \u00abpropriet\u00e0 multipla\u00bb. Questi termini possono creare un po' di confusione, poich\u00e9 l'argomento non \u00e8 essenzialmente legato all'affitto o alla propriet\u00e0. Si tratta di un problema strettamente legato all'architettura del software e all'organizzazione del suo utilizzo. E quest'ultimo aspetto \u00e8 altrettanto importante. <\/p>\n

Abbiamo iniziato a formare la nostra comprensione del multitenancy contemporaneamente all'inizio della progettazione del nostro approccio al modello di lavoro cloud (servizi) di \u00ab1C:Enterprise\u00bb. Questo \u00e8 accaduto alcuni anni fa. E da allora la nostra comprensione si \u00e8 ampliata costantemente. Scopriamo continuamente nuovi aspetti (vantaggi, svantaggi, complessit\u00e0, caratteristiche, ecc.) relativi a questo argomento. <\/p>\n

\"Sull'multitenancy\"
\n<\/a><\/noindex>
\nA volte, gli sviluppatori intendono per multitenancy un argomento abbastanza semplice: \u00abper memorizzare i dati di pi\u00f9 organizzazioni in un'unica base dati, \u00e8 necessario aggiungere a tutte le tabelle una colonna con l'identificatore dell'organizzazione e applicare un filtro su di essa\u00bb. Anche noi, naturalmente, abbiamo iniziato il nostro lavoro su questo argomento da questo punto. Ma abbiamo capito abbastanza rapidamente che si trattava solo di un aspetto (che, per inciso, non \u00e8 semplice). In realt\u00e0, \u00e8 \u00abun intero paese\u00bb. <\/p>\n

L'idea principale del multitenancy pu\u00f2 essere descritta pi\u00f9 o meno cos\u00ec. Un'applicazione normale \u00e8 un cottage progettato per una sola famiglia, che utilizza la sua infrastruttura (pareti, tetto, fornitura d'acqua, riscaldamento, ecc.). Un'applicazione multitenancy \u00e8 un condominio. In essa, ogni famiglia utilizza la stessa infrastruttura, ma l'infrastruttura \u00e8 realizzata per l'intero edificio. <\/p>\n

E l'approccio multitenancy \u00e8 positivo o negativo? Si possono trovare opinioni molto diverse su questo. Sembra che non ci sia un \u00abbuono o cattivo\u00bb in generale. \u00c8 necessario confrontare vantaggi e svantaggi nel contesto dei compiti specifici da risolvere. Ma questo \u00e8 un argomento a parte... <\/p>\n

Nel senso pi\u00f9 semplice, l'obiettivo del multitenancy \u00e8 ridurre i costi di supporto dell'applicazione attraverso la \u00absocializzazione\u00bb dei costi per l'infrastruttura. \u00c8 un movimento simile alla riduzione dei costi dell'applicazione tramite l'uso di una soluzione standard (forse con personalizzazioni e modifiche), invece di scrivere \u00absu misura\u00bb. Solo in un caso la progettazione \u00e8 socializzata, mentre nell'altro \u00e8 l'operativit\u00e0. <\/p>\n

Inoltre, ripetiamo, qui non c'\u00e8 un legame diretto con il metodo di vendita. L'architettura multitenancy pu\u00f2 essere applicata anche nelle infrastrutture IT aziendali o governative per automatizzare un gran numero di filiali simili e imprese del gruppo. <\/p>\n

Si pu\u00f2 dire che il multitenancy non sia solo una questione di organizzazione della memorizzazione dei dati. \u00c8 un modello di funzionamento dell'applicazione nel suo complesso (inclusi aspetti significativi della sua architettura, modello di distribuzione e organizzazione della manutenzione). <\/p>\n

La cosa pi\u00f9 complessa e interessante del modello multitenancy, a nostro avviso, \u00e8 che l'essenza dell'applicazione si \"duplica\". Una parte delle funzionalit\u00e0 lavora con aree di dati specifiche (appartamenti) e \"non si interessa\" a ci\u00f2 che avviene nei vari appartamenti. L'altra parte percepisce l'intero edificio e lavora immediatamente per tutti gli inquilini. Tuttavia, quest'ultima non pu\u00f2 astrarsi dal fatto che si tratta comunque di appartamenti separati, e \u00e8 necessario garantire il livello appropriato di granularit\u00e0 e sicurezza. <\/p>\n

Nel \"1C:Enterprise\" il modello multitenancy viene realizzato a livello di diverse tecnologie. Questi sono i meccanismi della piattaforma \"1C:Enterprise\", i meccanismi di1C:Technology di pubblicazione delle soluzioni 1cFresh<\/a><\/noindex>\" e \"1C:Technology di sviluppo delle soluzioni 1cFresh<\/a><\/noindex>\", meccanismi BSP<\/a><\/noindex> (librerie di sottosistemi standard). <\/p>\n

Ognuno di questi elementi contribuisce alla costruzione dell'infrastruttura complessiva di un condominio. Perch\u00e9 viene implementato in diverse tecnologie anzich\u00e9 in una sola, ad esempio nella piattaforma? Prima di tutto perch\u00e9 alcuni meccanismi, a nostro avviso, possono essere modificati in modo appropriato in base al particolare scenario di distribuzione. Ma in generale si tratta di una questione complessa, e ci troviamo costantemente di fronte alla scelta \u2013 a quale livello sia meglio implementare un certo aspetto del multitenancy. <\/p>\n

\u00c8 evidente che la parte fondamentale dei meccanismi doveva essere realizzata nella piattaforma. Per esempio, la suddivisione dei dati. Ci\u00f2 da cui di solito inizia la conversazione sul multitenancy. Ma alla fine, il modello multitenancy ha \"colpito\" una parte significativa dei meccanismi della piattaforma e ne ha richiesto il miglioramento, e in alcuni casi anche una ripensamento. <\/p>\n

A livello di piattaforma abbiamo implementato proprio i meccanismi di base. Questi consentono di creare applicazioni che funzionano nel modello di multitenancy. Ma affinch\u00e9 le applicazioni \"vivano e funzionino\" in questo modello, \u00e8 necessario avere un sistema di gestione della loro \"vita operativa\". A questo si occupano le tecnologie 1cFresh e il layer unificato di logica aziendale a livello di B\u0421\u041f. Proprio come un condominio fornisce ai residenti tutto il necessario, cos\u00ec le tecnologie 1cFresh forniscono tutto ci\u00f2 di cui hanno bisogno le applicazioni che operano nel modello di multitenancy. E affinch\u00e9 le applicazioni possano interagire con questa infrastruttura (senza sostanziali modifiche), vengono inseriti i corrispondenti \"innesti\" sotto forma di sottosistemi B\u0421\u041f. <\/p>\n

Dal punto di vista dei meccanismi della piattaforma \u00e8 facile notare che man mano che acquisiamo esperienza e sviluppiamo l'opzione di utilizzo nel cloud di \"1C:Enterprise\" espandiamo la gamma di meccanismi coinvolti in questa architettura. Facciamo un esempio. Nel modello di multitenancy cambia significativamente la distribuzione dei ruoli tra i partecipanti alla gestione delle applicazioni. Aumenta notevolmente il ruolo (livello di responsabilit\u00e0) di coloro che sono incaricati dell'operativit\u00e0 delle applicazioni. \u00c8 diventato necessario per loro avere strumenti di controllo delle applicazioni pi\u00f9 potenti. Questo perch\u00e9 gli utenti delle applicazioni (residenti) si fidano innanzitutto del fornitore con cui lavorano. Per questo motivo abbiamo implementato nella versione 8.3 un nuovo meccanismo di profili di sicurezza<\/a><\/noindex>. Questo meccanismo consente agli amministratori del fornitore di limitare la libert\u00e0 dei programmatori di applicazioni al livello di sicurezza necessario - in sostanza, isola il funzionamento dell'applicazione per ogni residente all'interno di specifici confini di \"sandbox\". <\/p>\n

Un interesse notevole \u00e8 rappresentato dall'architettura per la gestione delle applicazioni che operano in modalit\u00e0 multitenancy (ci\u00f2 che viene realizzato nelle tecnologie 1cFresh e BSP). Qui, rispetto al modello di distribuzione tradizionale, aumentano in modo significativo i requisiti per l'automazione dei processi di gestione. A tali processi si aggiungono decine: creazione di nuove aree di dati (\u00abappartamenti\u00bb), aggiornamento delle applicazioni, aggiornamento delle informazioni normative, backup, ecc. E, naturalmente, aumentano i requisiti per il livello di affidabilit\u00e0 e disponibilit\u00e0. Ad esempio, per garantire un'interazione affidabile tra le applicazioni e i componenti del sistema di gestione, abbiamo implementato una tecnologia di sistema di chiamata asincrona con consegna garantita. <\/p>\n

Un aspetto molto delicato \u00e8 il modo di condividere dati e processi. A prima vista potrebbe sembrare semplice (se a qualcuno sembra). La maggiore complessit\u00e0 sta nel bilancio tra centralizzazione di dati e processi e decentralizzazione. Da un lato, la centralizzazione consente di ridurre i costi (spazio su disco, risorse del processore, sforzi degli amministratori\u2026). Dall'altro lato, limita la libert\u00e0 degli \u00ababitanti\u00bb. Questo \u00e8 esattamente uno dei momenti di \u00abdivisione\u00bb dell'applicazione, quando il programmatore deve pensare contemporaneamente all'applicazione in senso stretto (che serve un \u00abappartamento\u00bb) e in senso lato (che serve tutti gli \u00ababitanti\u00bb). <\/p>\n

Un esempio di tale \u00abdilemma\u00bb pu\u00f2 essere rappresentato dalle informazioni normative e di riferimento. \u00c8 comprensibile che ci sia una forte tentazione di renderle comuni a tutti gli \u00ababitanti\u00bb della casa. Ci\u00f2 consente di conservarle in un unico esemplare e aggiornarle contemporaneamente per tutti. Ma pu\u00f2 capitare che un abitante abbia bisogno di modifiche specifiche. Stranamente, ma nella pratica questo accade, anche per le informazioni specificate dai regolatori (enti pubblici). Ne deriva una questione complessa: condividere o non condividere? \u00c8 certamente allettante creare informazioni comuni per tutti e private per chi desidera. Ma questo porta a una realizzazione tutt'altro che semplice. Ma su questo stiamo lavorando... <\/p>\n

Un altro esempio \u00e8 la progettazione dell'implementazione di processi regolari (eseguiti secondo un programma, avviati dal sistema di gestione, ecc.). Da un lato, possono essere implementati per ciascun dominio di dati separatamente. \u00c8 pi\u00f9 semplice e conveniente. Dall'altra parte, una granularit\u00e0 cos\u00ec fine crea un grande carico sul sistema. Per ridurre il carico, \u00e8 necessario implementare processi condivisi. Ma questi richiedono una pianificazione pi\u00f9 attenta. <\/p>\n

Naturalmente, si pone una questione molto significativa. Come possono gli sviluppatori di applicazioni garantire il funzionamento in modalit\u00e0 multitenancy? Cosa devono fare al riguardo? Certamente, miriamo a far s\u00ec che il peso delle questioni tecnologiche e infrastrutturali ricada il pi\u00f9 possibile sulle spalle della tecnologia fornita, mentre lo sviluppatore dell'applicazione dovrebbe concentrarsi solo sugli aspetti della logica aziendale. Ma, come con altre questioni architettoniche importanti, \u00e8 necessario che gli sviluppatori di applicazioni abbiano una certa comprensione del funzionamento nel modello di multitenancy e che siano necessarie alcuni sforzi durante lo sviluppo delle applicazioni. Perch\u00e9? Perch\u00e9 ci sono aspetti che la tecnologia non pu\u00f2 garantire automaticamente senza considerare la semantica dei dati. Ad esempio, la definizione dei confini di condivisione delle informazioni. Ma ci impegniamo a mantenere queste complessit\u00e0 al minimo. Ci sono gi\u00e0 esempi di applicazioni implementate. <\/p>\n

Un aspetto importante nel contesto dell'implementazione del multitenancy in \"1\u0421:Enterprise\" \u00e8 che stiamo creando un modello ibrido, in cui un'applicazione pu\u00f2 funzionare sia in modalit\u00e0 multitenancy che in modalit\u00e0 normale. Questo \u00e8 un compito piuttosto difficile e merita una discussione separata.
\n
Fonte: 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\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\udd47Pro multitenancy | ProHoster","description":"Sfortunatamente, questo termine non ha un buon equivalente in russo.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pro-multitenancy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/55231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=55231"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/55231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/55232"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=55231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=55231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=55231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}