Approcci architetturali per la messaggistica in soluzioni multi-tenant

  • Articolo

La messaggistica asincrona e la comunicazione basata su eventi sono asset critici quando si compila un'applicazione distribuita composta da diversi servizi interni ed esterni. Quando si progetta una soluzione multi-tenant, è fondamentale eseguire un'analisi preliminare per definire come condividere o partizionare messaggi relativi a tenant diversi.

La condivisione dello stesso sistema di messaggistica o dello stesso servizio di streaming di eventi può ridurre significativamente i costi operativi e la complessità di gestione. Tuttavia, l'uso di un sistema di messaggistica dedicato per ogni tenant offre un migliore isolamento dei dati, riduce il rischio di perdita di dati, elimina il problema Noisy Neighbor e consente di addebitare facilmente i costi di Azure ai tenant.

In questo articolo è possibile trovare una distinzione tra messaggi ed eventi e sono disponibili linee guida che gli architetti delle soluzioni possono seguire quando si decide quale approccio usare per un'infrastruttura di messaggistica o eventi in una soluzione multi-tenant.

Messaggi, punti dati ed eventi discreti

Tutti i sistemi di messaggistica hanno funzionalità simili, protocolli di trasporto e scenari di utilizzo. Ad esempio, la maggior parte dei sistemi di messaggistica moderni supporta comunicazioni asincrone che usano code volatili o persistenti, protocolli di trasporto AMQP e HTTPS, recapito di almeno una volta e così via. Tuttavia, esaminando in modo più approfondito il tipo di informazioni pubblicate e il modo in cui i dati vengono utilizzati ed elaborati dalle applicazioni client, è possibile distinguere tra diversi tipi di messaggi ed eventi. Esiste una distinzione essenziale tra i servizi che recapitano un evento e i sistemi che inviano un messaggio. Per ulteriori informazioni, vedi le seguenti risorse:

evento

Un evento è una notifica leggera di una condizione o di una modifica dello stato. Gli eventi possono essere unità discrete o parte di una serie. Gli eventi sono messaggi che in genere non comunicano l'intento di un editore diverso da quello di informare. Un evento acquisisce un fatto e lo comunica ad altri servizi o componenti. Un consumer dell'evento può elaborare l'evento perché lo soddisfa e non soddisfa le aspettative specifiche mantenute dall'editore. È possibile classificare gli eventi in due categorie principali:

  • Gli eventi discreti contengono informazioni su azioni specifiche eseguite dall'applicazione di pubblicazione. Quando si usa la comunicazione asincrona basata su eventi, un'applicazione pubblica un evento di notifica quando si verifica un evento all'interno del dominio. Una o più applicazioni che utilizzano devono essere consapevoli di questa modifica dello stato, ad esempio una variazione dei prezzi in un'applicazione del catalogo prodotti. I consumer sottoscrivono gli eventi per riceverli in modo asincrono. Quando si verifica un determinato evento, le applicazioni che utilizzano potrebbero aggiornare le entità di dominio, causando la pubblicazione di più eventi di integrazione.
  • Gli eventi di serie contengono punti dati informativi, ad esempio letture della temperatura dai dispositivi per l'analisi o le azioni degli utenti in una soluzione di analisi click, come elementi in un flusso continuo e continuo. Un flusso di eventi è correlato a un contesto specifico, ad esempio la temperatura o l'umidità segnalata da un dispositivo di campo. Tutti gli eventi correlati allo stesso contesto hanno un ordine temporale rigoroso che è importante durante l'elaborazione di questi eventi con un motore di elaborazione del flusso di eventi. L'analisi dei flussi di eventi che contengono punti dati richiede l'accumulo di questi eventi in un buffer che si estende su un intervallo di tempo desiderato. Oppure può trovarsi in un numero selezionato di elementi e quindi elaborarli usando una soluzione quasi in tempo reale o un algoritmo con training automatico. L'analisi di una serie di eventi può generare segnali, ad esempio la media di un valore misurato in un intervallo di tempo che supera una soglia. Questi segnali possono quindi essere generati come eventi discreti e interattivi.

Gli eventi discreti segnalano le modifiche dello stato e sono utilizzabili. Il payload dell'evento contiene informazioni su ciò che è accaduto, ma, in generale, non include i dati completi che hanno attivato l'evento. Ad esempio, un evento notifica ai consumer che un'applicazione di report ha creato un nuovo file in un account di archiviazione. Il payload dell'evento potrebbe avere informazioni generali sul file, ma non ha il file stesso. Gli eventi discreti sono ideali per le soluzioni serverless che devono essere ridimensionate.

