Comunicazione tra servizi

Suggerimento

Questo contenuto è un estratto dell'eBook, Progettazione di applicazioni .NET native del cloud per Azure, disponibile in .NET Docs o come PDF scaricabile gratuitamente che può essere letto offline.

Scarica PDF

Passando dal client front-end, ora affrontiamo i microservizi back-end che comunicano tra loro.

Quando si crea un'applicazione nativa del cloud, è necessario essere sensibili al modo in cui i servizi back-end comunicano tra loro. Idealmente, meno i servizi comunicano tra loro, meglio è. Tuttavia, non è sempre possibile evitare il fatto che i servizi back-end si basano spesso l'uno sull'altro per completare un'operazione.

Esistono diversi approcci ampiamente accettati per implementare la comunicazione tra servizi. Il tipo di interazione di comunicazione spesso determinerà l'approccio migliore.

Considerare i seguenti tipi di interazione:

• Query: quando un microservizio chiamante richiede una risposta da un microservizio chiamato, ad esempio "Hey, dammi le informazioni sull'acquirente per un determinato ID cliente".

• Comando: quando il microservizio chiamante richiede un altro microservizio per eseguire un'azione, ma non richiede una risposta, ad esempio "Ehi, spedisci questo ordine".

• Evento: quando un microservizio, denominato server di pubblicazione, genera un evento che lo stato è stato modificato o si è verificata un'azione. Altri microservizi, denominati sottoscrittori, che sono interessati, possono reagire in modo appropriato all'evento. Il server di pubblicazione e i sottoscrittori non sono a conoscenza degli altri.

I sistemi di microservizi usano in genere una combinazione di questi tipi di interazione durante l'esecuzione di operazioni che richiedono l'interazione tra servizi. Di seguito viene illustrato in dettaglio ogni aspetto e come implementarli.

Query

Molte volte, un microservizio potrebbe dover eseguire query su un altro, richiedendo una risposta immediata per completare un'operazione. Un microservizio carrello acquisti potrebbe richiedere informazioni sul prodotto e un prezzo per aggiungere un articolo al carrello. Esistono molti approcci per l'implementazione delle operazioni di query.

Messaggistica di tipo richiesta/risposta

Un'opzione per l'implementazione di questo scenario consiste nel chiamare il microservizio back-end per effettuare richieste HTTP dirette ai microservizi su cui è necessario eseguire query, come illustrato nella figura 4-8.

Figura 4-8. Comunicazione HTTP diretta

Anche se le chiamate HTTP dirette tra microservizi sono relativamente semplici da implementare, è necessario prestare attenzione a ridurre al minimo questa procedura. Per iniziare, queste chiamate sono sempre sincrone e bloccano l'operazione fino a quando non viene restituito un risultato o il timeout della richiesta. Quelli che una volta erano servizi autonomi e indipendenti, in grado di evolversi in modo indipendente e di distribuirsi frequentemente, ora sono accoppiati gli uni agli altri. Man mano che l'accoppiamento tra i microservizi aumenta, i vantaggi dell'architettura diminuiscono.

L'esecuzione di una richiesta rara che effettua una singola chiamata HTTP diretta a un altro microservizio potrebbe essere accettabile per alcuni sistemi. Tuttavia, le chiamate a volumi elevati che richiamano chiamate HTTP dirette a più microservizi non sono consigliate. Possono aumentare la latenza e influire negativamente sulle prestazioni, la scalabilità e la disponibilità del sistema. Peggio ancora, una lunga serie di comunicazioni HTTP dirette può portare a catene profonde e complesse di chiamate di microservizi sincrone, illustrate nella figura 4-9:

Figura 4-9. Concatenamento di query HTTP

È certamente possibile immaginare il rischio nella progettazione illustrata nell'immagine precedente. Cosa accade se il passaggio 3 ha esito negativo? Oppure se il passaggio 8 ha esito negativo? Come si esegue il ripristino? Cosa accade se il passaggio 6 è lento perché il servizio sottostante è occupato? Come continuare? Anche se tutto funziona correttamente, si pensi alla latenza che questa chiamata comporterebbe, che è la somma della latenza di ogni passaggio.

Il grado elevato di accoppiamento nell'immagine precedente suggerisce che i servizi non sono stati modellati in modo ottimale. Sarebbe opportuno che il team rivedesse la progettazione.

Modello di vista materializzata

