Share via

Modelli di attività di replica dei messaggi

  • Articolo

Panoramica della federazione e panoramica delle funzioni di replicator illustrano la razionalità per e gli elementi di base delle attività di replica e si consiglia di acquisire familiarità con loro prima di continuare con questo articolo.

In questo articolo vengono fornite informazioni dettagliate sull'implementazione per diversi modelli evidenziati nella sezione panoramica.

Replica

Il modello di replica copia i messaggi da una coda o un argomento all'altro oppure da una coda o da un argomento a un'altra destinazione, ad esempio un hub eventi. I messaggi vengono inoltrati senza apportare modifiche al payload del messaggio.

L'implementazione di questo modello è coperta dalla replica dei messaggi da e verso e da bus di servizio di Azure esempio.

Sequenze e conservazione degli ordini

Il modello di replica non mira a mantenere l'ordine assoluto di messaggi di una coda di origine o di un argomento in una coda o in un argomento di destinazione, ma si concentra, ogni volta che è necessario, per mantenere l'ordine relativo dei messaggi in cui l'applicazione lo richiede. L'applicazione consente di abilitare il supporto della sessione per l'entità di origine e raggruppare i messaggi correlati con la stessa chiave di sessione.

Le funzioni di replica predefinite con riconoscimento della sessione garantiscono che le sequenze di messaggi con lo stesso ID sessione recuperate da un'entità di origine vengano inviate nella coda di destinazione o nell'argomento come batch nella sequenza originale e con lo stesso ID sessione.

Metadati assegnati al servizio

I metadati assegnati al servizio di un messaggio ottenuto dalla coda di origine o dall'argomento, il numero di tempo e sequenza originale, vengono sostituiti da nuovi valori assegnati dal servizio nella coda o nell'argomento di destinazione, ma con le attività di replica predefinite fornite negli esempi, i valori originali vengono mantenuti nelle proprietà utente: repl-enqueue-time (stringa ISO8601) e repl-sequence.

Queste proprietà sono di tipo stringa e contengono il valore stringa stringato delle rispettive proprietà originali. Se il messaggio viene inoltrato più volte, i metadati assegnati al servizio dell'origine immediata vengono aggiunti alle proprietà già esistenti, con valori separati da punti e virgola.

Failover

Se si usa la replica per scopi di ripristino di emergenza, per proteggere i messaggi di disponibilità a livello di area nel servizio bus di servizio o contro le interruzioni di rete, qualsiasi scenario di errore richiederà l'esecuzione di un failover da una coda o un argomento al successivo, comunicando ai produttori e/o ai consumer di usare l'endpoint secondario.

Per tutti gli scenari di failover si presuppone che gli elementi necessari degli spazi dei nomi siano strutturalmente identici, ovvero che le code e gli argomenti siano denominati in modo identico e che le regole di firma di accesso condiviso e/o le regole di controllo degli accessi in base al ruolo siano configurate nello stesso modo. È possibile creare (e aggiornare) uno spazio dei nomi secondario seguendo le indicazioni per lo spostamento degli spazi dei nomi e omettendo il passaggio di pulizia.

Per forzare i produttori e i consumer a passare, è necessario rendere disponibili le informazioni sullo spazio dei nomi da usare per la ricerca in una posizione facile da raggiungere e aggiornare. Se i produttori o i consumatori riscontrano errori frequenti o persistenti, devono consultare tale posizione e modificare la configurazione. Esistono numerosi modi per condividere tale configurazione, ma vengono indicati due nei seguenti modi: DNS e condivisioni file.

Configurazione del failover basato su DNS

Un approccio candidato consiste nel contenere le informazioni nei record SRV DNS in un DNS controllato e puntare ai rispettivi endpoint di coda o argomento. Tenere presente che hub messaggi non consente agli endpoint di essere direttamente aliasati con record CNAME, il che significa che si userà DNS come meccanismo di ricerca resiliente per gli indirizzi endpoint e non per risolvere direttamente le informazioni sull'indirizzo IP.

Si supponga di possedere il dominio example.com e, per l'applicazione, una zona test.example.com. Per due bus di servizio alternativo, si creeranno ora due zone nidificate e un record SRV in ognuna.