Gli eventi di serie segnalano una condizione e sono analizzabili. Gli eventi discreti sono ordinati in base al tempo e correlati. In alcuni contesti, il consumer deve ricevere la sequenza completa di eventi per analizzare ciò che è accaduto e per eseguire l'azione necessaria.

Messaggi

I messaggi contengono dati non elaborati prodotti da un servizio da utilizzare o archiviare altrove. I messaggi spesso contengono informazioni necessarie per eseguire i passaggi in un flusso di lavoro o in una catena di elaborazione. Un esempio di questo tipo di comunicazione è il modello di comando. Il server di pubblicazione può anche prevedere che i ricevitori di un messaggio eseseguono una serie di azioni e segnalano il risultato dell'elaborazione con un messaggio asincrono. Esiste un contratto tra il server di pubblicazione dei messaggi e i ricevitori di messaggi. Ad esempio, l'autore invia un messaggio con alcuni dati non elaborati e prevede che il consumer crei un file da tali dati e invii un messaggio di risposta al termine. In altre situazioni, un processo del mittente potrebbe inviare un messaggio asincrono unidirezionale per chiedere a un altro servizio di eseguire una determinata operazione, ma senza aspettarsi di ottenere un messaggio di conferma o di risposta da esso.

Questo tipo di gestione dei messaggi contrattuali è molto diverso da un editore che pubblica eventi discreti a un pubblico di agenti consumer, senza alcuna previsione specifica di come gestiranno queste notifiche.

Scenari di esempio

Di seguito è riportato un elenco di alcuni scenari multi-tenant di esempio per messaggi, punti dati ed eventi discreti:

  • Eventi discreti:
    • Una piattaforma di condivisione musicale tiene traccia del fatto che un utente specifico in un tenant specifico ha ascoltato una determinata traccia musicale.
    • In un'applicazione Web dello store online, l'applicazione del catalogo invia un evento usando il modello Publisher-Subscriber ad altre applicazioni per notificare che è stato modificato un prezzo dell'articolo.
    • Un'azienda manifatturiera inserisce informazioni in tempo reale ai clienti e terze parti sulla manutenzione delle apparecchiature, sull'integrità dei sistemi e sugli aggiornamenti dei contratti.
  • Punti dati:
    • Un sistema di controllo della compilazione riceve eventi di telemetria, ad esempio letture di temperatura o umidità da sensori appartenenti a più clienti.
    • Un sistema di monitoraggio basato su eventi riceve ed elabora i log di diagnostica in modo quasi in tempo reale da più servizi, ad esempio i server Web.
    • Uno script sul lato client in una pagina Web raccoglie le azioni dell'utente e le invia a una soluzione di analisi click.
  • Messaggi:
    • Un'applicazione finanziaria B2B riceve un messaggio per iniziare a elaborare i record bancari di un tenant.
    • Un flusso di lavoro a esecuzione prolungata riceve un messaggio che attiva l'esecuzione del passaggio successivo.
    • L'applicazione basket di un'applicazione di archivio online invia un comando CreateOrder usando un messaggio asincrono e permanente all'applicazione di ordinamento.

Considerazioni e requisiti principali

Il modello di distribuzione e tenancy scelto per la soluzione ha un impatto profondo sulla sicurezza, sulle prestazioni, sull'isolamento dei dati, sulla gestione e sulla possibilità di eseguire il cross-charge dei costi delle risorse ai tenant. Questa analisi include il modello selezionato per la messaggistica e l'infrastruttura di eventi. In questa sezione vengono esaminate alcune delle decisioni chiave da prendere quando si pianifica un sistema di messaggistica nella soluzione multi-tenant.

Ridimensiona

Il numero di tenant, la complessità dei flussi di messaggi e dei flussi di eventi, il volume di messaggi, il profilo di traffico previsto e il livello di isolamento devono guidare le decisioni durante la pianificazione di un'infrastruttura di messaggistica o di eventi.

Il primo passaggio consiste nell'eseguire una pianificazione completa della capacità e stabilire la capacità massima necessaria per un sistema di messaggistica in termini di velocità effettiva per gestire correttamente il volume previsto di messaggi in caso di traffico normale o di picco.

