Condividi tramite

L'applicazione SaaS Wingtip Tickets

  • Articolo

Si applica a:database SQL di Azure

La stessa applicazione SaaS Wingtip Tickets viene implementata in ciascuno dei tre campioni. L'app è un'app SaaS semplice per l'elenco di eventi e la biglietteria, destinata a piccole sedi: teatri, club e così via. Ogni sede è un tenant dell'app e dispone di propri dati, ad esempio dettagli sede, elenchi di eventi, clienti, ordini di biglietti e così via. L'app, insieme agli script di gestione e alle esercitazioni, presenta uno scenario SaaS end-to-end. Sono inclusi i tenant di provisioning, il monitoraggio e la gestione delle prestazioni, la gestione dello schema e il reporting e analisi su più tenant.

Tre modelli di applicazione SaaS e tenancy

Sono disponibili tre versioni dell'app. Ognuna esplora un diverso modello di tenancy del database nel database SQL di Azure. Il primo usa un'applicazione autonoma per ogni tenant con il proprio database. Il secondo utilizza un'applicazione multiutente con un database per ciascun cliente. Il terzo esempio usa un'app multi-tenant con database multi-tenant partizionati.

Diagramma dei tre modelli di tenancy.

Ogni esempio include il codice applicazione, gli script di gestione ed esercitazioni che esplorano una gamma di modelli di progettazione e gestione. Ogni campione si implementa in meno di cinque minuti. Tutti e tre possono essere distribuiti fianco a fianco in modo da poter vedere le differenze di gestione e progettazione.

Modello di applicazione autonoma per ogni tenant

Il modello di app autonoma per ogni tenant usa un'applicazione a tenant singolo con un database per ogni tenant. L'app di ciascun tenant, incluso il relativo database, viene implementata in un gruppo di risorse di Azure separato. Il gruppo di risorse può essere distribuito nella sottoscrizione del provider di servizi o nella sottoscrizione del tenant e gestito dal provider per conto del tenant. Il modello di applicazione autonoma per ogni tenant fornisce il massimo isolamento dei tenant, ma è in genere il più costoso perché non esiste alcuna possibilità di condividere le risorse tra più tenant. Questo modello è particolarmente adatto ad applicazioni che potrebbero essere più complesse e che vengono distribuite in un numero inferiore di tenant. Con le distribuzioni autonome, l'app può essere più facilmente personalizzata per ogni tenant rispetto ad altri modelli.

Vedere le esercitazioni e il codice su GitHub .../Microsoft/WingtipTicketsSaaS-StandaloneApp.

Modello con un database per ogni tenant

Il modello con un database per ogni tenant è utile per i provider di servizi che si occupano di isolamento dei tenant e vogliono eseguire un servizio centralizzato che consente un utilizzo efficiente delle risorse condivise. Viene creato un database per ogni locale di ritrovo, o tenant, e tutti i database sono gestiti centralmente. I database possono essere ospitati in pool elastici per offrire una gestione delle prestazioni conveniente e semplice, che gestisce i modelli di carico di lavoro imprevedibili dei tenant. Un database di catalogo contiene il mapping tra i tenant e i relativi database. Questo mapping viene gestito mediante le funzionalità di gestione mappe partizioni della libreria client dei database elastici, il che offre una gestione efficiente delle connessioni all'applicazione.

Vedere le esercitazioni e il codice in GitHub .../Microsoft/WingtipTicketsSaaS-DbPerTenant.

Modello di database multi-tenant partizionato

I database multi-tenant sono efficaci per i provider di servizi che cercano un costo inferiore per ogni tenant e accettano un isolamento dei tenant ridotto. Questo modello consente di inserire un numero elevato di tenant in un unico database, riducendo il costo per tenant. È possibile avere una scalabilità quasi infinita partizionando i tenant in più database. Anche in questo caso un database di catalogo esegue il mapping dei tenant ai database.

Questo modello consente anche un modello ibrido di , in cui è possibile ottimizzare i costi con più tenant in un database o ottimizzare l'isolamento con un singolo tenant nel proprio database. La scelta può essere effettuata per ciascun tenant, sia quando viene effettuato il provisioning del tenant sia in un momento successivo, senza influire sull'applicazione. Questo modello può essere usato in modo efficace quando è necessario trattare in modo diverso i gruppi di tenant. Ad esempio, i tenant a basso costo possono essere assegnati a database condivisi, mentre i tenant premium possono essere assegnati ai propri database.

Consulta i tutorial Wingtips e il codice WingtipTicketsSaaS-MultiTenantDB su GitHub](https://github.com/Microsoft/WingtipTicketsSaaS-MultiTenantDb).

Contenuto correlato