Modello bridge di messaggistica

Questo articolo descrive il modello Messaging Bridge, una tecnica che è possibile usare per integrare sistemi diversi basati su infrastrutture di messaggistica diverse.

Contesto e problema

Molte organizzazioni e carichi di lavoro possono avere inavvertitamente sistemi IT che usano più infrastrutture di messaggistica come Microsoft Message Queueing (MSMQ), RabbitMQ, bus di servizio di Azure e Amazon SQS. Questo problema può verificarsi a causa di fusioni, acquisizioni o a causa dell'estensione dei sistemi locali correnti ai componenti ospitati nel cloud per un'efficienza dei costi e della facilità di manutenzione.

Gli sviluppatori potrebbero risolvere questa sfida modificando i sistemi integrati per comunicare usando servizi Web basati su HTTP. Tuttavia, questo approccio presenta svantaggi, tra cui:

• I sistemi devono essere modificati aggiungendo un client HTTP su un lato e un gestore di richieste HTTP sull'altro. I sistemi devono quindi essere ridiscati e ridistribuiti.
• Gli endpoint HTTP devono essere ospitati, che aggiungono complessità quando si rendono sicuri e a disponibilità elevata i servizi Web.
• Problemi frequenti di connettività di rete che richiedono meccanismi di ripetizione personalizzati.

Soluzione

Se i sistemi integrati sono costituiti da componenti che comunicano scambiando messaggi, il modello Messaging Bridge migliora l'integrazione e riduce gli svantaggi.

In questo scenario, ogni sistema si connette a un'infrastruttura di messaggistica. Per integrarsi in infrastrutture di messaggistica diverse, introdurre un componente bridge che si connette a due o più infrastrutture di messaggistica contemporaneamente. Il bridge esegue il pull dei messaggi da uno e li inserisce nell'altro senza modificare il payload.

I sistemi integrati non devono riconoscere gli altri o il ponte. Il sistema mittente è configurato per inviare messaggi specifici a una coda designata nell'infrastruttura di messaggistica nativa. Il bridge preleva i messaggi e li inoltra a un'altra coda in un'infrastruttura di messaggistica diversa in cui il sistema ricevitore li preleva.

Vantaggi

• Non è necessario modificare i sistemi integrati tramite il bridge di messaggistica. Idealmente, gli endpoint non sono consapevoli del fatto che i messaggi vengono bridge.
• L'integrazione è più affidabile rispetto all'alternativa HTTP a causa del meccanismo di recapito dei messaggi at-least-once.
• Gli scenari di migrazione possono essere più flessibili. Ad esempio, gli endpoint possono essere migrati da un'infrastruttura di messaggistica a un'altra perché la pianificazione consente invece di tutte contemporaneamente.

Svantaggi

• Le funzionalità avanzate di una o entrambe le tecnologie di messaggistica potrebbero non essere disponibili nella route bridged.
• Il percorso bridged deve considerare le limitazioni di entrambe le tecnologie. Ad esempio, la dimensione massima del messaggio potrebbe essere di 4 MB in MSMQ, ma solo 64 KB nelle code Archiviazione di Azure.

Considerazioni e problemi

Quando si implementa il modello Messaging Bridge, tenere presente quanto segue:

• Se uno dei sistemi integrati si basa su transazioni distribuite, ad esempio Microsoft Distributed Transaction Coordinator (DTC), per la correttezza, è necessario implementare un meccanismo di deduplicazione nel bridge.

• Se uno dei sistemi integrati non usa alcuna infrastruttura di messaggistica e non può essere modificato, è possibile creare il bridge di messaggistica tra l'infrastruttura usata dall'altro sistema e una coda emulata di SQL Server. Il sistema legacy può inviare messaggi usando la funzionalità Change Data Capture per SQL Server per eseguire il push delle modifiche in una tabella code dedicata. Il bridge può inoltrare questi messaggi all'infrastruttura di messaggistica effettiva.

• È possibile usare una singola coda in ogni infrastruttura di messaggistica, designata come coda di bridging. In questa topologia configurare il sistema di invio per l'uso di tale coda specifica come destinazione per i tipi di messaggio inviati all'altro sistema. È anche possibile usare più coppie di code in ogni infrastruttura di messaggistica, in modo che il mittente non sia a conoscenza del bridge. Viene creata una coda shadow per ogni coda di destinazione nell'infrastruttura di messaggistica del sistema di destinazione. Il bridge inoltra i messaggi tra le code shadow e le relative controparti.

• Per soddisfare i contratti di servizio di disponibilità desiderati, potrebbe essere necessario aumentare il numero di istanze del bridge di messaggistica usando l'approccio Consumer concorrenti .