Un'opzione comune per rimuovere l'accoppiamento di microservizi è il modello di visualizzazione materializzata. Con questo modello, un microservizio archivia la propria copia locale denormalizzata dei dati di proprietà di altri servizi. Anziché il microservizio Shopping Basket che esegue query sui microservizi Catalogo prodotti e Prezzi, gestisce la propria copia locale di tali dati. Questo modello elimina l'accoppiamento non necessario e migliora l'affidabilità e il tempo di risposta. L'intera operazione viene eseguita all'interno di un singolo processo. Questo modello e altri problemi relativi ai dati vengono esaminati nel capitolo 5.

Modello di aggregazione dei servizi

Un'altra opzione per eliminare l'accoppiamento da microservizio a microservizio è un microservizio Aggregator, illustrato in viola nella figura 4-10.

Figura 4-10. Microservizio Aggregator

Il modello isola un'operazione che effettua chiamate a più microservizi back-end, centralizzando la logica in un microservizio specializzato. Il microservizio aggregatore di checkout viola nella figura precedente orchestra il flusso di lavoro per l'operazione di checkout. Include chiamate a diversi microservizi back-end in un ordine sequenziato. I dati del flusso di lavoro vengono aggregati e restituiti al chiamante. Sebbene implementi ancora chiamate HTTP dirette, il microservizio aggregatore riduce le dipendenze dirette tra i microservizi back-end.

Modello di richiesta/risposta

Un altro approccio per separare i messaggi HTTP sincroni è un modello di richiesta-risposta, che usa la comunicazione di accodamento. La comunicazione che usa una coda è sempre un canale unidirezionale, con un producer che invia il messaggio e il consumer che lo riceve. Con questo modello vengono implementate sia una coda di richieste che una coda di risposte, come illustrato nella figura 4-11.

Figura 4-11. Modello di richiesta/risposta

In questo caso, il producer di messaggi crea un messaggio basato su query che contiene un ID di correlazione univoco e lo inserisce in una coda di richieste. Il servizio di utilizzo rimuove dalla coda i messaggi, li elabora e inserisce la risposta nella coda di risposta con lo stesso ID di correlazione. Il servizio producer rimuove dalla coda il messaggio, lo associa all'ID di correlazione e continua l'elaborazione. Le code vengono illustrate in dettaglio nella sezione successiva.

Comandi

Un altro tipo di interazione di comunicazione è un comando. Un microservizio potrebbe richiedere un altro microservizio per eseguire un'azione. Il microservizio Ordinazioni potrebbe richiedere il microservizio Spedizioni per creare una spedizione per un ordine approvato. Nella figura 4-12 un microservizio, denominato Producer, invia un messaggio a un altro microservizio, Consumer, ordinandogli di eseguire un'operazione.

Figura 4-12. Interazione dei comandi con una coda

La maggior parte delle volte, il producer non richiede una risposta e può generare e dimenticare il messaggio. Se è necessaria una risposta, il consumer invia un messaggio separato al producer su un altro canale. Un messaggio di comando è meglio se viene inviato in modo asincrono con una coda di messaggi. supportato da un broker di messaggi leggero. Nel diagramma precedente si noti come una coda separi e disaccoppi entrambi i servizi.

Una coda di messaggi è un costrutto intermedio attraverso il quale un producer e un consumer passano un messaggio. Le code implementano un modello di messaggistica da punto a punto asincrono. Il producer sa dove deve essere inviato un comando e lo instrada in modo appropriato. La coda garantisce che un messaggio venga elaborato esattamente da una delle istanze consumer che leggono dal canale. In questo scenario, il produttore o il servizio consumer può aumentare il numero di istanze senza influire sull'altro. Inoltre, le tecnologie possono essere diverse in ogni lato, vale a dire che potrebbe essere disponibile un microservizio Java che chiama un microservizio Golang.

Nel capitolo 1 abbiamo parlato dei servizi di backup. I servizi di backup sono risorse ausiliarie da cui dipendono i sistemi nativi del cloud. Le code di messaggi sono servizi di backup. Il cloud di Azure supporta due tipi di code di messaggi che i sistemi nativi del cloud possono usare per implementare la messaggistica dei comandi: code di Archiviazione di Azure e code del bus di servizio di Azure.

Code di Archiviazione di Azure

Le code di archiviazione di Azure offrono una semplice infrastruttura di accodamento veloce, conveniente e supportata dagli account di archiviazione di Azure.

