Descrivere gli scenari basati su messaggio ed eventi
La prima decisione nella progettazione dell'architettura dell'applicazione consiste nel pianificare la comunicazione dei componenti dell'applicazione. La definizione della strategia dei componenti consente di scegliere il servizio di Azure appropriato.
Si supponga di progettare l'architettura per un'applicazione di condivisione video per il miglioramento della casa per Tailwind Traders. Si vuole che l'applicazione sia quanto più affidabile e scalabile possibile. Si prevede di usare tecnologie di Azure per creare una solida infrastruttura di comunicazione. Prima di poter scegliere i servizi di Azure appropriati, è necessario progettare il modo in cui ogni componente dell'applicazione comunica con gli altri componenti. Per ogni tipo di comunicazione, è possibile scegliere una tecnologia di Azure diversa.
Informazioni su messaggi ed eventi
La maggior parte dei componenti dell'applicazione comunica inviando messaggi o eventi. Azure offre vari servizi per supportare le diverse strategie di comunicazione.
Messaggi
Verranno ora esaminate le caratteristiche dei messaggi.
I messaggi contengono dati non elaborati prodotti da un componente e utilizzati da un altro componente.
Un messaggio contiene i dati stessi, non solo un riferimento a tali dati.
Il componente di invio si aspetta che la destinazione elabori il contenuto del messaggio in un certo modo. L'integrità dell'intero sistema può dipendere dal fatto che sia il mittente sia il destinatario eseguano un processo specifico.
Si supponga che un utente carichi un nuovo video usando l'app per la condivisione di video per dispositivi mobili. L'app per dispositivi mobili deve inviare tale video all'API Web eseguita in Azure. È necessario inviare il file del video e non solo un avviso che indica che è stato aggiunto un nuovo video. L'app per dispositivi mobili prevede che l'API Web archivi il nuovo video nel database e lo renda disponibile ad altri utenti.
Eventi
Si esaminerà ora in modo più approfondito gli eventi .
Gli eventi hanno un peso minore dei messaggi e vengono spesso usati per le comunicazioni broadcast.
Un evento ha due componenti, un server di pubblicazione e sottoscrittori. L'autore di eventi invia l'evento. I sottoscrittori di eventi ricevono eventi.
Con gli eventi, i componenti di ricezione decidono in genere a quali comunicazioni sono interessati e sottoscrivono quindi gli eventi. Un intermediario gestisce il processo di sottoscrizione. L'intermediario usa servizi come Griglia di eventi di Azure o Hub eventi di Azure. Quando gli editori inviano un evento, l'intermediario instrada l'evento alle parti interessate. Questo modello è noto come architettura di pubblicazione-sottoscrizione ed è il più diffuso.
Gli eventi hanno le caratteristiche seguenti:
Un evento è una notifica leggera che indica che si è verificato qualcosa.
Un evento può essere inviato a più destinatari o a nessuno.
Un autore di eventi non prevede alcuna previsione sulle azioni da parte di un componente ricevente.
Un evento è spesso destinato a una distribuzione estesa o hanno molti sottoscrittori per ogni publisher.
Un evento è un'unità discreta non correlata ad altri eventi, ma un evento potrebbe far parte di una serie correlata e ordinata.
Aspetti da prendere in considerazione quando si scelgono messaggi o eventi
Esaminare gli scenari seguenti relativi a quando scegliere la comunicazione tra messaggi o eventi per l'architettura dell'applicazione per Tailwind Traders.
Prendere in considerazione messaggi ed eventi. Non è raro che un'applicazione implementi sia eventi che messaggi. Un'app può usare eventi per alcuni componenti e funzioni e messaggi per altri componenti. Scegliere ogni servizio di Azure per soddisfare le esigenze specifiche di ogni componente dell'app.
Prendere in considerazione le aspettative del mittente. Se il componente di invio nell'applicazione prevede che la destinazione elabori il componente in modo specifico, è consigliabile implementare i messaggi. Se il componente mittente nell'applicazione non ha requisiti per il componente di destinazione, è possibile implementare eventi anziché messaggi.
Considerare la comunicazione garantita. Se si sta creando un'applicazione distribuita e si vuole garantire che tutte le comunicazioni vengano elaborate, è consigliabile usare i messaggi. In una comunicazione di messaggio, è previsto che il mittente del messaggio e il destinatario completino le attività.
Prendere in considerazione la comunicazione temporanea. Effimero indica che la comunicazione viene eliminata se non sono presenti destinatari per la sottoscrizione. Se l'applicazione non richiede sottoscrittori o azioni da alcun ricevitore, prendere in considerazione l'uso di eventi.