Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Azure Service Bus spiegato: code, argomenti, dead-letter e messaggistica affidabile (Doppiaggio IA)

Transcript

Azure Service Bus spiegato: code, argomenti, dead-letter e messaggistica affidabile (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Pronto per dieci giorni di Microsoft 365, Copilot, IA, Azure
0:04
Speaker 2: e le persone che plasmano il futuro del lavoro? Questo gennaio,
0:09
Speaker 2: M365 con ritorna e puntiamo ancora più in alto. Unisciti
0:13
Speaker 2: a noi per sessioni dal vivo, demo concrete e conoscenze
0:15
Speaker 2: pratiche da MVP ed esperti del settore. Niente slide generiche,
0:20
Speaker 2: niente gergo infinito. Affrontiamo le vere sfide. Copilot Studio, agenti IA, Fabric, Sicurezza,
0:27
Speaker 2: Governance e Automazione. Che tu sia un professionista IT, uno
0:31
Speaker 2: sviluppatore o un leader aziendale, ci sono sessioni pensate per te.
0:35
Speaker 2: Con 10 giorni interi potrai esplorare tecnologie diverse e connetterti
0:39
Speaker 2: con una community globale. Segui in diretta e porta intuizioni
0:42
Speaker 2: pratiche nella tua organizzazione. Gennaio 2027? 10 giorni, un'unica Microsoft Community.
0:49
Speaker 2: Le iscrizioni sono aperte. Assicurati il tuo posto oggi stesso.
0:54
Speaker 2: Vai su m3sencentreinco. com. net Iscriviti ora su m365con. net e ci vediamo
1:03
Speaker 2: in diretta a gennaio. Immagina di dover inviare un messaggio
1:06
Speaker 2: a un collega. Vai da lui, gli consegni un biglietto
1:09
Speaker 2: e aspetti che legga e risponda. Funziona bene quando siete
1:12
Speaker 2: entrambi presenti. Ma se fosse in riunione, a pranzo o
1:14
Speaker 2: in vacanza per una settimana, non puoi andare avanti con
1:18
Speaker 2: il lavoro finché non risponde. È esattamente quello che succede
1:20
Speaker 2: quando due app comunicano direttamente. Un'app invia una richiesta e attende.
1:24
Speaker 2: Se l'altra app è lenta, occupata o in crash, la
1:26
Speaker 2: prima resta bloccata. Gli sviluppatori chiamano questo accoppiamento stretto. Le
1:30
Speaker 2: due app sono legate tra loro. Se una si rompe,
1:32
Speaker 2: anche l'altra si rompe. In un sistema con decine di servizi,
1:35
Speaker 2: è un disastro. La soluzione è mettere un intermediario. Un
1:38
Speaker 2: buffer digitale che accetta i messaggi quando il mittente è
1:40
Speaker 2: pronto e li conserva finché il ricevente non può lavorare.
1:42
Speaker 2: Questo intermediario si chiama Message Broker. E Azure Service Bus
1:45
Speaker 2: è la versione Microsoft di questo intermediario. Cos'è esattamente un
1:48
Speaker 2: Message Broker? Quindi, cos'è davvero un Message Broker? È un
1:52
Speaker 2: software che si posiziona tra le app e gestisce lo
1:53
Speaker 2: scambio dei messaggi. Il mittente invia un messaggio al broker
1:56
Speaker 2: e prosegue il suo lavoro. Nessuna attesa. Il ricevente preleva
1:59
Speaker 2: il messaggio quando è pronto. Le due parti non comunicano
2:02
Speaker 2: mai direttamente. Parlano solo con il broker. Chiamano questo disaccoppiamento
2:05
Speaker 2: ed è proprio il punto cruciale. Quando due app sono
2:07
Speaker 2: disaccoppiate possono fallire indipendentemente. Il ricevente va in crash e
2:10
Speaker 2: il mittente non se ne accorge nemmeno. Il messaggio resta
2:12
Speaker 2: semplicemente nel broker net. Quando il ricevente torna online riprende
2:15
Speaker 2: da dove aveva lasciato. Nessuna perdita di dati, nessun errore
2:17
Speaker 2: da gestire. Possono anche scalare in modo indipendente. Se il
2:20
Speaker 2: mittente riceve un flusso intenso di traffico può continuare a
2:22
Speaker 2: inviare messaggi alla velocità che preferisce. Il broker assorbe il picco.
2:25
Speaker 2: Il ricevente elabora al proprio ritmo. 10 messaggi al minuto, 10.000.
2:30
Speaker 2: E se devi aggiornare un'app, puoi farlo senza mettere fuori
2:32
Speaker 2: uso l'intero sistema. L'altra parte non noterà alcuna differenza. Ecco
2:35
Speaker 2: un modo semplice per pensare. Sei in un ufficio e
2:37
Speaker 2: devi consegnare un documento a qualcuno al terzo piano, ma
2:40
Speaker 2: è in riunione. Potresti aspettare fuori dalla sala riunioni, oppure
2:44
Speaker 2: lasciare il documento alla reception. L'addetto lo prende, tu torni
2:47
Speaker 2: alla tua scrivania e il documento viene consegnato quando la
2:49
Speaker 2: persona è libera. La reception è il tuo message broker.
2:52
Speaker 2: Accetta il messaggio, lo conserva al sicuro e lo consegna
2:55
Speaker 2: quando il destinatario è pronto. Azure Service Pass è la
2:58
Speaker 2: versione completamente gestita di Microsoft di questa reception. Completamente gestita
3:02
Speaker 2: significa che non devi preoccuparti dell'infrastruttura. Nessun server da aggiornare,
3:05
Speaker 2: nessun disco rigido da sostituire, nessun backup da pianificare. Microsoft
3:08
Speaker 2: gestisce tutto questo. Devi solo creare uno spazio di nomi,
3:10
Speaker 2: configurare code e argomenti e iniziare a inviare messaggi. È
3:13
Speaker 2: una messaggistica serverless. Paghi per ciò che usi e non
3:15
Speaker 2: pensi mai all'hardware sottostante. Quindi come organizzi i messaggi di
3:18
Speaker 2: questo intermediario? Utilizza due strutture principali, code e argomenti. Iniziamo
3:22
Speaker 2: con quella più semplice. Anatomia di un messaggio. Dunque abbiamo
3:25
Speaker 2: esaminato le strutture principali. Ora parliamo di ciò che viaggia
3:27
Speaker 2: al loro interno, il messaggio stesso. Pensa a un messaggio
3:32
Speaker 2: in Azure Service Bus come a un contenitore con due
3:35
Speaker 2: parti principali, il corpo e i metadati. Il corpo è
3:39
Speaker 2: il tuo dato effettivo, ciò che stai cercando di inviare.
3:41
Speaker 2: Di solito è formattato come JSON o XML, anche il
3:44
Speaker 2: testo è semplice. I dati binari sono supportati, ma in
3:46
Speaker 2: pratica il JSON è il formato più comune. È leggibile
3:49
Speaker 2: dagli umani, facile da gestire, ogni linguaggio di programmazione lo supporta.
3:52
Speaker 2: I metadati sono la parte più interessante. Ogni messaggio include
3:55
Speaker 2: una serie di proprietà di sistema che ServiceBus assegna automaticamente.
3:59
Speaker 2: Elementi come un ID messaggio univoco, un timestamp di accodamento
4:02
Speaker 2: e un numero di sequenza che indica la posizione nella coda.
4:06
Speaker 2: Questi sono i gestiti del sistema. Non imposti tu, sono
4:08
Speaker 2: semplicemente lì. Tuttavia puoi anche aggiungere le tue proprietà personalizzate.
4:11
Speaker 2: Si tratta di coppie chiave valore definite da te come
4:14
Speaker 2: regione cliente con valore Europa o totale ordine con 29,99,99
4:19
Speaker 2: o priorità con alta. Queste proprietà personalizzate sono fondamentali per
4:23
Speaker 2: il filtraggio nel Ricordi i filtri di sottoscrizione di cui
4:26
Speaker 2: abbiamo parlato? Funzionano a confronto dei dati con queste proprietà personalizzate.
4:29
Speaker 2: Imposti il filtro che dice ricevi solo i messaggi in
4:32
Speaker 2: cui la regione del cliente è Europa e la sottoscrizione
4:35
Speaker 2: usa la proprietà personalizzata per decidere se accettare il messaggio.
4:38
Speaker 2: Ci sono dei limiti alle dimensioni dei messaggi. Nel livello
4:40
Speaker 2: standard un messaggio può pesare fino a 256 KB. È
4:44
Speaker 2: sufficiente per la maggior parte dei dati aziendali un ordine
4:46
Speaker 2: a profilo cliente o una conferma di pagamento, tutti ben
4:48
Speaker 2: sotto quel limite. Se hai bisogno di più spazio, il
4:50
Speaker 2: livello premium supporta messaggi fino a 1 MB. Tuttavia, se
4:53
Speaker 2: invii regolarmente dati più grandi, probabilmente non dovresti inserirli in
4:56
Speaker 2: un messaggio. Archivi i dati voluminosi altrove e inserisci un
4:59
Speaker 2: riferimento nel messaggio. È il modello più comune. La consegna
5:01
Speaker 2: pianificata è una funzionalità utile. Invii un messaggio ora, ma
5:04
Speaker 2: dici a Service Bus di non renderlo visibile fino a
5:06
Speaker 2: un momento specifico nel futuro. Immagina di voler inviare un'email
5:09
Speaker 2: di promemoria tra 24 ore. Invii il messaggio ora con
5:12
Speaker 2: un orario di accodamento programmato fissato per domani. Service Bus
5:14
Speaker 2: lo trattiene, rimane invisibile e nessuno può leggerlo. Poi, al
5:17
Speaker 2: momento esatto programmato, appare nella coda come se fosse appena
5:20
Speaker 2: stato inviato. È perfetto per flussi di lavoro basati sul tempo, promemoria,
5:23
Speaker 2: timeout ed elaborazione di ritardo. Il ciclo di vita di
5:26
Speaker 2: un messaggio funziona così. Per prima cosa viene inviato alla
5:28
Speaker 2: coda argomento. Service bus lo archiva in modo permanente, scritto
5:31
Speaker 2: su uno storage a tripla ridondanza. Quindi un ricevitore richiede
5:33
Speaker 2: un messaggio. Service bus lo blocca, in modo che nessun
5:36
Speaker 2: altro ricevitore possa prendere. Il ricevitore elabora il messaggio. Se
5:39
Speaker 2: tutto va bene, il ricevitore chiama complete. Service bus elimina
5:42
Speaker 2: il messaggio. Se qualcosa va storto, il ricevitore può chiamare abandon.
5:46
Speaker 2: Il blocco viene rilasciato e il messaggio torna nella coda
5:48
Speaker 2: per un'altra tentativa. Se il messaggio continua a fallire, alla
5:50
Speaker 2: fine viene spostato nella coda dei messaggi non recapitabili. Ne
5:53
Speaker 2: parleremo nel prossimo passaggio. Il punto chiave è che i
5:55
Speaker 2: messaggi sono permanenti. Non scompaiono se un ricevitore si arresta
5:57
Speaker 2: in mano. Non vanno persi se la rete smette di funzionare.
6:00
Speaker 2: Rimangono in service bus archiviati in sicurezza affinché non vengono
6:02
Speaker 2: elaborati correttamente e spostati esplicitamente nella coda dei messaggi non recapitabili.
6:05
Speaker 2: Quella affidabilità è il motivo principale per cui si utilizza
6:07
Speaker 2: un message broker. Funzionalità avanzate che fanno la differenza. Ora
6:12
Speaker 2: parliamo delle funzionalità che trasformano una semplice coda di messaggi
6:14
Speaker 2: in una piattaforma su cui puoi contare iniziando dalla coda
6:16
Speaker 2: dei messaggi non recapitabili Abbiamo menzionato prima che i messaggi
6:19
Speaker 2: che continuano a fallire vengono infine spostati altrove. Quell'altrove è
6:22
Speaker 2: la coda dei messaggi non recapitabili di Adletter. Pensala come
6:25
Speaker 2: una cella di detenzione. Quando un messaggio supera il numero
6:27
Speaker 2: massimo di tentativi di consegna o scade perché il suo
6:29
Speaker 2: tempo di vita è terminato e non scompare semplicemente, viene
6:32
Speaker 2: spostato in una sottocoda separata all'interno della stessa coda o sottoscrizione.
6:35
Speaker 2: Puoi esaminare quei messaggi, capire cosa non ha funzionato e
6:38
Speaker 2: decidere cosa fare. Magari i dati erano formattati male e
6:40
Speaker 2: devi correggerli. Magari la logica di elaborazione è un bug.
6:43
Speaker 2: Magari il sistema Val era inattivo e vuoi riprovare più tardi.
6:46
Speaker 2: Ad Adletter qui ti offre un piano di riserva. Nulla
6:48
Speaker 2: va perso silenziosamente. Ora chiariamo un malinteso comune sulle sessioni.
6:52
Speaker 2: Per impostazione predefinita, Zero Service Bus non garantisce che i
6:55
Speaker 2: messaggi vengano elaborati in ordine. So che abbiamo detto che
6:58
Speaker 2: le code sono fifo, primo entrare, primo uscire. Ed è
7:00
Speaker 2: vero per come arrivano i messaggi, ma l'ordine di elaborazione
7:02
Speaker 2: è un'altra storia. Se hai più consumer che prelevano dalla
7:05
Speaker 2: stessa coda, un messaggio richiede più tempo di un altro
7:07
Speaker 2: per essere elaborato, o il secondo potrebbe finire prima del primo.
7:11
Speaker 2: L'ordine va perso. Le sessioni risolvono questo problema. Una sessione
7:14
Speaker 2: raggruppa insieme i messaggi correlati. Assegni un ID sessione a
7:16
Speaker 2: ogni messaggio, come un numero d'ordine cliente o un ID
7:19
Speaker 2: stanza di workflow. Tutti i messaggi con lo stesso ID
7:22
Speaker 2: sessione vengono elaborati dallo stesso consumer, uno alla volta, in ordine.
7:25
Speaker 2: Nessun altro consumer può toccarli. Questo garantisce un'elaborazione FIFO rigorosa
7:29
Speaker 2: all'interno di quella sessione. Sessioni diverse possono ancora essere elaborate
7:32
Speaker 2: in parallelo da consumer diversi. In questo modo mantieni il
7:35
Speaker 2: throughput preservando l'ordine importante. Il rilevamento dei duplicati è un'altra
7:38
Speaker 2: ottima funzione. A volte la rete è dentro. La tua
7:40
Speaker 2: applicazione invia un messaggio, ma la risposta viene persa. Quindi
7:44
Speaker 2: la tua app lo invia di nuovo pensando che il
7:45
Speaker 2: primo non sia mai arrivato. Senza il rilevamento dei duplicati,
7:48
Speaker 2: quel messaggio verrebbe elaborato due volte. Con esso, Service Bus
7:51
Speaker 2: ricorda l'ID del messaggio per una finestra, configurabile solitamente fino
7:54
Speaker 2: a 30 giorni. Se vede di nuovo lo stesso ID messaggio,
7:57
Speaker 2: scarta silenziosamente il duplicato. Il destinatario non saprà mai che
8:00
Speaker 2: c'è stato un nuovo tentativo. Le transazioni ti consentono di
8:02
Speaker 2: raggruppare più operazioni in un'unica unità top. Magari devi prendere
8:05
Speaker 2: un messaggio da una coda, elaborarlo e inviare un risultato
8:07
Speaker 2: a un'altra coda. Se un passaggio fallisce, vuoi che tutto
8:10
Speaker 2: venga annullato. Il messaggio torna alla prima coda. Il risultato
8:13
Speaker 2: non viene mai inviato. Tu rimani coerente. Questo è fondamentale
8:16
Speaker 2: per i sistemi finanziari, dove un'elaborazione parziale è peggiore di
8:19
Speaker 2: nessuna elaborazione. L'inoltro automatico ti consente di concatenare. I messaggi
8:23
Speaker 2: arrivano a una coda e vengono automaticamente inoltrati a un'altra.
8:26
Speaker 2: È utile per costruire pipeline di elaborazione. Un messaggio grezzo arriva,
8:29
Speaker 2: viene convalidato e poi inoltrato a una coda diversa per
8:31
Speaker 2: il lavoro del repro. La prima coda rimane pulita. La
8:34
Speaker 2: seconda coda gestisce il lavoro pesante. Il differimento ti permette
8:36
Speaker 2: di saltare temporaneamente un messaggio. Magari ricevi un messaggio, ma
8:39
Speaker 2: i dati a cui fa riferimento non sono ancora pronti.
8:41
Speaker 2: Puoi differirlo. Rimane la coda, ma diventa invisibile. In seguito,
8:45
Speaker 2: usando il numero di sequenza, puoi recuperarlo ed elaborarlo al
8:47
Speaker 2: momento giusto. Queste funzionalità sono ciò che distingue una semplice
8:50
Speaker 2: coda da un sistema su cui costruire la tua azienda.
8:53
Speaker 2: Service bus rispetto alle alternative. Quindi quando scegliere service bus
8:56
Speaker 2: invece di altro? Lascia che ti spiego. Azure Storage Queues
8:59
Speaker 2: sono le opzioni più semplici, economiche, veloci e facili da configurare.
9:03
Speaker 2: Ma sono limitate. I messaggi arrivano al massimo a 64
9:06
Speaker 2: KB e non hai argomenti, sessioni, dead letter o transazioni.
9:11
Speaker 2: Sono ottime per code di lavoro in background, di base
9:13
Speaker 2: dove devi solo scaricare il lavoro, ma se ti servono
9:15
Speaker 2: le funzionalità avanzate di cui abbiamo parlato le supererai presto.
9:18
Speaker 2: Event Hub si è pensato per qualcosa di completamente diverso,
9:21
Speaker 2: lo streaming di eventi ad alto throughput. Pensa a milioni
9:24
Speaker 2: di eventi al secondo, dispositivi IoT o log di applicazioni.
9:27
Speaker 2: Non è un message broker, è una pipeline in gestione dati.
9:30
Speaker 2: Quindi non lo useresti per flussi di lavoro transazionali. Si
9:32
Speaker 2: usa quando devi acquisire ed elaborare enormi flussi di dati.
9:36
Speaker 2: Event Grid è l'opzione leggera, un sistema PubSub per trigger
9:39
Speaker 2: basati su eventi, Quando un blob viene caricato nello storage,
9:43
Speaker 2: Event Grid può attivare un Azure Function. Quando viene creata
9:45
Speaker 2: una risorsa, può notificare altri servizi. È veloce, economico e
9:49
Speaker 2: perfetto per scenari reattivi, ma non è una coda. Non
9:51
Speaker 2: conserva i messaggi per un'elaborazione successiva, quindi se il ricevitore
9:54
Speaker 2: è inattivo l'evento va perso. Ora, Service Bus si colloca
9:57
Speaker 2: esattamente nel mezzo. Ha le ricche funzionalità di un broker aziendale.
10:00
Speaker 2: aziendale senza la complessità di gestirne uno. Se ti servono
10:03
Speaker 2: coded letters, sessioni, transazioni, argomenti con filtri o consegna garantita,
10:07
Speaker 2: Service Bus è la scelta giusta. E Kafka? Quella è
10:10
Speaker 2: una conversazione del tutto diversa. Service Bus serve per comandi
10:13
Speaker 2: e flussi di lavoro aziendali, mentre Kafka serve per streaming
10:15
Speaker 2: di eventi e analisi. Molti grandi sistemi usano entrambi. Service
10:19
Speaker 2: Bus gestisce la messaggistica operativa, Kafka gestisce la pipeline dei dati.
10:22
Speaker 2: Sono complementari, non in competizione. Ecco una semplice regola in Piri.
10:25
Speaker 2: Se ti chiedi se questo messaggio è stato elaborato correttamente,
10:29
Speaker 2: usa Service Bus. Se ti chiedi se posso riprodurre il
10:31
Speaker 2: flusso di eventi della scorsa settimana, usa Kafka. Strumenti diversi
10:35
Speaker 2: per avere diversi. Casi d'uso in mondo reale. Prendiamolo concreto
10:38
Speaker 2: con alcuni esempi. Ecco come funziona Service Bus in produzione.
10:41
Speaker 2: Partiamo dall'e-commerce. Un cliente effettua un ordine su un sito web.
10:45
Speaker 2: Il server web riceve l'ordine e pubblica immediatamente un singolo
10:47
Speaker 2: messaggio in una coda di service bus poi dice al
10:49
Speaker 2: cliente grazie il tuo ordine è confermato. Il cliente ottiene
10:52
Speaker 2: una risposta rapida senza attesia. Dietro le quinte un pool
10:55
Speaker 2: di servizi worker preleva i messaggi dalla coda. Un worker
10:58
Speaker 2: elabora il pagamento, un altro controlla l'inventario, un altro prepara
11:00
Speaker 2: l'etichetta di spedizione. Ogni worker prende il messaggio successivo, svolge
11:04
Speaker 2: il suo compito e passa oltre. Il cliente non vede
11:06
Speaker 2: nulla di tutto questo, vede solo la conferma. Questo è
11:09
Speaker 2: il classico modello di elaborazione asincrona. Feedback istantaneo per l'utente,
11:12
Speaker 2: lavoro pesante in background. I sistemi finanziari portano tutto ciò
11:15
Speaker 2: a un livello superiore. L'elaborazione dei pagamenti richiede una consegna garantita.
11:18
Speaker 2: Non puoi perdere una transazione o elaborarla due volte. Hai
11:21
Speaker 2: bisogno di ordinamento e transazione. ServiceBus ti offre tutto questo.
11:24
Speaker 2: Un metodo di pagamento arriva, viene elaborato e il risultato
11:27
Speaker 2: viene inviato a un'altra coda. Se qualcosa fallisce, l'intera operazione
11:30
Speaker 2: viene annullata e così il denaro non si sposta mai
11:31
Speaker 2: in modo errato. È qui che ServiceBus eccella. Non solo
11:34
Speaker 2: spostare dati, ma spostarli in sicurezza. Ora pensa al fan- out multiservizi.
11:38
Speaker 2: Un nuovo cliente si registra sulla tua piattaforma. Vuoi che
11:40
Speaker 2: il sistema CRM lo sappia, che il sistema di marketing
11:42
Speaker 2: invia un'email di benvenuto e che il team di supporto
11:44
Speaker 2: crea un ticket? Invece di chiamare tre servizi diversi pubblichi
11:47
Speaker 2: un messaggio in un argomento chiamato cliente registrato. Ogni servizio
11:50
Speaker 2: ha la sua sottoscrizione. La sottoscrizione CRM prende ogni messaggio,
11:55
Speaker 2: quella di marketing filtra solo i nuovi clienti, quella di
11:57
Speaker 2: supporto filtra solo i clienti premium. Un messaggio ha tre reazioni.
12:01
Speaker 2: E se aggiungi un quarto servizio in seguito crei semplicemente
12:03
Speaker 2: una nuova sottoscrizione. L'invitente non cambia mai. Le aziende di
12:06
Speaker 2: logistica lo usano su scala massiccia. Immagina un sistema di
12:08
Speaker 2: tracciamento pacchi in cui centinaia di migliaia di camion inviano
12:11
Speaker 2: aggiornamenti sulla posizione ogni pochi secondi. Ogni aggiornamento o messaggio
12:14
Speaker 2: ed aggiornamenti di ogni pacco devono essere elaborati in ordine.
12:17
Speaker 2: Non puoi elaborare l'aggiornamento consegnato prima di quello in consegna.
12:20
Speaker 2: Le sessioni gestiscono questo aspetto. Ogni pacco tiene il suo
12:23
Speaker 2: ID sessione e tutti gli aggiornamenti per quel pacco passano
12:25
Speaker 2: attraverso la stessa sessione in ordine. Pacchi diversi possono comunque
12:28
Speaker 2: essere elaborati in parallelo. Milioni di pacchi, miliardi di aggiornamenti,
12:32
Speaker 2: tutto gestito in modo affidabile. Le architetture microservizi usano Service
12:35
Speaker 2: Bus come spina dorsale per la comunicazione. I servizi non
12:38
Speaker 2: si chiamano direttamente tra loro, scambiano messaggi. Il servizio A
12:42
Speaker 2: invia un comando a una coda, il servizio B lo
12:44
Speaker 2: preleva ed esegue il lavoro. Il servizio C pubblica un
12:47
Speaker 2: evento su un topic e i servizi D ed E
12:49
Speaker 2: reagiscono ognuno a modo proprio. Nessuna chiamata diretta, nessun accoppiamento.
12:53
Speaker 2: Ogni servizio può essere aggiornato, scalato o sostituito senza toccare
12:56
Speaker 2: gli altri. Ed ecco un modello che si vede nelle
12:57
Speaker 2: aziende più datate. Hanno un sistema legacy locale che non
13:00
Speaker 2: può essere sostituito facilmente ma vogliono usare moderni servizi cloud.
13:04
Speaker 2: Quindi colmano il divario con il service bus. Sistema Legacy
13:06
Speaker 2: invia messaggi a una coda e le applicazioni cloud li consumano.
13:10
Speaker 2: Vecchio sistema non sa mai che sta comunicando con il
13:12
Speaker 2: cloud e il cloud non sa mai che sta comunicando
13:13
Speaker 2: con un vecchio sistema. Il service bus si posiziona nel mezzo,
13:16
Speaker 2: traducendo e inoltrando. La consegna pianificata gestisce i lavori basati
13:19
Speaker 2: sul tempo. Invia un'email di promemoria tra 24 ore. Puoi
13:22
Speaker 2: scadere questa prenotazione tra 30 minuti se non confermata. Genera
13:25
Speaker 2: un report settimanale ogni lunedì alle 8. Invi il messaggio
13:28
Speaker 2: ora con un orario di consegna futuro e il service
13:30
Speaker 2: bus lo trattiene e lo rilascia esattamente al momento giusto.
13:33
Speaker 2: Niente cronjob, niente timer in background, solo un messaggio con
13:36
Speaker 2: un timer. Il filo conduttore in tutti questi esempi è
13:38
Speaker 2: lo stesso. Il mitente non aspetta il destinatario e il
13:41
Speaker 2: destinatario non deve essere online quando il messaggio viene inviato.
13:44
Speaker 2: Sono disaccoppiati. Questo disaccoppiamento rende l'intero sistema più resiliente, più
13:47
Speaker 2: scalabile e più facile da modificare. Quadro generale, perché tutto
13:51
Speaker 2: si incastra. Quindi cos'è esattamente il service bus? È la
13:54
Speaker 2: spina dorsale che permette a servizi indipendenti di comunicare in
13:56
Speaker 2: modo affidabile senza dipendere uno dall'altro. Tre parole lo riassumono. Disaccoppiare,
14:00
Speaker 2: bufferizzare e instradare. Disaccoppiare significa che i servizi non hanno
14:03
Speaker 2: bisogno di conoscersi troppo, conoscono solo la coda e il topic.
14:06
Speaker 2: Ciò significa che puoi modificare un servizio senza rompere gli altri,
14:09
Speaker 2: scalarne uno senza influenzare il resto e distribuire aggiornamenti a
14:12
Speaker 2: uno mentre gli altri continuano a funzionare. Bufferizzare significa che
14:15
Speaker 2: quando il traffico aumenta la coda assorbe il carico. Il
14:17
Speaker 2: mittente continua a inviare a piena velocità mentre il destinatario
14:20
Speaker 2: elabora il proprio ritmo, così nessuno va in crash o
14:22
Speaker 2: viene sopraffatto e il buffer spiana i picchi e colma
14:24
Speaker 2: le valli. In stradare significa che le code inviano messaggio
14:28
Speaker 2: a un singolo consumatore, mentre i topic trasmettono a molti
14:31
Speaker 2: e i filtri assicurano che ogni consumatore riceva solo ciò
14:33
Speaker 2: di cui ha bisogno, così il messaggio trova la sua
14:34
Speaker 2: strada nel posto giusto automaticamente. Le code gestiscono la distribuzione
14:38
Speaker 2: del lavoro point to point e i topic gestiscono la
14:40
Speaker 2: trasmissione a molti consumatori. Funzionalità avanzate gestiscono i casinini. Fallimenti
14:44
Speaker 2: vanno nell'accolto dei messaggi non recapitabili, l'ordinamento delle sessioni utenti,
14:47
Speaker 2: i duplicati vengono rilevati, le transazioni mantengono tutto coerente.