Le code di archiviazione di Azure offrono un meccanismo di accodamento basato su REST con messaggistica affidabile e persistente. Forniscono un set di funzionalità minimo, ma sono economici e archiviano milioni di messaggi. La capacità varia fino a 500 TB. Le dimensioni massime di ogni messaggio possono essere di 64 kB.

È possibile accedere ai messaggi da qualsiasi parte del mondo tramite chiamate autenticate attraverso HTTP o HTTPS. Le code di archiviazione possono raggiungere un numero elevato di client simultanei per gestire i picchi di traffico.

Detto questo, esistono limitazioni con il servizio:

• L'ordine dei messaggi non è garantito.

• Un messaggio può essere mantenuto solo per sette giorni prima che venga rimosso automaticamente.

• Il supporto per la gestione dello stato, il rilevamento dei duplicati o le transazioni non è disponibile.

La figura 4-13 mostra la gerarchia di una coda di archiviazione di Azure.

Figura 4-13. Gerarchia delle code di archiviazione

Nella figura precedente si noti come le code di archiviazione archiviano i messaggi nell'account di archiviazione di Azure sottostante.

Per gli sviluppatori, Microsoft offre diverse librerie lato client e server per l'elaborazione delle code di archiviazione. È supportata la maggior parte delle piattaforme principali, tra cui .NET, Java, JavaScript, Ruby, Python e Go. Gli sviluppatori non devono mai comunicare direttamente con queste librerie. In questo modo il codice del microservizio verrà strettamente collegato al servizio di accodamento di Archiviazione di Azure. È consigliabile isolare i dettagli di implementazione dell'API. Introdurre un livello intermedio o un'API intermedia che espone operazioni generiche e incapsula la libreria concreta. Questo accoppiamento libero consente di scambiare un servizio di accodamento per un altro senza dover apportare modifiche al codice del servizio mainline.

Le code di Archiviazione di Azure sono un'opzione economica per implementare la messaggistica dei comandi nelle applicazioni native del cloud. In particolare quando una dimensione della coda supererà 80 GB o un set di funzionalità semplice è accettabile. Si paga solo per l'archiviazione dei messaggi; non sono previsti addebiti orari fissi.

Code del bus di servizio di Azure

Per requisiti di messaggistica più complessi, prendere in considerazione le code del bus di servizio di Azure.

In cima a un'infrastruttura di messaggi affidabile, il bus di servizio di Azure supporta un modello di messaggistica negoziata. I messaggi vengono archiviati in modo affidabile in un broker (la coda) fino a quando non vengono ricevuti dal consumer. La coda garantisce il recapito dei messaggi First-In/First-Out (FIFO), rispettando l'ordine in cui i messaggi sono stati aggiunti alla coda.

Le dimensioni di un messaggio possono essere molto più grandi, fino a 256 kB. I messaggi vengono salvati in modo permanente nella coda per un periodo illimitato di tempo. Il bus di servizio supporta non solo le chiamate basate su HTTP, ma fornisce anche il supporto completo per il protocollo AMQP. AMQP è uno standard aperto tra i fornitori che supporta un protocollo binario e un livello di affidabilità superiore.

Il bus di servizio offre un set completo di funzionalità, tra cui il supporto delle transazioni e una funzionalità di rilevamento duplicati. La coda garantisce il "recapito al massimo una volta" per ogni messaggio. Rimuove automaticamente un messaggio che è già stato inviato. Se un producer è in dubbio, può inviare nuovamente lo stesso messaggio e il bus di servizio garantisce che venga elaborata una sola copia. Il rilevamento di duplicati consente di creare un'infrastruttura plumbing aggiuntiva.

Altre due funzionalità aziendali sono il partizionamento e le sessioni. Una coda del bus di servizio convenzionale viene gestita da un singolo broker di messaggi e archiviata in un unico archivio messaggi. Tuttavia, il partizionamento del bus di servizio distribuisce la coda tra più broker di messaggi e archivi di messaggi. La velocità effettiva complessiva non è più limitata dalle prestazioni di un singolo broker di messaggi o archivio di messaggistica. Un'interruzione temporanea di un archivio di messaggistica non rende disponibile una coda partizionata.

Le sessioni del bus di servizio consentono di raggruppare i messaggi correlati. Si immagini uno scenario del flusso di lavoro in cui i messaggi devono essere elaborati insieme e l'operazione completata alla fine. Per sfruttare i vantaggi, le sessioni devono essere abilitate in modo esplicito per la coda e ogni messaggio correlato deve contenere lo stesso ID sessione.