I record SRV sono, seguendo la convenzione comune, preceduti da _azure_servicebus._amqp e contengono due record endpoint: uno per AMQP-over-TLS sulla porta 5671 e uno per AMQP-over-WebSocket sulla porta 443, entrambi puntando all'endpoint del bus di servizio dello spazio dei nomi corrispondente alla zona.

Zona Record SRV
sb1.test.example.com _azure_servicebus._amqp.sb1.test.example.com
1 1 5671 sb1-test-example-com.servicebus.windows.net
2 2 443 sb1-test-example-com.servicebus.windows.net
sb2.test.example.com _azure_servicebus._amqp.sb1.test.example.com
1 1 5671 sb2-test-example-com.servicebus.windows.net
2 2 443 sb2-test-example-com.servicebus.windows.net

Nella zona dell'applicazione verrà quindi creata una voce CNAME che punta alla zona subordinata corrispondente alla coda o all'argomento primario:

Record CNAME Alias
servicebus.test.example.com sb1.test.example.com

Usando un client DNS che consente di eseguire query su record CNAME e SRV in modo esplicito (i client predefiniti di Java e .NET consentono solo la risoluzione semplice dei nomi agli indirizzi IP), è quindi possibile risolvere l'endpoint desiderato. Con DnsClient.NET, ad esempio, la funzione di ricerca è:

static string GetServiceBusName(string aliasName)
{
    const string SrvRecordPrefix = "_azure_servicebus._amqp.";
    LookupClient lookup = new LookupClient();

    return (from CNameRecord alias in (lookup.Query(aliasName, QueryType.CNAME).Answers)
            from SrvRecord srv in lookup.Query(SrvRecordPrefix + alias.CanonicalName, QueryType.SRV).Answers
            where srv.Port == 5671
            select srv.Target).FirstOrDefault()?.Value.TrimEnd('.');
}

La funzione restituisce il nome host di destinazione registrato per la porta 5671 della zona attualmente aliasata con CNAME, come illustrato sopra.

L'esecuzione di un failover richiede la modifica del record CNAME e la punta alla zona alternativa.

Il vantaggio di usare DNS, e in particolare DNS di Azure, è che le informazioni DNS di Azure vengono replicate a livello globale e quindi resilienti rispetto alle interruzioni a area singola.

Questa procedura è simile al funzionamento del geo-ripristino di emergenza del bus di servizio, ma completamente sotto il proprio controllo e funziona anche con scenari attivi/attivi.

Configurazione del failover basato su condivisione file

L'alternativa più semplice all'uso di DNS per la condivisione delle informazioni sull'endpoint consiste nell'inserire il nome dell'endpoint primario in un file di testo normale e servire il file da un'infrastruttura affidabile rispetto alle interruzioni e consente comunque gli aggiornamenti.

Se si esegue già un'infrastruttura del sito Web a disponibilità elevata con la disponibilità globale e la replica del contenuto, aggiungendo un file di questo tipo e ripubblicando il file se è necessario un commutatore.

Unione

Il modello di unione include una o più attività di replica che puntano a una destinazione, possibilmente simultaneamente con i produttori regolari che inviano messaggi alla stessa destinazione.

Le varianti di questo modello sono:

  • Due o più funzioni di replica acquisiscono simultaneamente messaggi da origini separate e li inviano alla stessa destinazione.
  • Una funzione di replica che acquisisce messaggi da un'origine mentre la destinazione viene usata direttamente dai produttori.
  • Il modello precedente, ma i messaggi con mirroring tra due o più argomenti, causando tali argomenti contenenti gli stessi messaggi, indipendentemente dalla posizione in cui vengono prodotti i messaggi.

Le prime due varianti di modello sono semplici e non differiscono dalle attività di replica normale.

L'ultimo scenario richiede l'esclusione di messaggi già replicati da replicare. La tecnica è illustrata e spiegata nell'esempio attivo/attivo.

Editor