Alcune offerte di servizio, ad esempio il livello Bus di servizio di Azure Premium, forniscono l'isolamento delle risorse a livello di CPU e memoria in modo che ogni carico di lavoro del cliente venga eseguito in isolamento. Questo contenitore di risorse viene chiamato unità di messaggistica. Ad ogni spazio dei nomi Premium viene allocata almeno un'unità di messaggistica. È possibile acquistare 1, 2, 4, 8 o 16 unità di messaggistica per ogni spazio dei nomi Premium bus di servizio. Un singolo carico di lavoro o entità può estendersi su più unità di messaggistica ed è possibile modificare il numero di unità di messaggistica in base alle esigenze. Il risultato è un risultato prevedibile e ripetibile per la soluzione basata su bus di servizio. Per altre informazioni, vedere bus di servizio livelli di messaggistica Premium e Standard. Analogamente, Hub eventi di Azure piani tariffari consentono di ridimensionare lo spazio dei nomi, in base al volume previsto di eventi in ingresso e in uscita. Ad esempio, l'offerta Premium viene fatturata dalle unità di elaborazione (PU), che corrispondono a una condivisione di risorse isolate (CPU, memoria e archiviazione) nell'infrastruttura sottostante. L'inserimento effettivo e la velocità effettiva del flusso per pu dipenderanno dai fattori seguenti:

  • Numero di produttori e consumatori
  • Dimensioni del payload
  • Numero di partizioni
  • Frequenza delle richieste in uscita
  • Utilizzo dell'acquisizione di Hub eventi, del Registro schemi e di altre funzionalità avanzate

Per altre informazioni, vedere Panoramica di Hub eventi Premium.

Quando la soluzione gestisce un numero considerevole di tenant e si decide di adottare un sistema di messaggistica separato per ogni tenant, è necessario disporre di una strategia coerente per automatizzare la distribuzione, il monitoraggio, gli avvisi e il ridimensionamento di ogni infrastruttura, separatamente l'uno dall'altro.

Ad esempio, un sistema di messaggistica per un determinato tenant può essere distribuito durante il processo di provisioning usando uno strumento di infrastruttura come codice (IaC), ad esempio un modello JSON Terraform, Bicep o Azure Resource Manager (ARM) e un sistema DevOps come Azure DevOps o GitHub Actions. Per altre informazioni, vedere Approcci architetturali per la distribuzione e la configurazione di soluzioni multi-tenant.

Il sistema di messaggistica può essere ridimensionato con una velocità effettiva massima nei messaggi per unità di tempo. Se il sistema supporta la scalabilità automatica dinamica, la capacità potrebbe essere aumentata o ridotta automaticamente, in base alle condizioni e alle metriche del traffico per soddisfare il contratto di servizio previsto.

Prevedibilità e affidabilità delle prestazioni

Quando si progetta e si crea un sistema di messaggistica per un numero limitato di tenant, l'uso di un singolo sistema di messaggistica può essere una soluzione eccellente per soddisfare i requisiti funzionali, in termini di velocità effettiva e potrebbe ridurre il costo totale di proprietà. Un'applicazione multi-tenant può condividere le stesse entità di messaggistica, ad esempio code e argomenti tra più clienti. In alternativa, è possibile usare un set dedicato di componenti per ognuno, per aumentare l'isolamento del tenant. D'altra parte, la condivisione della stessa infrastruttura di messaggistica tra più tenant potrebbe esporre l'intera soluzione al problema Noisy Neighbor. L'attività di un tenant potrebbe danneggiare altri tenant, in termini di prestazioni e operabilità.

In questo caso, il sistema di messaggistica deve essere ridimensionato correttamente per sostenere il carico del traffico previsto durante il picco. Idealmente, dovrebbe supportare la scalabilità automatica. Il sistema di messaggistica deve aumentare dinamicamente il numero di istanze quando il traffico aumenta e aumenta quando il traffico diminuisce. Un sistema di messaggistica dedicato per ogni tenant potrebbe anche ridurre il rischio Noisy Neighbor, ma la gestione di un numero elevato di sistemi di messaggistica potrebbe aumentare la complessità della soluzione.

Un'applicazione multi-tenant può infine adottare un approccio ibrido, in cui i servizi di base usano lo stesso set di code e argomenti in un unico sistema di messaggistica condivisa, per implementare comunicazioni interne e asincrone. Al contrario, altri servizi potrebbero adottare un gruppo dedicato di entità di messaggistica o anche un sistema di messaggistica dedicato, per ogni tenant per attenuare il problema Noisy Neighbor e garantire l'isolamento dei dati.

