Modelli di progettazione per i microservizi

Servizi cloud di Azure

L'obiettivo dei microservizi è aumentare la velocità delle versioni dell'applicazione scomponendo l'applicazione in piccoli servizi autonomi che possono essere distribuiti in modo indipendente. Un'architettura di microservizi comporta anche alcune sfide. I modelli di progettazione illustrati di seguito consentono di attenuare queste sfide.

Microservices design patterns

Ambassador può essere usato per eseguire l'offload di attività comuni di connettività client, ad esempio il monitoraggio, la registrazione, il routing e la sicurezza (ad esempio TLS) in modo indipendente dal linguaggio. I servizi Ambassador vengono spesso distribuiti come sidecar (vedere di seguito).

Il livello anti-danneggiamento implementa una facciata tra applicazioni nuove e legacy, per garantire che la progettazione di una nuova applicazione non sia limitata dalle dipendenze dai sistemi legacy.

I back-end per i front-end creano servizi back-end separati per diversi tipi di client, ad esempio desktop e dispositivi mobili. In questo modo, un singolo servizio back-end non deve gestire i requisiti in conflitto di vari tipi di client. Questo modello consente di mantenere semplice ogni microservizio separando i problemi specifici del client.

La testa bulk isola le risorse critiche, ad esempio pool di connessioni, memoria e CPU, per ogni carico di lavoro o servizio. Usando le intestazioni bulk, un singolo carico di lavoro (o servizio) non può utilizzare tutte le risorse, con la fame di altri utenti. Questo modello aumenta la resilienza del sistema impedendo errori a catena causati da un servizio.

Aggregazione gateway aggrega le richieste a più microservizi singoli in una singola richiesta, riducendo la chattiness tra consumer e servizi.

L'offload del gateway consente a ogni microservizio di eseguire l'offload delle funzionalità del servizio condiviso, ad esempio l'uso di certificati SSL, in un gateway API.

Il routing del gateway instrada le richieste a più microservizi usando un singolo endpoint, in modo che i consumer non debbano gestire molti endpoint separati.

Messaging Bridge integra sistemi diversi creati con infrastrutture di messaggistica diverse.

Sidecar distribuisce i componenti helper di un'applicazione come contenitore o processo separato per fornire isolamento e incapsulamento.

Strangler Fig supporta il refactoring incrementale di un'applicazione, sostituendo gradualmente parti specifiche di funzionalità con nuovi servizi.

Per il catalogo completo dei modelli di progettazione cloud nel Centro architetture di Azure, vedere Modelli di progettazione cloud.

Passaggi successivi