molto impegnativo all’inizio. Comporta per\u00f2 diversi vantaggi che possono essere riassunti come
“indipendenza dai componenti<\/strong>“. <\/p>\n\n\n\n
Per citare solo alcuni di questi:<\/p>\n\n\n\n
- \n
- Scalabilit\u00e0<\/strong>: i componenti possono fare scale in\/out a seconda del loro utilizzo in modo indipendente.
Questo di solito si traduce in un migliore utilizzo delle risorse e in una riduzione dei costi ed \u00e8 anche un fattore-chiave per l’alta disponibilit\u00e0 dell’intero sistema.<\/li>\n\n\n\n- Resilienza:<\/strong> \u00e8 meno probabile che un guasto in un singolo microservizio si propaghi all’intero sistema creando un fallimento grave.<\/li>\n\n\n\n
- Manutenibilit\u00e0<\/strong>: i microservizi, come suggerisce il nome, sono solitamente componenti pi\u00f9 piccoli. In termini di code base, la manutenzione e l’aggiornamento diventano quindi pi\u00f9 semplici, con conseguenti aggiornamenti pi\u00f9 rapidi e consistenti. Inoltre, i microservizi possono essere anche indipendenti dal punto di vista del linguaggio di programmazione e\/o della tecnologia usata, quindi il loro sviluppo pu\u00f2 essere suddiviso e parallelizzato tra pi\u00f9 team. Questo pu\u00f2 aumentare enormemente la velocit\u00e0 di sviluppo del prodotto e delle relative funzionalit\u00e0.<\/li>\n\n\n\n
- Facilit\u00e0 di test:<\/strong> un altro aspetto della code base ridotta dei microservizi \u00e8 che il test del codice diventa pi\u00f9 semplice. Gli sviluppatori dovranno scrivere test unitari solo per lo specifico microservizio. Questo solitamente si traduce in un maggior numero di test scritti e in una migliore copertura del codice che contribuisce alla robustezza del software.<\/li>\n<\/ul>\n\n\n\n
Questa indipendenza \u00e8 fondamentale nell’ambiente dinamico ed elastico del cloud, dove
l’agilit\u00e0, unita alla scalabilit\u00e0 fornita dai servizi AWS, aiuta realmente a sviluppare e migliorare
rapidamente l’applicazione.<\/p>\n\n\n\nComponenti a basso accoppiamento<\/h2>\n\n\n\n
Un modello di progettazione comune \u00e8 quello dei “componenti a basso accoppiamento”: i componenti devono essere progettati per operare indipendentemente l’uno dall’altro, interagendo con una dipendenza minima o nulla. <\/p>\n\n\n\n
In questo senso, i componenti hanno una conoscenza minima l’uno dell’altro; sanno solo come scambiare informazioni tra loro attraverso interfacce ben definite o contratti che standardizzano la comunicazione: strutture di messaggi, formato dei dati e cos\u00ec via.<\/p>\n\n\n\n
Come accennato in precedenza, l’accoppiamento pu\u00f2 essere visto sotto molti aspetti diversi: dall’accoppiamento tecnologico, in cui le applicazioni condividono lo stesso linguaggio di programmazione o la stessa tecnologia, all’accoppiamento della comunicazione e della conversazione: la comunicazione \u00e8 sincrona o asincrona? Come comunichiamo: risultati completi, paginazione, caching? E il meccanismo di riprova?<\/p>\n\n\n\n
Dato che lo scopo di questo articolo \u00e8 incentrato sulla comunicazione tra sistemi, ci concentreremo sulle strategie di disaccoppiamento correlate.<\/p>\n\n\n\n
Gli Event Bus: la spina dorsale delle architetture distribuite nel Cloud<\/h2>\n\n\n\n
Parlando di comunicazione tra sistemi, gli event bus sono la soluzione perfetta per ottenere il disaccoppiamento.<\/p>\n\n\n\n
Nelle architetture cloud, i sistemi comunicano e si integrano tra loro utilizzando gli eventi. Gli event bus possono essere utilizzati come sistema di interconnessione tra produttori e consumatori di eventi, orchestrando il flusso di eventi tra le parti.<\/p>\n\n\n\n
La caratteristica principale \u00e8 che, poich\u00e9 il bus si trova nel mezzo tra produttori e consumatori, \u00e8 possibile collegare pi\u00f9 sistemi in una relazione molti-a-molti<\/em> con il minimo sforzo: i produttori invieranno i loro eventi al bus dedicato e tutti i consumatori interessati a un evento specifico lo riceveranno ed elaboreranno.<\/p>\n\n\n\n
A titolo di esempio, si pensi a un sito di e-commerce che deve elaborare un ordine sotto diversi aspetti: elaborazione del pagamento, gestione dell’inventario e spedizione dell’ordine.<\/p>\n\n\n\n
Lo stesso vale per i consumatori che possono essere interessati allo stesso tipo di evento, prodotto da pi\u00f9 sistemi. Un esempio di ci\u00f2 pu\u00f2 essere un sistema di notifiche comune per l’intera architettura.<\/p>\n\n\n\n
In questo senso, si pu\u00f2 notare come l’uso degli event bus \u00e8 simile a quello di un sistema Pub\/Sub.<\/p>\n\n\n\n
<\/p>\n\n\n
\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2024\/02\/unnamed-2024-02-05T165526.338-1.png\")
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Gestione degli event bus su AWS: Amazon EventBridge<\/h2>\n\n\n\n
Il servizio AWS che consente di creare e utilizzare gli event bus \u00e8 Amazon EventBridge<\/strong>. Per ogni account AWS \u00e8 previsto un event bus pre-creato chiamato “default<\/strong>“. Questo bus viene utilizzato da tutti i servizi AWS all’interno dell’account per pubblicare tutti gli eventi relativi alle loro operazioni. Questo bus \u00e8 molto importante perch\u00e9 \u00e8 la spina dorsale di tutta l’architettura event-driven di AWS. (Un rapido esempio: Funzione Lambda attivata su oggetti caricati su Amazon S3).<\/p>\n\n\n\n
Oltre all\u2019event bus predefinito, \u00e8 possibile creare event bus specifici per le applicazioni per disaccoppiarle all’interno dello stesso account AWS.<\/strong><\/p>\n\n\n\n
Un altro importante livello di disaccoppiamento che si pu\u00f2 ottenere utilizzando i bus di eventi EventBridge \u00e8 il disaccoppiamento degli account della AWS Organization. Solitamente le organizzazioni dispongono di pi\u00f9 account AWS raggruppati per applicazioni specifiche. In tali contesti, c’\u00e8 solitamente la necessit\u00e0 di centralizzare risorse specifiche in modo che il team che dovr\u00e0 lavorarci possa farlo facilmente.<\/p>\n\n\n\n
Riprendendo un esempio precedente, si pensi alla necessit\u00e0 di centralizzare i log e monitorare le metriche. Gli event bus di EventBridge possono essere letti\/scritti cross-account AWS, per cui applicazioni specifiche potranno facilmente inviare le loro metriche all’event bus dell\u2019account AWS dedicato, dove saranno presenti trigger di eventi per archiviare e consolidare questo tipo di informazioni.<\/p>\n\n\n\n
Il servizio Amazon EventBridge dispone di funzioni aggiuntive come Rules e Pipes <\/strong>per definire regole per eventi specifici – anche da integrazioni di servizi AWS – filtrarli e trasformarli, per poi consegnarli ai consumatori.<\/p>\n\n\n\n
Oltre agli event bus EventBridge, esiste un altro servizio AWS che pu\u00f2 essere utilizzato come bus di eventi: Amazon SNS. <\/p>\n\n\n\n
Amazon SNS pu\u00f2 essere visto come un bus di eventi altamente scalabile e flessibile che consente ai componenti di pubblicare e sottoscriversi agli eventi, assicurando che i cambiamenti in una parte del sistema inneschino risposte appropriate altrove. Utilizzando i topic SNS, possiamo disaccoppiare gli eventi, semplificandone la gestione.<\/p>\n\n\n\n
Code: disaccoppiamento, flusso di controllo e controllo di flusso<\/h2>\n\n\n\n
Oltre agli event bus, un altro strumento che possiamo usare per raggiungere o migliorare il livello di disaccoppiamento della nostra architettura sono le code. Le code fungono da intermediari tra i componenti, aiutandoli in diversi modi: dalla comunicazione asincrona, che elimina la necessit\u00e0 di avere entrambi i sistemi online nello stesso momento, al disaccoppiamento temporale, che consente ai produttori e ai consumatori di creare ed elaborare i messaggi secondo il proprio ritmo.<\/p>\n\n\n\n
Il servizio di code in AWS \u00e8 Amazon SQS, che pu\u00f2 anche essere integrato con EventBridge, complementando il servizio e agendo anche come traduttore da architetture event-driven a message-driven. <\/p>\n\n\n\n
Per approfondire il potenziale del servizio EventBridge e il modo in cui possiamo sfruttarlo per il disaccoppiamento architetturale, dobbiamo introdurre due concetti aggiuntivi: il flusso di controllo e il controllo del flusso<\/strong>.<\/p>\n\n\n\n
Il flusso di controllo <\/strong>definisce l’ordine delle operazioni per elaborare i messaggi o i task. Questo argomento \u00e8 fondamentale per comprendere meglio ogni integrazione con gli event bus in generale. Lo vedremo applicato ai casi d’uso con EventBridge.<\/p>\n\n\n\n
Fondamentalmente, dobbiamo definire come i sistemi si integrano tra loro. Possiamo classificare ogni componente di una data integrazione in 4 classi diverse, a seconda della comunicazione con gli altri componenti dell’integrazione:<\/p>\n\n\n\n
- \n
- Puller:<\/strong> riceve attivamente i messaggi; i suoi output sono presi passivamente dal passo successivo. <\/li>\n\n\n\n
- Pusher:<\/strong> i suoi input sono spinti dal passo precedente, spinge attivamente i messaggi di uscita.<\/li>\n\n\n\n
- Coda:<\/strong> riceve passivamente i messaggi in ingresso e fornisce quelli in uscita.<\/li>\n\n\n\n
- Driver:<\/strong> riceve attivamente i messaggi di input e fornisce quelli di output.<\/li>\n<\/ul>\n\n\n\n
Vediamolo in pratica con due semplici esempi che utilizzano un’integrazione molto comune: <\/p>\n\n\n\n
Amazon SNS \u2192 Amazon EventBridge \u2192 destinazione evento. <\/p>\n\n\n\n
Poich\u00e9 Amazon SNS \u00e8 una sorgente pusher (spinge attivamente gli input), il filtraggio e le trasformazioni degli eventi di EventBridge sono anch’essi passi pusher (quando ricevono l’input e lo elaborano, inoltrando al passo successivo), diversi tipi di destinazioni possono portare a diversi tipi di integrazioni:<\/p>\n\n\n\n
- \n
- Destinazione SQS: \u00e8 una coda (riceve passivamente gli input). L’integrazione avviene senza problemi.<\/li>\n\n\n\n
- Destinazione API: le API possono essere viste come uno step di tipo driver (prende gli input e manda gli output attivamente) e ci\u00f2 diventa un problema se lo step precedente \u00e8 di tipo Pusher.<\/li>\n<\/ol>\n\n\n\n
Per ottenere la seconda integrazione, \u00e8 necessario comprendere il flusso di controllo e applicare strategie adatte. \u00c8 necessario interporre un componente aggiuntivo per invertire il flusso di controllo, prendendo gli input spinti attivamente dalla sorgente e preparando gli output per una destinazione attiva di tipo poller.<\/p>\n\n\n\n
Questa \u00e8 la definizione di uno step di tipo coda. Una delle propriet\u00e0 delle code nel flusso di controllo \u00e8 quella di invertire il flusso, consentendo cos\u00ec integrazioni tra sistemi pusher-puller.<\/p>\n\n\n\n
Inoltre, le API possono avere dei limiti (richieste\/secondo, ecc\u2026), quindi, impostazioni come la frequenza di invocazione e il TTL dei messaggi in coda possono essere utilizzate per non sovraccaricare il sistema di destinazione.<\/p>\n\n\n\n
\u00c8 qui che entra in gioco il controllo del flusso<\/strong>. <\/p>\n\n\n\n
Le code sono ottime per la loro propriet\u00e0 di disaccoppiamento temporale; la velocit\u00e0 dei messaggi prodotti pu\u00f2 variare molto da quella dei messaggi consumati. Tuttavia, se queste sono molto diverse, pu\u00f2 diventare un problema, poich\u00e9 la coda si riempir\u00e0 continuamente fino ad essere completamente piena.<\/p>\n\n\n\n
Per risolvere questo problema, abbiamo due principali pattern del controllo del flusso: TTL (time to live), che scarta i messaggi troppo vecchi, e back pressure, che rallenta la velocit\u00e0 di arrivo. Il primo \u00e8 gi\u00e0 implementato in Amazon SQS, mentre il secondo metodo deve essere implementato dal lato produttore.<\/p>\n\n\n\n
<\/p>\n\n\n
\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2024\/02\/unnamed-2024-02-05T165625.111-1.png\")
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Semantica dell’ordine e della consegna<\/h2>\n\n\n\n
Parlando di sistemi distribuiti e di come i loro componenti si scambiano messaggi, vale la pena spendere qualche riga per discutere l’ordine dei messaggi e la semantica di consegna.<\/p>\n\n\n\n
Il mantenimento dell’ordine di elaborazione dei messaggi nei sistemi distribuiti pu\u00f2 essere essenziale per garantire la coerenza e l’integrit\u00e0 dei processi aziendali. L’ordinamento dei messaggi consiste nel garantire che gli eventi vengano consumati ed elaborati nello stesso ordine in cui sono stati prodotti.<\/p>\n\n\n\n
L’ordine<\/strong> diventa una sfida difficile quando iniziamo ad avere pi\u00f9 consumatori. Possiamo ottenere l’ordine dei messaggi utilizzando il pattern First-In-First-Out (FIFO) (in poche parole: \u201cchi prima arriva meglio alloggia\u201d. <\/p>\n\n\n\n
Gli event bus di EventBridge consegnano gli eventi garantendo un ordine FIFO. Amazon SNS ha topic FIFO, mentre Amazon SQS ha code FIFO e gruppi di messaggi. I gruppi consentono di ottenere un ordinamento locale dei messaggi, relativamente al gruppo. Infatti, ogni messaggio all’interno di un dato gruppo, secondo l’ordine di arrivo, sar\u00e0 inviato per l’elaborazione allo stesso consumatore.<\/p>\n\n\n\n
Una nota aggiuntiva sui topic e le code FIFO: i gruppi di messaggi sono mantenuti tra topic e coda.<\/p>\n\n\n\n
Parlando di semantica di consegna<\/strong>, EventBridge supporta due semantiche: “Almeno una volta” e “Esattamente una volta”. <\/p>\n\n\n\n
La prima scelta fa pensare alla possibilit\u00e0 di eventi duplicati, pertanto \u00e8 necessario applicare strategie di deduplicazione e progettare i consumatori in modo che siano idempotenti. \u00c8 possibile ottenere la deduplicazione con le code SQS utilizzando due funzionalit\u00e0: l’ID di deduplicazione dei messaggi e il timeout di visibilit\u00e0.<\/p>\n\n\n\n
Gestione degli errori, archivi e repliche<\/h2>\n\n\n\n
I guasti possono verificarsi anche nei sistemi distribuiti a causa della loro natura complessa. <\/p>\n\n\n\n
Una gestione efficace degli errori \u00e8 essenziale per preservare l’affidabilit\u00e0 del sistema, indipendentemente dalla causa dell’errore (problemi di rete, servizi non disponibili o anomalie impreviste dei dati). <\/p>\n\n\n\n
Gli errori possono essere classificati in due categorie principali: gli errori temporanei, che si risolvono con il tempo, come ad esempio l’indisponibilit\u00e0 di un sistema o il carico troppo elevato in quel dato momento, e gli errori sistematici, dovuti a bug che si ripetono continuamente.<\/p>\n\n\n\n
Possiamo usare le Dead Letter Queues (DLQ), insieme al parametro MaxRetryAttempt, per distinguere i due tipi di errore e, nel caso di un errore sistematico, far s\u00ec che un team lo ispezioni e aggiorni la logica del codice per risolverlo.<\/p>\n\n\n\n
I messaggi possono essere archiviati per la verifica, la conformit\u00e0 e l’analisi storica. \u00c8 possibile archiviare gli eventi a lungo termine utilizzando Amazon S3 per la memorizzazione e utilizzare le DLQ per gli errori immediati. Una volta archiviati gli eventi, \u00e8 possibile riprodurre i messaggi necessari.<\/p>\n\n\n\n
La capacit\u00e0 di riprodurre gli eventi fornisce un ciclo di miglioramento continuo, consentendo agli sviluppatori di imparare dagli errori, perfezionare la logica del sistema e migliorarne l’affidabilit\u00e0 complessiva.<\/p>\n\n\n\n
Un consiglio veloce: attenzione a non usare gli ID dei messaggi AWS, poich\u00e9 cambiano durante la rielaborazione. Inoltre, i consumatori, insieme ai sistemi a valle, rielaboreranno lo stesso evento. Pertanto, devono essere progettati per essere idempotenti.<\/p>\n\n\n\n
Conclusioni<\/h2>\n\n\n\n
Al termine di questa esplorazione sulle complessit\u00e0 delle architetture cloud disaccoppiate su AWS, arriviamo a un punto di convergenza tra resilienza e innovazione. <\/p>\n\n\n\n
I servizi AWS come Amazon EventBridge e Amazon SQS ci aiutano a orchestrare e disaccoppiare la nostra infrastruttura, aprendo la strada a una nuova era del cloud computing in cui affidabilit\u00e0, scalabilit\u00e0 e flessibilit\u00e0 operano armonicamente insieme.<\/p>\n\n\n\n
Nel corso della nostra indagine, abbiamo visto come il disaccoppiamento liberi i componenti in modo che possano operare insieme in modo armonioso, ma separato<\/em>. <\/p>\n\n\n\n
Abbiamo analizzato le strategie di flusso di controllo e controllo di flusso e ci siamo resi conto di quanto siano importanti per bilanciare la messaggistica e la comunicazione tra i componenti nei sistemi distribuiti. <\/p>\n\n\n\n
Abbiamo anche esplorato rapidamente argomenti come l’ordinamento dei messaggi e la semantica di consegna, concludendo parlando del potenziale offerto dalle strategie di gestione degli errori, dell’uso delle DLQ come reti di sicurezza per l’infrastruttura e delle repliche degli eventi come memoria storica per il miglioramento continuo.<\/p>\n\n\n\n
Diventa quindi chiaro come il disaccoppiamento non sia solo una strategia tecnica, ma uno strumento che consente alle organizzazioni di abbracciare l’innovazione, di adattarsi rapidamente a condizioni mutevoli e di creare sistemi duraturi, resilienti ed efficienti. <\/p>\n\n\n\n
Terminando questa disamina, continuiamo a innovare, ad adattarci e a liberare l’infinito potenziale delle architetture cloud disaccoppiate su AWS!<\/p>\n\n\n\n
Risorse<\/strong><\/h3>\n\n\n\n
- Pusher:<\/strong> i suoi input sono spinti dal passo precedente, spinge attivamente i messaggi di uscita.<\/li>\n\n\n\n
- Resilienza:<\/strong> \u00e8 meno probabile che un guasto in un singolo microservizio si propaghi all’intero sistema creando un fallimento grave.<\/li>\n\n\n\n