{"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":"Sulla multitenancy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sfortunatamente, non esiste un buon equivalente in lingua russa per questo termine. Wikipedia fornisce traduzione<\/a><\/noindex> \u00abmulti-tenancy, affitto multiplo\u00bb. A volte viene definito \u00abpropriet\u00e0 multipla\u00bb. Questi termini possono essere un po' fuorvianti, poich\u00e9 l'argomento non \u00e8 in realt\u00e0 legato n\u00e9 all'affitto n\u00e9 alla propriet\u00e0. Si tratta di un tema legato all'architettura del software e alla sua gestione. Quest'ultima, tra l'altro, \u00e8 altrettanto importante. <\/p>\n

Abbiamo iniziato a formare la nostra comprensione del multitenancy mentre progettavamo l'approccio al modello di lavoro cloud (servizio) di \u00ab1C:Enterprise\u00bb. \u00c8 stata qualche anno fa. E da allora la nostra comprensione \u00e8 in continua espansione. Scopriamo costantemente nuovi aspetti (vantaggi, svantaggi, complessit\u00e0, peculiarit\u00e0, ecc.) di questo argomento. <\/p>\n

\"Sulla
\n<\/a><\/noindex>
\nA volte gli sviluppatori intendono per multitenancy un concetto piuttosto semplice: \u00abper conservare i dati di diverse organizzazioni in un unico database, \u00e8 necessario aggiungere una colonna con l'identificatore dell'organizzazione a tutte le tabelle e imporre un filtro su di essa\u00bb. Naturalmente, anche noi abbiamo iniziato la nostra indagine da questo punto. Tuttavia, ci siamo resi conto abbastanza rapidamente che questo \u00e8 solo un aspetto (anch'esso non semplice). In realt\u00e0, si tratta di un \u00abintero paese\u00bb. <\/p>\n

L'idea principale del multitenancy pu\u00f2 essere descritta all'incirca in questo modo. Un'applicazione normale \u00e8 una villa progettata per una sola famiglia, che utilizza la sua infrastruttura (pareti, tetto, approvvigionamento idrico, riscaldamento, ecc.). Un'applicazione multitenancy, invece, \u00e8 un condominio. In esso, ogni famiglia utilizza la stessa infrastruttura, ma quest'ultima \u00e8 realizzata per l'intero edificio. <\/p>\n

\u00c8 un approccio multitenancy buono o cattivo? Puoi trovare opinioni molto diverse su questo tema. Sembra che non ci sia un concetto di \u00abbuono o cattivo\u00bb in senso assoluto. Bisogna confrontare vantaggi e svantaggi nel contesto delle specifiche problematiche da risolvere. Ma questo \u00e8 un argomento separato\u2026 <\/p>\n

In termini semplici, l'obiettivo del multitenancy \u00e8 ridurre i costi di mantenimento dell'applicazione attraverso la \u00absocializzazione\u00bb delle spese per l'infrastruttura. \u00c8 un movimento simile a quello di abbattere i costi dell'applicazione attraverso soluzioni standardizzate (possibilmente con personalizzazioni e modifiche), piuttosto che attraverso uno sviluppo \u00absu misura\u00bb. In un caso, si socializza lo sviluppo, nell'altro la gestione. <\/p>\n

Dobbiamo ribadire che qui non c'\u00e8 un legame diretto con il metodo di vendita. L'architettura del multitenancy pu\u00f2 essere utilizzata anche nelle infrastrutture IT aziendali o dipartimentali per automatizzare un gran numero di filiali o imprese affiliate. <\/p>\n

Si pu\u00f2 dire che il multitenancy non \u00e8 semplicemente una questione di organizzazione della conservazione dei dati. \u00c8 un modello di funzionamento dell'applicazione nel suo complesso (compresa una parte significativa degli aspetti della sua architettura, del modello di distribuzione e dell'organizzazione della manutenzione). <\/p>\n

La cosa pi\u00f9 complessa e interessante del modello multitenancy, a nostro avviso, \u00e8 che l'essenza dell'applicazione viene \u00abscissa\u00bb. Parte della funzionalit\u00e0 lavora con aree dati specifiche (appartamenti) e \u00abnon si interessa\u00bb agli inquilini di altri appartamenti. Un'altra parte percepisce l'intero edificio e lavora contemporaneamente per tutti gli inquilini. Tuttavia, quest'ultima non pu\u00f2 astrarsi dal fatto che ci sono effettivamente appartamenti separati, e \u00e8 necessario garantire un livello di granularit\u00e0 e sicurezza adeguato. <\/p>\n

Nel \u00ab1C:Enterprise\u00bb, il modello multitenancy viene implementato a diversi livelli tecnologici. Ci sono meccanismi della piattaforma \u00ab1C:Enterprise\u00bb, meccanismi di1C:Technology for Publishing 1cFresh Solutions<\/a><\/noindex>\u00bb e \u00ab1C:Technology for Developing 1cFresh Solutions<\/a><\/noindex>\u00bb, meccanismi BSP<\/a><\/noindex> (librerie di sistemi standard). <\/p>\n

Ciascuno di questi aspetti contribuisce alla costruzione dell'infrastruttura complessiva del condominio. Perch\u00e9 realizzarlo tramite diverse tecnologie anzich\u00e9 in una sola, come la piattaforma? Principalmente perch\u00e9 una parte dei meccanismi, a nostro avviso, pu\u00f2 essere modificata in base alla specifica variante di distribuzione. Ma in termini generali, questo \u00e8 un argomento complesso e ci troviamo costantemente di fronte alla scelta del livello migliore per implementare un dato aspetto del multitenancy. <\/p>\n

\u00c8 evidente che la parte fondamentale dei meccanismi doveva essere implementata nella piattaforma. Ad esempio, la suddivisione dei dati in s\u00e9. \u00c8 solitamente da qui che si comincia a parlare di multitenancy. Tuttavia, alla fine il modello di multitenancy ha coinvolto una parte significativa dei meccanismi della piattaforma, richiedendo il loro miglioramento e, in alcuni casi, una revisione. <\/p>\n

A livello di piattaforma, abbiamo implementato i meccanismi di base. Questi consentono di creare applicazioni che operano secondo il modello multitenancy. Tuttavia, affinch\u00e9 le applicazioni 'vivano e funzionino' in questo modello, \u00e8 necessario avere un sistema di gestione della loro 'vita operativa'. Questo \u00e8 garantito dalle tecnologie 1cFresh e dal livello unificato della logica aziendale a livello di BSP. Cos\u00ec come in un condominio l'infrastruttura fornisce ai residenti tutto il necessario, le tecnologie 1cFresh forniscono tutto il necessario alle applicazioni che operano nel modello multitenancy. E affinch\u00e9 le applicazioni possano interagire con questa infrastruttura (senza dover apportare significativi miglioramenti), vengono inseriti i corrispondenti 'connettori' sotto forma di sottosistemi BSP. <\/p>\n

Dal punto di vista dei meccanismi della piattaforma, \u00e8 facile notare che man mano che acquisiamo esperienza e sviluppiamo l'uso cloud di '1C:Enterprise', ampliamo il insieme dei meccanismi coinvolti in questa architettura. Facciamo un esempio. Nel modello multitenancy cambia significativamente la distribuzione dei ruoli tra i partecipanti alla gestione delle applicazioni. Aumenta notevolmente il ruolo (il livello di responsabilit\u00e0) di coloro che si occupano dell'esercizio delle applicazioni. \u00c8 diventato necessario disporre di strumenti di controllo delle applicazioni pi\u00f9 potenti. Perch\u00e9 gli utenti delle applicazioni (residenti) si fidano prima di tutto del fornitore con cui lavorano. Per questo 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 degli sviluppatori di applicazioni al livello necessario di sicurezza \u2013 in sostanza, isolare il lavoro dell'applicazione per ogni residente all'interno di determinati limiti di una 'sandbox'. <\/p>\n

Anche l'architettura per la gestione delle applicazioni che operano in modalit\u00e0 multitenancy (ci\u00f2 che viene realizzato con le tecnologie 1cFresh e BSP) \u00e8 di grande interesse. Qui, rispetto al modello di distribuzione standard, aumentano notevolmente i requisiti per l'automazione dei processi di gestione. Questi processi sono decine: creazione di nuove aree dati ('appartamenti'), aggiornamento delle applicazioni, aggiornamento delle informazioni normative, backup, ecc. E, naturalmente, aumentano le esigenze riguardo al livello di affidabilit\u00e0 e disponibilit\u00e0. Ad esempio, per garantire una interazione affidabile delle applicazioni con i componenti del sistema di gestione, abbiamo implementato una tecnologia di sistema di chiamate asincrone con consegna garantita. <\/p>\n

Un aspetto molto delicato \u00e8 il modo di rendere comuni dati e processi. Sembra semplice (se a qualcuno sembra) solo a prima vista. La maggiore complessit\u00e0 sta nel bilanciare centralizzazione e decentralizzazione di dati e processi. Da un lato, la centralizzazione consente di ridurre i costi (spazio su disco, risorse di CPU, sforzi degli amministratori\u2026). Dall'altro, limita la libert\u00e0 dei 'residenti'. Questo \u00e8 proprio uno dei momenti di 'sdoppiamento' dell'applicazione, in cui lo sviluppatore deve pensare contemporaneamente all'applicazione in senso stretto (che serve un'unica 'appartamento') e in senso ampio (che serve tutti i 'residenti' contemporaneamente). <\/p>\n

