Esempi di infrastrutture su AWS - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Esempi di infrastrutture su AWS

Questa sezione fornisce esempi per la progettazione di un'infrastruttura per l'applicazione da utilizzare per implementare un'architettura esagonale. AWS Ti consigliamo di iniziare con un'architettura semplice per creare un prodotto minimo valido (MVP). La maggior parte dei microservizi necessita di un unico punto di ingresso per gestire le richieste dei client, un livello di elaborazione per eseguire il codice e un livello di persistenza per archiviare i dati. I seguenti AWS servizi sono ottimi candidati per essere utilizzati come client, adattatori primari e adattatori secondari in architettura esagonale:

  • Clienti: Amazon API Gateway, Amazon Simple Queue Service (Amazon SQS), Elastic Load Balancing, Amazon EventBridge

  • Adattatori principali: Amazon Elastic Container Service (Amazon ECS) AWS Lambda, Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Compute Cloud (Amazon) EC2

  • Adattatori secondari: Amazon DynamoDB, Amazon Relational Database Service (Amazon RDS), Amazon Aurora, API Gateway, Amazon SQS, Elastic Load Balancing EventBridge, Amazon Simple Notification Service (Amazon SNS)

Le sezioni seguenti illustrano questi servizi nel contesto dell'architettura esagonale in modo più dettagliato.

Inizia in modo semplice

Si consiglia di iniziare in modo semplice quando si progetta un'applicazione utilizzando l'architettura esagonale. In questo esempio, API Gateway viene utilizzato come client (API REST), Lambda come adattatore principale (elaborazione) e DynamoDB viene utilizzato come adattatore secondario (persistenza). Il client gateway chiama il punto di ingresso, che, in questo caso, è un gestore Lambda.

Architettura esagonale semplice

Questa architettura è completamente serverless e offre all'architetto un buon punto di partenza. Si consiglia di utilizzare lo schema di comandi nel dominio perché semplifica la gestione del codice e si adatta ai nuovi requisiti aziendali e non funzionali. Questa architettura potrebbe essere sufficiente per creare microservizi semplici con poche operazioni.

Applica il pattern CQRS

Ti consigliamo di passare al pattern CQRS se il numero di operazioni sul dominio sta per aumentare. È possibile applicare il pattern CQRS come architettura completamente serverless AWS utilizzando l'esempio seguente.

Applicazione del pattern CQRS in un'architettura esagonale

Questo esempio utilizza due gestori Lambda, uno per le query e uno per i comandi. Le query vengono eseguite in modo sincrono utilizzando un gateway API come client. I comandi vengono eseguiti in modo asincrono utilizzando Amazon SQS come client.

Questa architettura include più client (API Gateway e Amazon SQS) e più adattatori primari (Lambda), che vengono richiamati dai punti di ingresso corrispondenti (gestori Lambda). Tutti i componenti appartengono allo stesso contesto limitato, quindi si trovano all'interno dello stesso dominio.

Fai evolvere l'architettura aggiungendo contenitori, un database relazionale e un'API esterna

I contenitori sono una buona opzione per le attività di lunga durata. Potresti anche voler utilizzare un database relazionale se disponi di uno schema di dati predefinito e desideri sfruttare la potenza del linguaggio SQL. Inoltre, il dominio dovrebbe comunicare con l'esterno. APIs È possibile evolvere l'esempio di architettura per supportare questi requisiti, come illustrato nel diagramma seguente.

Evoluzione dell'architettura esagonale aggiungendo contenitori, un database relazionale e un'API esterna

Questo esempio utilizza Amazon ECS come adattatore principale per l'avvio di attività di lunga durata nel dominio. Amazon EventBridge (client) avvia un'attività Amazon ECS (punto di ingresso) quando si verifica un evento specifico. L'architettura include Amazon RDS come altro adattatore secondario per l'archiviazione di dati relazionali. Aggiunge inoltre un altro gateway API come adattatore secondario per richiamare una chiamata API esterna. Di conseguenza, l'architettura utilizza più adattatori primari e secondari che si basano su diversi livelli di elaborazione sottostanti in un unico dominio aziendale.

Il dominio è sempre associato in modo lasco a tutti gli adattatori primari e secondari tramite astrazioni chiamate porte. Il dominio definisce ciò che richiede dal mondo esterno utilizzando le porte. Poiché è responsabilità dell'adattatore implementare la porta, il passaggio da un adattatore all'altro non influisce sul dominio. Ad esempio, puoi passare da Amazon DynamoDB ad Amazon RDS scrivendo un nuovo adattatore, senza influire sul dominio.

Aggiungi altri domini (rimpicciolisci)

L'architettura esagonale si allinea bene con i principi di un'architettura di microservizi. Gli esempi di architettura mostrati finora contenevano un singolo dominio (o contesto limitato). Le applicazioni includono in genere più domini, che devono comunicare tramite adattatori primari e secondari. Ogni dominio rappresenta un microservizio ed è associato in modo approssimativo ad altri domini.

Aggiungere domini alla tua architettura esagonale

In questa architettura, ogni dominio utilizza un set diverso di ambienti di calcolo. (Ogni dominio può anche avere più ambienti di calcolo, come nell'esempio precedente). Ogni dominio definisce le interfacce richieste per comunicare con altri domini tramite porte. Le porte vengono implementate utilizzando adattatori primari e secondari. In questo modo, il dominio non viene modificato in caso di modifica dell'adattatore. Inoltre, i domini sono disaccoppiati l'uno dall'altro.

Nell'esempio di architettura mostrato nel diagramma precedente, Lambda, Amazon EC2, Amazon ECS AWS Fargate e vengono utilizzati come adattatori principali. API Gateway, Elastic Load Balancing e Amazon SQS vengono utilizzati come adattatori secondari. EventBridge