Tuttavia, esistono alcune importanti avvertenze: le dimensioni delle code del bus di servizio sono limitate a 80 GB, molto più piccole rispetto a quelle disponibili dalle code dei negozi. Inoltre, le code del bus di servizio comportano un costo di base e un addebito per ogni operazione.

La figura 4-14 descrive l'architettura generale di una coda del bus di servizio.

Figura 4-14. coda del bus di servizio

Nella figura precedente si noti la relazione da punto a punto. Due istanze dello stesso provider stanno accodando i messaggi in una singola coda del bus di servizio. Ogni messaggio viene utilizzato da una sola delle tre istanze consumer a destra. Verrà quindi illustrato come implementare la messaggistica in cui i diversi consumer potrebbero essere interessati allo stesso messaggio.

Eventi

Accodamento messaggi è un modo efficace per implementare la comunicazione in cui un producer può inviare in modo asincrono un messaggio a un consumer. Tuttavia, cosa accade quando molti consumer diversi sono interessati allo stesso messaggio? Una coda di messaggi dedicata per ogni consumer non viene ridimensionata correttamente e diventa difficile da gestire.

Per risolvere questo scenario, si passa al terzo tipo di interazione tra messaggi, ovvero l'evento. Un microservizio annuncia che si è verificata un'azione. Altri microservizi, se interessati, reagiscono all'azione o all'evento. Questo è noto anche come stile architettonico basato su eventi.

L'evento è un processo in due passaggi. Per una modifica dello stato specificata, un microservizio pubblica un evento in un broker di messaggi, rendendolo disponibile per qualsiasi altro microservizio interessato. Il microservizio interessato riceve una notifica sottoscrivendo l'evento nel broker di messaggi. Usare il modello Pubblica/Sottoscrivi per implementare la comunicazione basata su eventi.

La figura 4-15 mostra un microservizio di tipo carrello della spesa che pubblica un evento con altri due microservizi che lo sottoscrivono.

Figura 4-15. Messaggistica guidata dagli eventi

Si noti il componente bus di eventi che si trova al centro del canale di comunicazione. Si tratta di una classe personalizzata che incapsula il broker di messaggi e la disaccoppia dall'applicazione sottostante. I microservizi di ordinamento e inventario operano in modo indipendente l'evento senza alcuna conoscenza tra loro, né il microservizio di tipo carrello della spesa. Quando l'evento registrato viene pubblicato nel bus di eventi, agiscono su di esso.

Con l'evento, passiamo dalla tecnologia di accodamento agli argomenti. Un argomento è simile a una coda, ma supporta un modello di messaggistica uno-a-molti. Un microservizio pubblica un messaggio. Più microservizi di sottoscrizione possono scegliere di ricevere e agire su tale messaggio. La figura 4-16 mostra un'architettura dell'argomento.

Figura 4-16. Architettura degli argomenti

Nella figura precedente gli editori inviano messaggi all'argomento. Alla fine, i sottoscrittori ricevono messaggi dalle sottoscrizioni. Al centro, l'argomento inoltra i messaggi alle sottoscrizioni in base a un set di regole, mostrato nelle caselle blu scuro. Le regole fungono da filtro che inoltrano messaggi specifici a una sottoscrizione. In questo caso, viene inviato un evento "GetPrice" alle sottoscrizioni di prezzo e registrazione perché la sottoscrizione di registrazione ha scelto di ricevere tutti i messaggi. Un evento "GetInformation" verrebbe inviato alle informazioni e alle sottoscrizioni di registrazione.

Il cloud di Azure supporta due diversi servizi di argomento: Argomenti del bus di servizio di Azure e Griglia di eventi di Azure.

Argomenti del bus di servizio di Azure

Oltre allo stesso modello di messaggio negoziato affidabile delle code del bus di servizio di Azure sono argomenti del bus di servizio di Azure. Un argomento può ricevere messaggi da più editori indipendenti e inviare messaggi a un massimo di 2.000 sottoscrittori. Le sottoscrizioni possono essere aggiunte o rimosse in modo dinamico in fase di esecuzione senza arrestare il sistema o ricreare l'argomento.