Quando si distribuisce un sistema di messaggistica nelle macchine virtuali, è necessario co-individuare queste macchine virtuali con le risorse di calcolo per ridurre la latenza di rete. Queste macchine virtuali non devono essere condivise con altri servizi o applicazioni, per evitare l'infrastruttura di messaggistica per competere per le risorse di sistema, ad esempio CPU, memoria e larghezza di banda di rete con altri sistemi. Le macchine virtuali possono anche essere distribuite tra le zone di disponibilità, per aumentare la resilienza e l'affidabilità all'interno dell'area dei carichi di lavoro critici dell'azienda, inclusi i sistemi di messaggistica. Si supponga di decidere di ospitare un sistema di messaggistica, ad esempio RabbitMQ o Apache ActiveMQ, nelle macchine virtuali. In tal caso, è consigliabile distribuirlo in un set di scalabilità di macchine virtuali e configurarlo per la scalabilità automatica, in base a metriche come CPU o memoria. In questo modo, il numero di nodi agente che ospitano il sistema di messaggistica aumenta e aumenta correttamente il numero di istanze, in base alle condizioni del traffico. Per altre informazioni, vedere Panoramica della scalabilità automatica con i set di scalabilità di macchine virtuali di Azure.

Analogamente, quando si ospita il sistema di messaggistica in un cluster Kubernetes, prendere in considerazione l'uso di selettori di nodo e taints per pianificare l'esecuzione dei pod in un pool di nodi dedicato, non condiviso con altri carichi di lavoro, per evitare il problema Noisy Neighbor. Quando si distribuisce un sistema di messaggistica in un cluster del servizio Azure Kubernetes con ridondanza della zona, usare i vincoli di distribuzione della topologia pod per controllare la distribuzione dei pod nel cluster del servizio Azure Kubernetes tra domini di errore, ad esempio aree, zone di disponibilità e nodi. Quando si ospita un sistema di messaggistica di terze parti nel servizio Azure Kubernetes, usare la scalabilità automatica di Kubernetes per aumentare in modo dinamico il numero di nodi di lavoro quando il traffico aumenta. Con la scalabilità automatica orizzontale dei pod e il ridimensionamento automatico del cluster del servizio Azure Kubernetes, i volumi dei nodi e dei pod vengono regolati in modo dinamico in tempo reale, in base alla condizione del traffico e per evitare tempi di inattività causati da problemi di capacità. Per altre informazioni, vedere Ridimensionare automaticamente un cluster per soddisfare le richieste delle applicazioni nel servizio Azure Kubernetes. Prendere in considerazione l'uso della scalabilità automatica basata su pari di Kubernetes (KEDA), se si vuole aumentare il numero di pod di un sistema di messaggistica ospitato in Kubernetes, ad esempio RabbitMQ o Apache ActiveMQ, in base alla lunghezza di una determinata coda. Con KEDA è possibile gestire il ridimensionamento di qualsiasi contenitore in Kubernetes, in base al numero di eventi che devono essere elaborati. Ad esempio, è possibile usare KEDA per ridimensionare le applicazioni in base alla lunghezza di una coda bus di servizio di Azure, di una coda RabbitMQ o a una coda ActiveMQ. Per altre informazioni su KEDA, vedere Scalabilità automatica guidata dagli eventi di Kubernetes.

Isolamento