Il modello di editor si basa sul modello di replica , ma i messaggi vengono modificati prima che vengano inoltrati. Gli esempi per tali modifiche sono:

  • Transcoding : se il contenuto del messaggio (noto anche come "corpo" o "payload") arriva dall'origine codificato usando il formato Apache Avro o un formato di serializzazione proprietario, ma l'aspettativa del sistema proprietario della destinazione è che il contenuto sia codificato JSON , un'attività di transcoding replica deserializzerà prima il payload da Apache Avro in un grafico a oggetti in memoria e quindi serializza tale grafico nel file JSON formato per il messaggio che viene inoltrato. La trascodazione include anche attività di compressione e decompressione del contenuto.
  • Trasformazione : i messaggi che contengono dati strutturati possono richiedere la modifica di tali dati per un utilizzo più semplice da parte dei consumer downstream. Ciò può comportare un funzionamento simile a strutture nidificate, modificare elementi di dati extranei o rimodellare il payload in modo da adattare esattamente uno schema specifico.
  • Batching : i messaggi possono essere ricevuti in batch (più messaggi in un singolo trasferimento) da un'origine, ma devono essere inoltrati a una destinazione o viceversa. Un'attività può quindi inoltrare più messaggi in base a un singolo trasferimento di messaggi di input o aggregare un set di messaggi che vengono quindi trasferiti insieme.
  • Convalida : i dati dei messaggi provenienti da origini esterne spesso devono essere controllati per verificare se sono in conformità con un set di regole prima che vengano inoltrati. Le regole possono essere espresse usando schemi o codice. i messaggi che non devono essere conformi possono essere eliminati, con il problema annotato nei log o possono essere inoltrati a una destinazione di destinazione speciale per gestirli ulteriormente.
  • Arricchimento : i dati dei messaggi provenienti da alcune origini possono richiedere l'arricchimento con un ulteriore contesto per poterli usare nei sistemi di destinazione. Ciò può comportare la ricerca di dati di riferimento e l'incorporamento dei dati con il messaggio o l'aggiunta di informazioni sull'origine nota all'attività di replica, ma non contenute nei messaggi.
  • Filtro : alcuni messaggi che arrivano da un'origine potrebbero dover essere mantenuti dalla destinazione in base a una regola. Un filtro verifica il messaggio su una regola e elimina il messaggio se il messaggio non corrisponde alla regola. Filtrando i messaggi duplicati osservando determinati criteri e eliminando i messaggi successivi con gli stessi valori è una forma di filtro.
  • Routing e partizionamento : alcune attività di replica possono consentire due o più destinazioni alternative e definire regole per cui viene scelta la destinazione di replica per qualsiasi messaggio specifico in base ai metadati o al contenuto del messaggio. Una forma speciale di routing è partizionamento, in cui l'attività assegna in modo esplicito le partizioni in una destinazione di replica in base alle regole.
  • Crittografia : un'attività di replica può dover decrittografare il contenuto proveniente dall'origine e/o crittografare il contenuto inoltrato in seguito a una destinazione e/o potrebbe dover verificare l'integrità del contenuto e dei metadati relativi a una firma portata nel messaggio o collegare tale firma.
  • Attestazione : un'attività di replica può collegare metadati, potenzialmente protetti da una firma digitale, a un messaggio che attesta che il messaggio è stato ricevuto tramite un canale specifico o in un momento specifico.
  • Concatenamento : un'attività di replica può applicare firme alle sequenze di messaggi in modo che l'integrità della sequenza sia protetta e i messaggi mancanti possano essere rilevati.

Tutti questi modelli possono essere implementati usando Funzioni di Azure, usando il trigger hub messaggi per l'acquisizione di messaggi e l'associazione di output della coda o dell'argomento per la distribuzione.

Routing

Il modello di routing si basa sul modello di replica, ma invece di avere un'origine e una destinazione, l'attività di replica ha più destinazioni, illustrate qui in C#:

[FunctionName("SBRouter")]
public static async Task Run(
    [ServiceBusTrigger("source", Connection = "serviceBusConnectionAppSetting")] ServiceBusReceivedMessage[] messages,
    [ServiceBusOutput("dest1", Connection = "serviceBusConnectionAppSetting")] IAsyncCollector<dynamic> output1,
    [ServiceBusOutput("dest2", Connection = "serviceBusConnectionAppSetting")] IAsyncCollector<dynamic> output2,
    ILogger log)
{
    foreach (Message messageData in messages)
    {
        // send to output1 or output2 based on criteria 
    }
}

La funzione di routing considererà i metadati del messaggio e/o il payload del messaggio e quindi selezionare una delle destinazioni disponibili da inviare.

Passaggi successivi