Architettura logica e architettura fisica

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

A questo punto è utile arrestare e discutere la distinzione tra architettura logica e architettura fisica e come si applica alla progettazione di applicazioni basate su microservizi.

Per iniziare, la creazione di microservizi non richiede l'uso di una tecnologia specifica. Ad esempio, i contenitori Docker non sono obbligatori per creare un'architettura basata su microservizi. Questi microservizi possono anche essere eseguiti come processi semplici. I microservizi sono un'architettura logica.

Inoltre, anche quando un microservizio può essere implementato fisicamente come un singolo servizio, processo o contenitore (per semplicità, questo è l'approccio adottato nella versione iniziale di eShopOnContainers), questa parità tra microservizi aziendali e servizio fisico o contenitore non è necessariamente necessaria in tutti i casi quando si compila un'applicazione di grandi dimensioni e complessa composta da molte decine o persino centinaia di servizi.

Qui c'è una differenza tra l'architettura logica di un'applicazione e l'architettura fisica. L'architettura logica e i limiti logici di un sistema non corrispondono necessariamente uno-a-uno all'architettura fisica o di implementazione. Può accadere, ma spesso non lo fa.

Anche se potrebbero essere stati identificati determinati microservizi aziendali o contesti delimitati, non significa che il modo migliore per implementarli sia sempre creando un singolo servizio (ad esempio un'API Web ASP.NET) o un singolo contenitore Docker per ogni microservizio aziendale. Avere una regola che indica che ogni microservizio aziendale deve essere implementato usando un singolo servizio o contenitore è troppo rigido.

Pertanto, un microservizio aziendale o un contesto delimitato è un'architettura logica che potrebbe coincidere (o meno) con l'architettura fisica. Il punto importante è che un microservizio aziendale o un contesto delimitato deve essere autonomo consentendo il controllo delle versioni, la distribuzione e il ridimensionamento in modo indipendente del codice e dello stato.

Come illustrato nella figura 4-8, il microservizio aziendale del catalogo può essere costituito da diversi servizi o processi. Questi possono essere più ASP.NET servizi API Web o qualsiasi altro tipo di servizi tramite HTTP o qualsiasi altro protocollo. Più importante, i servizi potrebbero condividere gli stessi dati, purché questi servizi siano coesi rispetto allo stesso dominio aziendale.

Figura 4-8. Microservizio aziendale con diversi servizi fisici

I servizi nell'esempio condividono lo stesso modello di dati perché il servizio API Web è destinato agli stessi dati del servizio di ricerca. Pertanto, nell'implementazione fisica del microservizio aziendale, si divide tale funzionalità in modo da poter ridimensionare ognuno di questi servizi interni in base alle esigenze. Il servizio API Web richiede in genere più istanze del servizio di ricerca o viceversa.

In breve, l'architettura logica dei microservizi non deve sempre coincidere con l'architettura di distribuzione fisica. In questa guida, ogni volta che si menziona un microservizio, si intende un microservizio aziendale o logico che potrebbe eseguire il mapping a uno o più servizi (fisici). Nella maggior parte dei casi, questo sarà un singolo servizio, ma potrebbe essere più.

PrecedenteAvanti