Quando si progetta il sistema di messaggistica per una soluzione multi-tenant, è consigliabile considerare che diversi tipi di applicazioni richiedono un tipo di isolamento diverso, basato sui requisiti di prestazioni, privacy e controllo dei tenant.

  • Più tenant possono condividere le stesse entità di messaggistica, ad esempio code, argomenti e sottoscrizioni, nello stesso sistema di messaggistica. Ad esempio, un'applicazione multi-tenant potrebbe ricevere messaggi che contengono dati per più tenant, da una singola coda bus di servizio di Azure. Questa soluzione può causare problemi di prestazioni e scalabilità. Se alcuni tenant generano un volume maggiore di ordini rispetto ad altri, questo potrebbe causare un backlog di messaggi. Questo problema, noto anche come problema Noisy Neighbor, può degradare il contratto di servizio in termini di latenza per alcuni tenant. Il problema è più evidente se l'applicazione consumer legge ed elabora i messaggi dalla coda, uno alla volta, in ordine cronologico rigoroso e se il tempo necessario per elaborare un messaggio dipende dal numero di elementi nel payload. Quando si condividono una o più risorse di coda tra più tenant, l'infrastruttura di messaggistica e i sistemi di elaborazione devono essere in grado di soddisfare il traffico previsto basato sui requisiti di scalabilità e velocità effettiva. Questo approccio architetturale è particolarmente adatto in questi scenari in cui una soluzione multi-tenant adotta un singolo pool di processi di lavoro, per ricevere, elaborare e inviare messaggi per tutti i tenant.
  • Più tenant condividono lo stesso sistema di messaggistica, ma usano risorse diverse per argomenti o code. Questo approccio offre maggiore isolamento e protezione dei dati a un costo più elevato, maggiore complessità operativa e maggiore agilità perché gli amministratori di sistema devono effettuare il provisioning, monitorare e gestire un numero più elevato di risorse della coda. Questa soluzione garantisce un'esperienza coerente e prevedibile per tutti i tenant, in termini di prestazioni e contratti di servizio, in quanto impedisce a qualsiasi tenant di creare un collo di bottiglia che può influire sugli altri tenant.
  • Per ogni tenant viene usato un sistema di messaggistica dedicato separato. Ad esempio, una soluzione multi-tenant può usare uno spazio dei nomi bus di servizio di Azure distinto per ogni tenant. Questa soluzione offre il grado massimo di isolamento, a un costo più elevato di complessità e operatività. Questo approccio garantisce prestazioni coerenti e consente di ottimizzare il sistema di messaggistica, in base a specifiche esigenze del tenant. Quando viene eseguito l'onboarding di un nuovo tenant, oltre a un sistema di messaggistica completamente dedicato, l'applicazione di provisioning potrebbe anche dover creare un'identità gestita separata o un'entità servizio con le autorizzazioni di controllo degli accessi in base al ruolo appropriate per accedere allo spazio dei nomi appena creato. Ad esempio, quando un cluster Kubernetes viene condiviso da più istanze della stessa applicazione SaaS, una per ogni tenant e ognuna in esecuzione in uno spazio dei nomi separato, ogni istanza dell'applicazione può usare un'entità servizio diversa o un'identità gestita per accedere a un sistema di messaggistica dedicato. In questo contesto, il sistema di messaggistica potrebbe essere un servizio PaaS completamente gestito, ad esempio uno spazio dei nomi bus di servizio di Azure o un sistema di messaggistica ospitato in Kubernetes, ad esempio RabbitMQ. Quando si elimina un tenant dal sistema, l'applicazione deve rimuovere il sistema di messaggistica e qualsiasi risorsa dedicata creata in precedenza per il tenant. Lo svantaggio principale di questo approccio è che aumenta la complessità operativa e riduce l'agilità, soprattutto quando il numero di tenant aumenta nel tempo.

Esaminare le considerazioni e le osservazioni aggiuntive seguenti:

  • Se i tenant devono usare la propria chiave per crittografare e decrittografare i messaggi, una soluzione multi-tenant deve fornire la possibilità di adottare uno spazio dei nomi bus di servizio di Azure Premium separato per ogni tenant. Per altre informazioni, vedere Configurare chiavi gestite dal cliente per la crittografia dei dati bus di servizio di Azure inattivi.
  • Se i tenant necessitano di un livello elevato di resilienza e continuità aziendale, una soluzione multi-tenant deve offrire la possibilità di effettuare il provisioning di uno spazio dei nomi premium bus di servizio con il ripristino di emergenza geografico e le zone di disponibilità abilitate. Per altre informazioni, vedere Ripristino di emergenza geografico per il bus di servizio di Azure.
  • Quando si usano risorse code separate o un sistema di messaggistica dedicato per ogni tenant, è ragionevole adottare un pool separato di processi di lavoro, per ognuno di essi aumentare il livello di isolamento dei dati e ridurre la complessità di gestione di più entità di messaggistica. Ogni istanza del sistema di elaborazione può adottare credenziali diverse, ad esempio un stringa di connessione, un'entità servizio o un'identità gestita, per accedere al sistema di messaggistica dedicato. Questo approccio offre un livello di sicurezza e un isolamento migliori tra i tenant, ma richiede una maggiore complessità nella gestione delle identità.

Analogamente, un'applicazione guidata dagli eventi può fornire diversi livelli di isolamento:

  • Un'applicazione guidata dagli eventi riceve eventi da più tenant, tramite una singola istanza di Hub eventi di Azure condivisa. Questa soluzione offre un livello elevato di agilità, perché l'onboarding di un nuovo tenant non richiede la creazione di una risorsa di inserimento di eventi dedicata, ma offre un livello di protezione dei dati basso, poiché inter-mingles i messaggi di più tenant nella stessa struttura di dati.
  • I tenant possono scegliere un hub eventi dedicato o un argomento Kafka per evitare il problema Noisy Neighbor e soddisfare i requisiti di isolamento dei dati, quando gli eventi non devono essere associati a quelli di altri tenant, per la sicurezza e la protezione dei dati.
  • Se i tenant necessitano di un livello elevato di resilienza e continuità aziendale, un multi-tenant deve fornire la possibilità di effettuare il provisioning di uno spazio dei nomi Premium di Hub eventi, con il ripristino di emergenza geografico e le zone di disponibilità abilitate. Per altre informazioni, vedere Hub eventi di Azure - Ripristino di emergenza geografico.
  • Hub eventi dedicati, con acquisizione di Hub eventi abilitato, deve essere creato per i clienti che devono archiviare gli eventi in un account Archiviazione di Azure, per motivi di conformità e obblighi normativi. Per altre informazioni, vedere Acquisire eventi tramite Hub eventi di Azure in Archiviazione BLOB di Azure o Azure Data Lake Storage.
  • Una singola applicazione multi-tenant può inviare notifiche a più sistemi interni ed esterni usando Griglia di eventi di Azure. In questo caso, deve essere creata una sottoscrizione di Griglia di eventi separata per ogni applicazione consumer. Se l'applicazione usa più istanze di Griglia di eventi per inviare notifiche a un numero elevato di organizzazioni esterne, è consigliabile usare domini eventi, che consentono a un'applicazione di pubblicare eventi in migliaia di argomenti, ad esempio uno per ogni tenant. Per altre informazioni, vedere Informazioni sui domini eventi per la gestione degli argomenti di Griglia di eventi.

