{"id":6693,"date":"2024-02-02T09:00:00","date_gmt":"2024-02-02T08:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=6693"},"modified":"2024-02-05T17:01:05","modified_gmt":"2024-02-05T16:01:05","slug":"un-tuffo-nelle-architetture-cloud-disaccoppiate-con-gli-event-bus","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/un-tuffo-nelle-architetture-cloud-disaccoppiate-con-gli-event-bus\/","title":{"rendered":"Un tuffo nelle architetture cloud disaccoppiate con gli Event Bus"},"content":{"rendered":"\n
Per trasformarsi ed essere all’avanguardia nel mondo del Cloud Computing le aziende devono assicurarsi scalabilit\u00e0, resilienza e flessibilit\u00e0 dei loro sistemi.<\/p>\n\n\n\n
Per far ci\u00f2, sempre pi\u00f9 organizzazioni stanno migrando da architetture monolitiche a sistemi distribuiti.<\/p>\n\n\n\n
Nel passaggio da applicazioni monolitiche a sistemi distribuiti, padroneggiare le strategie e i pattern di disaccoppiamento diventa cruciale.<\/p>\n\n\n\n
Il disaccoppiamento (decoupling) \u00e8 un cambiamento strategico che divide i componenti all’interno di un
sistema, facendoli funzionare in modo indipendente e mantenendo l’interoperabilit\u00e0.<\/p>\n\n\n\n
Questo articolo \u00e8 ispirato da una sessione dell’AWS re:Invent 2023 Dal titolo “Advanced integration patterns & trade-offs for loosely coupled systems”<\/p>\n\n\n\n
In questo articolo esploreremo le architetture cloud disaccoppiate concentrandoci sulla funzione
degli event bus. Gli event bus fungono da base per il coordinamento e la comunicazione delle applicazioni in un sistema distribuito.<\/p>\n\n\n\n
Questo articolo spiegher\u00e0 le complessit\u00e0 della moderna architettura cloud ai tecnici veterani e ai
leader aziendali che desiderano comprenderne le basi. Evidenzier\u00e0, inoltre, i vantaggi concreti
dell’adozione di un approccio disaccoppiato.<\/p>\n\n\n\n
Il processo di scomposizione dell’applicazione monolitica in microservizi pu\u00f2 sembrare Per citare solo alcuni di questi:<\/p>\n\n\n\n Questa indipendenza \u00e8 fondamentale nell’ambiente dinamico ed elastico del cloud, dove 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 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 <\/p>\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 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 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 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 <\/p>\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 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 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
molto impegnativo all’inizio. Comporta per\u00f2 diversi vantaggi che possono essere riassunti come
“indipendenza dai componenti<\/strong>“. <\/p>\n\n\n\n\n
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
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
Gli Event Bus: la spina dorsale delle architetture distribuite nel Cloud<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n
Gestione degli event bus su AWS: Amazon EventBridge<\/h2>\n\n\n\n
Code: disaccoppiamento, flusso di controllo e controllo di flusso<\/h2>\n\n\n\n
\n
\n
<\/figure><\/div>\n\n\n
Semantica dell’ordine e della consegna<\/h2>\n\n\n\n
Gestione degli errori, archivi e repliche<\/h2>\n\n\n\n
Conclusioni<\/h2>\n\n\n\n
Risorse<\/strong><\/h3>\n\n\n\n