Molte funzionalità avanzate delle code del bus di servizio di Azure sono disponibili anche per argomenti, tra cui il supporto per il rilevamento dei duplicati e le transazioni. Per impostazione predefinita, gli argomenti del bus di servizio vengono gestiti da un singolo broker di messaggi e archiviati in un unico archivio messaggi. Tuttavia, il partizionamento del bus di servizio ridimensiona un argomento distribuendolo in molti broker di messaggi e archivi messaggi.

Il recapito pianificato dei messaggi contrassegna un messaggio con un tempo specifico per l'elaborazione. Il messaggio non verrà visualizzato nell'argomento prima di tale ora. Il differimento dei messaggi consente di rinviare un recupero di un messaggio a un secondo momento. Entrambi vengono comunemente usati negli scenari di elaborazione del flusso di lavoro in cui le operazioni vengono elaborate in un ordine specifico. È possibile posticipare l'elaborazione dei messaggi ricevuti fino al completamento del lavoro precedente.

Gli argomenti del bus di servizio sono una tecnologia solida e collaudata per abilitare la comunicazione di pubblicazione/sottoscrizione nei sistemi nativi del cloud.

Griglia di eventi di Azure

Mentre il bus di servizio di Azure è un broker di messaggistica testato con un set completo di funzionalità aziendali, Griglia di eventi di Azure è il nuovo elemento figlio del blocco.

A prima vista, Griglia di eventi può essere simile a un altro sistema di messaggistica basato su argomenti. Tuttavia, è diverso in molti modi. Incentrato sui carichi di lavoro basati su eventi, consente l'elaborazione di eventi in tempo reale, l'integrazione approfondita di Azure e un'infrastruttura open-platform, tutto su un'infrastruttura serverless. È progettato per applicazioni native del cloud e serverless contemporanee

Come backplane, o pipe, centralizzati di eventi, Griglia di eventi reagisce agli eventi all'interno delle risorse di Azure e dai propri servizi.

Le notifiche degli eventi vengono pubblicate in un argomento di Griglia di eventi, che a sua volta instrada ogni evento a una sottoscrizione. I sottoscrittori eseguono il mapping alle sottoscrizioni e utilizzano gli eventi. Analogamente al bus di servizio, Griglia di eventi supporta un modello sottoscrittore filtrato in cui una sottoscrizione imposta una regola per gli eventi che desidera ricevere. Griglia di eventi offre una velocità effettiva rapida con una garanzia di 10 milioni di eventi al secondo che consentono il recapito quasi in tempo reale, molto più di quello che il bus di servizio di Azure può generare.

Uno scenario ideale per Griglia di eventi è la profonda integrazione nell'infrastruttura dell'infrastruttura di Azure. Una risorsa di Azure, ad esempio Cosmos DB, può pubblicare eventi predefiniti direttamente in altre risorse di Azure interessate, senza la necessità di codice personalizzato. Griglia di eventi può pubblicare eventi da una sottoscrizione di Azure, un gruppo di risorse o un servizio, offrendo agli sviluppatori un controllo accurato sul ciclo di vita delle risorse cloud. Tuttavia, Griglia di eventi non è limitata ad Azure. Si tratta di una piattaforma aperta che può utilizzare eventi HTTP personalizzati pubblicati da applicazioni o servizi di terze parti e instradare eventi a sottoscrittori esterni.

Quando si pubblicano e sottoscrivono eventi nativi dalle risorse di Azure, non è necessaria alcuna codifica. Con una configurazione semplice, è possibile integrare eventi da una risorsa di Azure a un'altra sfruttando il plumbing predefinito per Argomenti e sottoscrizioni. La figura 4-17 mostra l'anatomia di Griglia di eventi.

Figura 4-17. Anatomia di Griglia di eventi

Una differenza importante tra Griglia di eventi e bus di servizio è il modello di scambio di messaggi sottostante.

Il bus di servizio implementa un modello di pull di stile precedente in cui il sottoscrittore downstream esegue attivamente il polling della sottoscrizione dell'argomento per i nuovi messaggi. Sul lato positivo, questo approccio offre al sottoscrittore il controllo completo del ritmo con cui elabora i messaggi. Controlla quando e quanti messaggi elaborare in un determinato momento. I messaggi non letti rimangono nella sottoscrizione fino a quando non vengono elaborati. Un problema significativo è la latenza tra il momento in cui viene generato l'evento e l'operazione di polling che esegue il pull del messaggio al sottoscrittore per l'elaborazione. Inoltre, il sovraccarico del polling costante per l'evento successivo utilizza risorse e denaro.

