Sfortunatamente, questo termine non ha un buon analogo in lingua russa. Wikipedia dà "multi-locazione, locazione multipla." Questo è talvolta chiamato "proprietà multipla". Questi termini possono creare confusione, poiché l'argomento non è intrinsecamente associato né all'affitto né alla proprietà. Questa è una questione di architettura del software e organizzazione del suo funzionamento. E quest'ultimo non è meno importante.
Abbiamo iniziato a formulare la nostra comprensione della multitenancy nello stesso momento in cui abbiamo iniziato a progettare un approccio al modello di lavoro cloud (servizio) in 1C:Enterprise. Questo è successo diversi anni fa. E da allora la nostra comprensione si è continuamente ampliata. Scopriamo costantemente nuovi aspetti di questo argomento (pro, contro, difficoltà, caratteristiche, ecc.).
A volte gli sviluppatori considerano la multitenancy come un argomento molto semplice: "per poter archiviare i dati di più organizzazioni in un database, è necessario aggiungere una colonna con l'identificatore dell'organizzazione a tutte le tabelle e impostare un filtro su di essa". Naturalmente anche noi abbiamo cominciato a studiare la questione da questo momento. Ma si sono presto resi conto che si trattava solo di una radura (anche questa, tra l'altro, non facile). In generale, questo è un "intero paese".
L'idea di base della multilocazione può essere descritta in questo modo. Un'applicazione tipica è un cottage progettato per ospitare una famiglia, che utilizza le sue infrastrutture (muri, tetto, approvvigionamento idrico, riscaldamento, ecc.). Un'applicazione multilocazione è un condominio. In esso ogni famiglia utilizza la stessa infrastruttura, ma l'infrastruttura stessa è implementata per l'intera casa.
L’approccio multitenancy è buono o cattivo? Puoi trovare opinioni molto diverse a riguardo. Sembra che non esista affatto un “buono o cattivo”. È necessario confrontare i pro e i contro nel contesto dei compiti specifici da risolvere. Ma questo è un argomento a parte...
Nel suo senso più semplice, l'obiettivo della multitenancy è ridurre i costi di manutenzione di un'applicazione “socializzando” i costi dell'infrastruttura. Questo è lo stesso movimento di ridurre il costo di un’applicazione utilizzando una soluzione di produzione (possibilmente con personalizzazione e modifica), anziché scriverla “su ordinazione”. Solo in un caso lo sviluppo è socializzato e nell'altro lo sfruttamento.
Inoltre, lo ripetiamo, non esiste alcun collegamento diretto con la modalità di vendita. L'architettura multi-tenancy può essere utilizzata anche in un'infrastruttura IT aziendale o dipartimentale per automatizzare un gran numero di filiali e holding simili.
Possiamo dire che la multitenancy non è solo una questione di organizzazione dell’archiviazione dei dati. Si tratta di un modello di come funziona l'applicazione nel suo insieme (inclusa una parte significativa della sua architettura, del suo modello di distribuzione e della sua organizzazione di manutenzione).
La cosa più difficile e interessante del modello multitenancy, ci sembra, è che l’essenza dell’applicazione “si biforca”. Una parte della funzionalità funziona con aree dati specifiche (appartamenti) e “non è interessata” al fatto che ci siano residenti in altri appartamenti. E alcuni percepiscono la casa nel suo insieme e lavorano per tutti i residenti contemporaneamente. Allo stesso tempo, questi ultimi non possono ignorare il fatto che si tratta, in fondo, di appartamenti separati, ed è necessario garantire il necessario livello di granularità e sicurezza.
In 1C:Enterprise, il modello multitenancy è implementato a livello di diverse tecnologie. Questi sono i meccanismi della piattaforma 1C:Enterprise, i meccanismi di"E"", meccanismi (librerie di sottosistemi standard).
Ciascuno di questi elementi contribuisce alla costruzione dell'infrastruttura complessiva di un condominio. Perché questo è implementato in diverse tecnologie e non in una, ad esempio, in una piattaforma? Innanzitutto perché alcuni meccanismi, a nostro avviso, sono abbastanza appropriati da modificare per una specifica opzione di implementazione. Ma in generale, questa è una domanda difficile e siamo costantemente di fronte a una scelta: a quale livello è meglio implementare questo o quell'aspetto della multilocazione.
Ovviamente, la parte base dei meccanismi doveva essere implementata nella piattaforma. Bene, ad esempio, l'effettiva separazione dei dati. È qui che di solito si inizia a parlare di multitenancy. Ma alla fine, il modello multitenancy ha “viaggiato” attraverso una parte significativa dei meccanismi della piattaforma e ha richiesto il loro affinamento e, in alcuni casi, un ripensamento.
A livello di piattaforma, abbiamo implementato esattamente i meccanismi di base. Consentono di creare applicazioni eseguite in un modello multi-tenancy. Ma affinché le applicazioni “vivano e funzionino” in un modello del genere, è necessario disporre di un sistema per gestire le loro “attività della vita”. Ne sono responsabili le tecnologie 1cFresh e un livello di logica aziendale unificato a livello BSP. Proprio come in un condominio l’infrastruttura fornisce ai residenti tutto ciò di cui hanno bisogno, così le tecnologie 1cFresh forniscono tutto ciò di cui hanno bisogno per le applicazioni che funzionano in un modello multitenancy. E affinché le applicazioni possano interagire con questa infrastruttura (senza modifiche significative), i corrispondenti “connettori” vengono inseriti in esse sotto forma di sottosistemi BSP.
Dal punto di vista dei meccanismi della piattaforma, è facile notare che man mano che acquisiamo esperienza e sviluppiamo il caso d’uso del cloud “1C:Enterprise”, stiamo espandendo la composizione dei meccanismi coinvolti in questa architettura. Facciamo un esempio. Nel modello multi-tenancy, i ruoli dei partecipanti al servizio applicativo cambiano in modo significativo. Il ruolo (livello di responsabilità) dei responsabili delle applicazioni operative aumenta notevolmente. È diventato necessario per loro disporre di strumenti di controllo delle applicazioni più potenti. Perché gli utenti dell'applicazione (residenti) si fidano innanzitutto del provider con cui lavorano. Per fare ciò, abbiamo implementato un nuovo . Questo meccanismo consente agli amministratori dei provider di limitare la libertà degli sviluppatori di applicazioni al livello di sicurezza richiesto, in sostanza di isolare il funzionamento dell'applicazione per ciascun tenant all'interno di una determinata sandbox.
Non meno interessante è l'architettura per la gestione delle applicazioni operanti in modalità multitenancy (quella implementata nelle tecnologie 1cFresh e BSP). Qui, rispetto al modello di implementazione convenzionale, i requisiti per l’automazione dei processi di gestione sono notevolmente aumentati. Esistono dozzine di processi di questo tipo: creazione di nuove aree dati ("appartamenti"), aggiornamento di applicazioni, aggiornamento di informazioni normative, backup, ecc. E, naturalmente, i requisiti per il livello di affidabilità e disponibilità stanno aumentando. Ad esempio, per garantire un'interazione affidabile tra applicazioni e componenti del sistema di controllo, abbiamo implementato la tecnologia del sistema di chiamata asincrono con consegna garantita.
Un punto molto delicato è il modo di socializzare dati e processi. Sembra semplice (se lo sembra a qualcuno) solo a prima vista. La sfida più grande è l’equilibrio 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 dell'amministratore...). D’altro canto limita la libertà degli “inquilini”. Questo è esattamente uno dei momenti di "biforcazione" dell'applicazione, quando lo sviluppatore deve pensare contemporaneamente all'applicazione in senso stretto (servire un "appartamento") e in senso lato (servire tutti gli "inquilini" contemporaneamente) .
Come esempio di tale "dilemma" si possono citare le informazioni normative e di riferimento. Certo, è grande la tentazione di renderlo comune a tutti gli “inquilini” della casa. Ciò ti consente di archiviarlo in una copia e aggiornarlo per tutti contemporaneamente. Ma succede che alcuni residenti abbiano bisogno di cambiamenti specifici. Stranamente, in pratica ciò accade anche per le informazioni specificate dagli enti di regolamentazione (organismi governativi). Questa risulta essere una domanda difficile: socializzare o non socializzare? Naturalmente si è tentati di rendere le informazioni generali per tutti e private per coloro che le desiderano. E questo già porta ad un’implementazione molto difficile. Ma stiamo lavorando su questo...
Un altro esempio è la progettazione dell'implementazione di processi regolari (eseguiti secondo un programma, avviati dal sistema di controllo, ecc.). Da un lato possono essere realizzati separatamente per ciascuna area dati. È più facile e conveniente. Ma, d'altra parte, una granularità così fine crea un grande carico sul sistema. Per ridurre il carico, è necessario implementare processi socializzati. Ma richiedono uno studio più attento.
Naturalmente, ciò solleva una questione molto significativa. In che modo gli sviluppatori di applicazioni possono garantire la multitenancy? Cosa devono fare per questo? Naturalmente, ci sforziamo di garantire che il peso delle questioni tecnologiche e infrastrutturali ricada il più possibile sulle spalle della tecnologia fornita e lo sviluppatore dell'applicazione pensi solo in termini di compiti di logica aziendale. Ma come per altre importanti questioni architetturali, gli sviluppatori di applicazioni devono avere una certa conoscenza del funzionamento del modello multi-tenancy e sarà necessario un certo impegno durante lo sviluppo delle applicazioni. Perché? Perché ci sono punti che la tecnologia non può fornire automaticamente senza tenere conto della semantica dei dati. Ad esempio, la stessa definizione dei confini della socializzazione dell'informazione. Ma cerchiamo di mantenere queste difficoltà piccole. Esistono già esempi di implementazione di tali applicazioni.
Un punto importante nel contesto dell'implementazione della multitenancy in 1C:Enterprise è che stiamo creando un modello ibrido in cui un'applicazione può operare sia in modalità multitenancy che in modalità normale. Si tratta di un compito molto difficile e oggetto di una discussione separata.
Fonte: habr.com