Come esempio di tale 'dilemma', possiamo citare le informazioni normative e di riferimento. Naturalmente, c'\u00e8 una grande tentazione di renderle comuni per tutti i 'residenti' del palazzo. Questo consente di conservarle in un'unica copia e di aggiornarle immediatamente per tutti. Ma a volte un certo residente ha bisogno di modifiche specifiche. Stranamente, ma nella pratica ci\u00f2 accade, anche per informazioni che sono specificate dai regolatori (da enti governativi). Si pone cos\u00ec una questione complessa: rendere comuni o meno? \u00c8 sicuramente allettante fornire informazioni generali per tutti e private per quelli che ne hanno bisogno. Ma questo conduce a un'implementazione piuttosto complicata. Stiamo lavorando su questo\u2026 <\/p>\n

Un altro esempio \u00e8 la progettazione di processi regolari (eseguiti secondo un programma, avviati dal sistema di gestione, ecc.). Da un lato, \u00e8 possibile implementarle separatamente per ogni area dati. Questo \u00e8 pi\u00f9 semplice e conveniente. Dall'altro, una tale granularit\u00e0 fine crea un carico maggiore sul sistema. Per ridurre il carico, \u00e8 necessario implementare processi comunitari. Ma richiedono una pianificazione pi\u00f9 accurata. <\/p>\n