Complessità dell'implementazione

Quando si progetta una soluzione multi-tenant, è essenziale considerare il modo in cui il sistema si evolverà a medio-lungo termine, per evitare che la complessità aumenti nel tempo, fino a quando non è necessario riprogettare parte o l'intera soluzione. Questa riprogettazione consente di gestire un numero crescente di tenant. Quando si progetta un sistema di messaggistica, è consigliabile considerare la crescita prevista nei volumi di messaggi e nei tenant, nei prossimi anni, e quindi creare un sistema in grado di aumentare il numero di istanze, per mantenere il passo con il traffico stimato e ridurre la complessità delle operazioni, ad esempio il provisioning, il monitoraggio e la manutenzione.

La soluzione deve creare o eliminare automaticamente le entità di messaggistica necessarie ogni volta che viene effettuato il provisioning o l'annullamento del provisioning di un'applicazione tenant, senza la necessità di operazioni manuali.

Un particolare problema per le soluzioni di dati multi-tenant è il livello di personalizzazione supportato. Qualsiasi personalizzazione deve essere configurata e applicata automaticamente dal sistema di provisioning dell'applicazione (ad esempio un sistema DevOps), che si basa su un set di parametri iniziali, ogni volta che viene distribuita un'applicazione a tenant singolo o multi-tenant.

Complessità della gestione e delle operazioni

Pianificare sin dall'inizio come si intende operare, monitorare e gestire l'infrastruttura di messaggistica ed eventi e il modo in cui l'approccio multi-tenancy influisce sulle operazioni e sui processi. Si considerino ad esempio le possibilità seguenti:

  • È possibile pianificare l'hosting del sistema di messaggistica usato dall'applicazione in un set dedicato di macchine virtuali, uno per ogni tenant. In tal caso, come si prevede di distribuire, aggiornare, monitorare e aumentare il numero di istanze di questi sistemi?
  • Analogamente, se si ospita e si ospita il sistema di messaggistica in un cluster Kubernetes condiviso, come si prevede di distribuire, aggiornare, monitorare e scalare i singoli sistemi di messaggistica?
  • Si supponga di condividere un sistema di messaggistica tra più tenant. In che modo la soluzione può raccogliere e segnalare le metriche di utilizzo per tenant o limitare il numero di messaggi che ogni tenant può inviare o ricevere?
  • Quando il sistema di messaggistica usa un servizio PaaS, ad esempio bus di servizio di Azure, è necessario porre la domanda seguente:
    • Come è possibile personalizzare il piano tariffario per ogni tenant, in base alle funzionalità e al livello di isolamento (condiviso o dedicato) richiesto dal tenant?
    • Come è possibile creare un'identità di gestione per tenant e un'assegnazione di ruolo di Azure per assegnare le autorizzazioni appropriate solo alle entità di messaggistica, ad esempio code, argomenti e sottoscrizioni, a cui il tenant può accedere? Per altre informazioni, vedere Autenticare un'identità gestita con Microsoft Entra ID per accedere alle risorse bus di servizio di Azure.
  • Come si eseguirà la migrazione dei tenant, se necessario passare a un tipo diverso di servizio di messaggistica, a una distribuzione diversa o a un'altra area?

Costo

In genere, maggiore è la densità dei tenant per l'infrastruttura di distribuzione, minore è il costo per il provisioning di tale infrastruttura. Tuttavia, l'infrastruttura condivisa aumenta la probabilità di problemi come il problema Noisy Neighbor, quindi considerare attentamente i compromessi.

Approcci e modelli da prendere in considerazione