EventGrid, tuttavia, è diverso. Implementa un modello push in cui gli eventi vengono inviati ai Gestori eventi ricevuti, fornendo un recapito di eventi quasi in tempo reale. Riduce anche i costi quando il servizio viene attivato solo quando è necessario utilizzare un evento, non continuamente come con il polling. Detto questo, un gestore eventi deve gestire il carico in ingresso e fornire meccanismi di limitazione per proteggersi dal sovraccarico. Molti servizi di Azure che usano questi eventi, ad esempio Funzioni di Azure e App per la logica, offrono funzionalità di scalabilità automatica per gestire carichi aumentati.

Griglia di eventi è un servizio cloud serverless completamente gestito. Ridimensiona in modo dinamico in base al traffico e agli addebiti solo per l'utilizzo effettivo, non per la capacità pre-acquistata. Le prime 100.000 operazioni al mese sono gratuite: operazioni definite come ingresso di eventi (notifiche degli eventi in ingresso), tentativi di recapito delle sottoscrizioni, chiamate di gestione e filtro in base all'oggetto. Con disponibilità del 99,99%, EventGrid garantisce il recapito di un evento entro un periodo di 24 ore, con funzionalità predefinite di ripetizione dei tentativi per il recapito non riuscito. I messaggi non recapitati possono essere spostati in una coda di messaggi non recapitabili per la risoluzione. A differenza del bus di servizio di Azure, Griglia di eventi è ottimizzata per prestazioni veloci e non supporta funzionalità come la messaggistica ordinata, le transazioni e le sessioni.

Streaming di messaggi nel cloud di Azure

Il bus di servizio di Azure e Griglia di eventi offrono un ottimo supporto per le applicazioni che espongono eventi singoli e discreti, ad esempio un nuovo documento, sono stati inseriti in un cosmos DB. Ma cosa accade se il sistema nativo del cloud deve elaborare un flusso di eventi correlati? I flussi di eventi sono più complessi. In genere sono ordinati in base al tempo, correlati e devono essere elaborati come gruppo.

Hub eventi di Azure è una piattaforma di streaming di dati e un servizio di inserimento di eventi che raccoglie, trasforma e archivia gli eventi. È ottimizzato per acquisire i dati di streaming, ad esempio le notifiche di eventi continue generate da un contesto di telemetria. Il servizio è altamente scalabile e può archiviare ed elaborare milioni di eventi al secondo. Illustrato nella figura 4-18, è spesso una porta principale per una pipeline di eventi, che disaccoppia il flusso di inserimento dal consumo di eventi.

Figura 4-18. Hub eventi di Azure

Hub eventi supporta bassa latenza e conservazione del tempo configurabile. A differenza delle code e degli argomenti, Hub eventi mantiene i dati degli eventi dopo la lettura da parte di un consumer. Questa funzionalità consente ad altri servizi di analisi dei dati, interni ed esterni, di riprodurre i dati per ulteriori analisi. Gli eventi archiviati nell'hub eventi vengono eliminati solo alla scadenza del periodo di conservazione, ovvero un giorno per impostazione predefinita, ma configurabile.

Hub eventi supporta protocolli comuni di pubblicazione di eventi, tra cui HTTPS e AMQP. Supporta anche Kafka 1.0. Le applicazioni Kafka esistenti possono comunicare con Hub eventi usando il protocollo Kafka, offrendo un'alternativa alla gestione di cluster Kafka di grandi dimensioni. Molti sistemi open source nativi del cloud abbracciano Kafka.

Hub eventi implementa lo streaming di messaggi tramite un modello consumer partizionato in cui ogni consumer legge solo un subset specifico o una partizione del flusso di messaggi. Questo modello consente una notevole scalabilità orizzontale per l'elaborazione di eventi e fornisce altre funzionalità incentrate sui flussi che non sono disponibili in code e argomenti. Una partizione è una sequenza ordinata di eventi che viene mantenuta in un hub eventi. Man mano che arrivano, i nuovi eventi vengono aggiunti alla fine di questa sequenza. La figura 4-19 mostra il partizionamento in un hub eventi.

Figura 4-19. Partizionamento dell'hub eventi

Invece di leggere dalla stessa risorsa, ogni gruppo di consumer legge in un subset o una partizione del flusso di messaggi.

Per le applicazioni native del cloud che devono trasmettere un numero elevato di eventi, Hub eventi di Azure può essere una soluzione affidabile e conveniente.

PrecedenteSuccessivo