• I normali componenti di elaborazione dei messaggi usano il modello Di ripetizione dei tentativi per gestire gli errori temporanei. Il limite di contatori dei tentativi consente ai componenti di rilevare i messaggi non elaborabili e rimuoverli dalla coda per sbloccare l'elaborazione. Il bridge potrebbe richiedere criteri di ripetizione diversi per impedire l'identificazione falsa dei messaggi come non elaborabili in caso di errore dell'infrastruttura. È possibile usare il modello interruttore per sospendere l'inoltro.

Quando usare questo modello

Usare il modello Messaging Bridge quando è necessario:

• Integrare i sistemi esistenti con una necessità minima di modifica.
• Integrare applicazioni legacy che non possono usare altre tecnologie di messaggistica.
• Estendere le applicazioni locali esistenti con componenti ospitati nel cloud.
• Connettere sistemi con distribuzione geografica quando la connessione Internet non è stabile.
• Eseguire la migrazione di un singolo sistema distribuito da un'infrastruttura di messaggistica a un'altra in modo incrementale senza la necessità di eseguire la migrazione dell'intero sistema in un unico sforzo.

Questo modello potrebbe non essere adatto se:

• Almeno uno dei sistemi coinvolti si basa su una funzionalità di un'infrastruttura di messaggistica non presente nell'altra.
• L'integrazione è sincrona e il sistema di avvio richiede una risposta immediata.
• L'integrazione presenta requisiti funzionali o non funzionali specifici, ad esempio problemi di sicurezza o privacy.
• Il volume di dati per l'integrazione supera la capacità del sistema di messaggistica o rende la messaggistica una soluzione costosa al problema.

Progettazione del carico di lavoro

Un architetto deve valutare il modo in cui il modello Messaging Bridge può essere usato nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:

Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.

Esempio

È disponibile un'applicazione scritta in un framework .NET per la gestione della pianificazione dei dipendenti ospitata in locale. L'applicazione è ben strutturata con componenti separati che comunicano tramite MSMQ. L'applicazione funziona e il team del carico di lavoro non ha intenzione di riscriverlo. È necessario creare un nuovo consumer dei dati di pianificazione per soddisfare le esigenze aziendali e la strategia IT richiede di creare un nuovo software come applicazioni native del cloud per ottimizzare i costi e i tempi di consegna.

L'architettura asincrona basata su code ha lavorato per il team del carico di lavoro in passato, quindi il team userà lo stesso approccio architetturale, ma con la tecnologia moderna, bus di servizio. Il team del carico di lavoro non vuole introdurre comunicazioni sincrone tra il cloud e la distribuzione locale per ridurre la latenza o l'indisponibilità di uno che influisce sull'altro.

Il team decide di usare il modello Messaging Bridge per connettere i due sistemi. Il modello è costituito da due parti. Una parte riceve messaggi dalla coda MSMQ esistente e li inoltra a bus di servizio. L'altra parte accetta i messaggi dal bus di servizio e li inoltra alla coda MSMQ esistente.

Quando il team di implementazione usa questo approccio, usa l'infrastruttura esistente nell'applicazione esistente per l'integrazione con i nuovi componenti. L'applicazione esistente non è consapevole del fatto che i nuovi componenti sono ospitati in Azure. Analogamente, i nuovi componenti comunicano con l'applicazione legacy nello stesso modo in cui comunicano tra loro, inviando bus di servizio messaggi. Il bridge inoltra i messaggi tra i due sistemi.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Rob Bagby | Responsabile contenuto dell'architettura principale
• Kyle Baley | Software Engineer
• Udi Dahan | Fondatore e CEO di Particolare Software
• Chad Kittel | Principal Software Engineer
• Bryan Lamos | Relazioni tra sviluppatori
• Szymon Pobiega | Ingegnere

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Descrizione del modello di messaggistica Bridge dalla community dei modelli di integrazione aziendale.
• Informazioni su come implementare un bridge di messaggistica nel framework Spring Java.
• Il bridge QPid può essere usato per collegare le tecnologie di messaggistica abilitate per AMQP.
• Il bridge di messaggistica NServiceBus è un'implementazione .NET di un bridge da coda a coda che supporta un'ampia gamma di infrastrutture di messaggistica, tra cui MSMQ, bus di servizio e Archiviazione code di Azure.
• NServiceBus.Router è un progetto open source che implementa il modello Messaging Bridge. Consente anche il bridging di più di due tecnologie in una singola istanza e offre funzionalità avanzate di routing dei messaggi.

Risorse correlate

• Il modello Consumer concorrenti garantisce che l'implementazione del bridge di messaggistica possa gestire il carico.
• Il modello Di ripetizione dei tentativi consente al bridge di messaggistica di gestire gli errori temporanei.
• Il modello interruttore consente di risparmiare risorse quando uno dei due lati del bridge subisce tempi di inattività.