Diversi modelli di progettazione cloud del Centro architetture di Azure possono essere applicati a un sistema di messaggistica multi-tenant. È possibile scegliere di seguire uno o più modelli in modo coerente oppure è possibile prendere in considerazione la combinazione e i modelli di corrispondenza in base alle proprie esigenze. Ad esempio, è possibile usare uno spazio dei nomi multi-tenant bus di servizio per la maggior parte dei tenant, ma è possibile distribuire uno spazio dei nomi dedicato bus di servizio tenant singolo per i tenant che pagano più o che hanno requisiti più elevati, in termini di isolamento e prestazioni. Analogamente, è spesso consigliabile ridimensionare usando indicatori di distribuzione, anche quando si usa uno spazio dei nomi multi-tenant bus di servizio o spazi dei nomi dedicati all'interno di un timbro.

Modello degli stamp di distribuzione

Per altre informazioni sul modello deployment stamp e sulla multi-tenancy, vedere la sezione Modello stamp di distribuzione degli approcci architetturali per la multi-tenancy. Per altre informazioni sui modelli di tenancy, vedere Modelli tenancy da considerare per una soluzione multi-tenant.

Sistema di messaggistica condivisa

È possibile valutare la possibilità di distribuire un sistema di messaggistica condivisa, ad esempio bus di servizio di Azure, e condividerlo in tutti i tenant.

Diagram showing a single shared multitenant messaging system for all tenants.

Questo approccio fornisce la massima densità dei tenant all'infrastruttura, quindi riduce il costo totale totale di proprietà. Spesso riduce anche il sovraccarico di gestione, poiché esiste un singolo sistema di messaggistica o una singola risorsa per gestire e proteggere.

Tuttavia, quando si condivide una risorsa o un'intera infrastruttura tra più tenant, prendere in considerazione le avvertenze seguenti:

  • Tenere sempre presente e considerare i vincoli, le funzionalità di ridimensionamento, le quote e i limiti della risorsa in questione. Ad esempio, il numero massimo di spazi dei nomi bus di servizio in una sottoscrizione di Azure, il numero massimo di hub eventi in un singolo spazio dei nomi o i limiti massimi di velocità effettiva, potrebbe diventare un blocco più rigido, se e quando l'architettura aumenta per supportare più tenant. Considerare attentamente la scala massima che è necessario ottenere in termini di numero di spazi dei nomi per ogni singola sottoscrizione di Azure o code per singolo spazio dei nomi. Confrontare quindi le stime correnti e future con le quote e i limiti esistenti del sistema di messaggistica preferito, prima di selezionare questo modello.
  • Come accennato nelle sezioni precedenti, il problema Noisy Neighbor può diventare un fattore, quando si condivide una risorsa tra più tenant, soprattutto se alcuni sono particolarmente occupati o se generano traffico più elevato rispetto ad altri. In questo caso, è consigliabile applicare il modello di limitazione delle richieste o il modello di limitazione della frequenza per attenuare questi effetti. Ad esempio, è possibile limitare il numero massimo di messaggi che un singolo tenant può inviare o ricevere nell'unità di tempo.
  • Potrebbe essere difficile monitorare l'attività e misurare il consumo di risorse per un singolo tenant. Alcuni servizi, ad esempio bus di servizio di Azure, vengono addebitati per le operazioni di messaggistica. Di conseguenza, quando si condivide uno spazio dei nomi tra più tenant, l'applicazione deve essere in grado di tenere traccia del numero di operazioni di messaggistica eseguite per conto di ogni tenant e i costi di chargeback. Altri servizi non forniscono lo stesso livello di dettaglio.

I tenant possono avere requisiti diversi per la sicurezza, la resilienza all'interno dell'area, il ripristino di emergenza o la posizione. Se queste non corrispondono alla configurazione del sistema di messaggistica, potrebbe non essere possibile gestirle solo con una singola risorsa.

Modello di partizionamento orizzontale

Il modello di partizionamento orizzontale prevede la distribuzione di più sistemi di messaggistica, denominati partizioni, che contengono una o più entità di messaggistica dei tenant, ad esempio code e argomenti. A differenza dei francobolli di distribuzione, le partizioni non implicano che l'intera infrastruttura sia duplicata. È possibile che i sistemi di messaggistica partizioni non vengano duplicati o partizionati anche altre infrastrutture nella soluzione.

Diagram showing a sharded messaging system. One messaging system contains the queues for tenants A and B, and the other contains the queues for tenant C.