Ovviamente, sorge una domanda piuttosto rilevante. Come possono gli sviluppatori di applicazioni garantire il funzionamento in modalit\u00e0 multitenancy? Cosa devono fare al riguardo? Naturalmente, ci impegniamo a garantire che il peso delle questioni tecnologiche e infrastrutturali ricada il pi\u00f9 possibile sulla tecnologia fornita, mentre lo sviluppatore dell'applicazione dovrebbe concentrarsi solo sulle questioni di logica aziendale. Tuttavia, come per altre importanti questioni architettoniche, \u00e8 necessario che gli sviluppatori di applicazioni abbiano una certa comprensione del funzionamento della modalit\u00e0 multitenancy e che siano richiesti alcuni sforzi nello 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 stessa dei confini della condivisione delle informazioni. Ci sforziamo, per\u00f2, affinch\u00e9 queste complessit\u00e0 siano minime. Ci sono gi\u00e0 esempi di implementazione di tali applicazioni. <\/p>\n

Un aspetto importante nel contesto dell'implementazione della multitenancy in \u00ab1C:Enterprise\u00bb \u00e8 che stiamo creando un modello ibrido, in cui un'applicazione pu\u00f2 funzionare sia in modalit\u00e0 multitenancy che in modalit\u00e0 standard. Questo \u00e8 un compito piuttosto complesso e merita una discussione a parte.
\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\udd47Multitenancy | 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}]}}