Progettazione di applicazioni basate su contenitori e microservizi

Suggerimento

Questo contenuto è un estratto dell'eBook, Architettura di microservizi .NET per applicazioni .NET containerizzati, disponibile in documentazione .NET o come PDF scaricabile gratuitamente leggibile offline.

Scaricare il PDF

I microservizi offrono grandi vantaggi, ma generano anche nuove sfide enormi. I modelli di architettura dei microservizi sono elementi fondamentali per la creazione di un'applicazione basata su microservizi.

In precedenza in questa guida sono stati illustrati i concetti di base relativi ai contenitori e a Docker. Queste informazioni erano il minimo necessario per iniziare a usare i contenitori. Anche se i contenitori sono abilitanti di e sono ideali per i microservizi, non sono obbligatori per un'architettura di microservizi. Molti concetti dell'architettura in questa sezione dell'architettura possono essere applicati senza contenitori. Tuttavia, questa guida è incentrata sull'intersezione di entrambi a causa dell'importanza già introdotta dei contenitori.

Le applicazioni aziendali possono essere complesse e spesso sono costituite da più servizi anziché da una singola applicazione basata su servizi. Per questi casi, è necessario comprendere altri approcci architetturali, ad esempio i microservizi e alcuni modelli DDD (Domain-Driven Design) e i concetti di orchestrazione dei contenitori. Si noti che questo capitolo descrive non solo i microservizi nei contenitori, ma anche qualsiasi applicazione in contenitori.

Principi di progettazione dei contenitori

Nel modello contenitore un'istanza dell'immagine del contenitore rappresenta un singolo processo. Definendo un'immagine del contenitore come limite di processo, è possibile creare primitive che possono essere usate per ridimensionare o raggruppare il processo.

Quando si progetta un'immagine del contenitore, verrà visualizzata una definizione ENTRYPOINT nel Dockerfile. Questa definizione definisce il processo il cui ciclo di vita controlla la durata del contenitore. Al termine del processo, termina il ciclo di vita del contenitore. I contenitori possono rappresentare processi a esecuzione prolungata come server Web, ma possono anche rappresentare processi di breve durata, ad esempio processi batch, che in precedenza potrebbero essere stati implementati come processi Web di Azure.

Se il processo fallisce, il contenitore termina e l'orchestratore assume il controllo. Se l'agente di orchestrazione è stato configurato per mantenere cinque istanze in esecuzione e una ha esito negativo, l'agente di orchestrazione creerà un'altra istanza del contenitore per sostituire il processo non riuscito. In un processo batch, l'esecuzione viene avviata con parametri. Al termine del processo, il lavoro viene completato. Queste linee guida approfondiscono sugli orchestratori, successivamente.

È possibile trovare uno scenario in cui si vogliono eseguire più processi in un singolo contenitore. Per questo scenario, poiché può essere presente un solo punto di ingresso per ogni contenitore, è possibile eseguire uno script all'interno del contenitore che avvia tutti i programmi necessari. Ad esempio, è possibile usare Supervisor o uno strumento simile per avviare più processi all'interno di un singolo contenitore. Tuttavia, anche se è possibile trovare architetture che contengono più processi per ogni contenitore, questo approccio non è molto comune.

PrecedenteAvanti