Ogni sistema di messaggistica o partizione può avere caratteristiche diverse in termini di affidabilità, SKU e posizione. Ad esempio, è possibile partizionare i tenant in più sistemi di messaggistica con caratteristiche diverse, in base alla posizione o alle esigenze in termini di prestazioni, affidabilità, protezione dei dati o continuità aziendale.

Quando si usa il modello di partizionamento orizzontale, è necessario usare una strategia di partizionamento orizzontale per eseguire il mapping di un determinato tenant al sistema di messaggistica che contiene le code. La strategia di ricerca usa una mappa per individuare il sistema di messaggistica di destinazione, in base al nome o all'ID del tenant. Più tenant possono condividere la stessa partizione, ma le entità di messaggistica usate da un singolo tenant non verranno distribuite tra più partizioni. La mappa può essere implementata con un singolo dizionario che esegue il mapping del nome del tenant al nome o al riferimento del sistema di messaggistica di destinazione. La mappa può essere archiviata in una cache distribuita accessibile, da tutte le istanze di un'applicazione multi-tenant o in un archivio permanente, ad esempio una tabella in un database relazionale o una tabella in un account di archiviazione.

Il modello di partizionamento orizzontale può essere ridimensionato a un numero molto elevato di tenant. Inoltre, a seconda del carico di lavoro, potrebbe essere possibile ottenere una densità elevata di tenant per le partizioni, in modo che il costo possa essere interessante. Il modello di partizionamento orizzontale può essere usato anche per gestire le quote, i limiti e i vincoli del servizio di Azure.

App multi-tenant con sistema di messaggistica dedicato per ogni tenant

Un altro approccio comune consiste nel distribuire una singola applicazione multi-tenant, con sistemi di messaggistica dedicati per ogni tenant. In questo modello di tenancy sono disponibili alcuni componenti condivisi, ad esempio le risorse di calcolo, mentre altri servizi vengono forniti e gestiti usando un approccio di distribuzione dedicato a tenant singolo. Ad esempio, è possibile compilare un singolo livello applicazione e quindi distribuire singoli sistemi di messaggistica per ogni tenant, come illustrato nella figura seguente.

Diagram showing different messaging systems for each tenant.

Le distribuzioni partizionate orizzontalmente consentono di attenuare un problema di disturbo adiacente, se è stato rilevato che la maggior parte del carico nel sistema è dovuta a componenti specifici che è possibile distribuire separatamente per ogni tenant. Ad esempio, potrebbe essere necessario usare un sistema di messaggistica o di streaming di eventi separato per ogni tenant perché una singola istanza non è sufficiente per tenere il passo con il traffico generato da più tenant. Quando si usa un sistema di messaggistica dedicato per ogni tenant, se un singolo tenant causa un volume elevato di messaggi o eventi, questo potrebbe influire sui componenti condivisi, ma non su altri sistemi di messaggistica dei tenant.

Poiché si effettua il provisioning di risorse dedicate per ogni tenant, il costo per questo approccio può essere superiore a quello di un modello di hosting condiviso. D'altra parte, è più facile ricaricare i costi delle risorse di un sistema dedicato al tenant univoco che lo usa, quando si adotta questo modello di tenancy. Questo approccio consente di ottenere una densità elevata per altri servizi, ad esempio le risorse di calcolo, e riduce i costi di questi componenti.

Con una distribuzione partizionata orizzontalmente, è necessario adottare un processo automatizzato per la distribuzione e la gestione dei servizi di un'applicazione multi-tenant, in particolare quelli usati da un singolo tenant.

Modello geodes

Il modello Geode prevede la distribuzione di una raccolta di servizi back-end in un set di nodi geografici. Ognuno può eseguire qualsiasi richiesta per qualsiasi client in qualsiasi area. Questo modello consente di gestire le richieste in uno stile attivo-attivo, migliorando la latenza e aumentando la disponibilità, distribuendo l'elaborazione delle richieste in tutto il mondo.

Diagram showing the Geode pattern, with messaging systems deployed across multiple regions that synchronize together.

bus di servizio di Azure e Hub eventi di Azure supportano il ripristino di emergenza dei metadati, tra spazi dei nomi di ripristino di emergenza primario e secondario e in aree di disponibilità separate, per fornire supporto per la migliore resilienza all'interno dell'area. Inoltre, bus di servizio di Azure e Hub eventi di Azure implementare un set di modelli di federazione che replicano attivamente lo stesso argomento logico, coda o hub eventi per essere disponibili in più spazi dei nomi, alla fine situati in aree diverse. Per ulteriori informazioni, vedi le seguenti risorse:

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Altri contributori:

Passaggi successivi

Per altre informazioni sui modelli di progettazione della messaggistica, vedere le risorse seguenti: