Condividi tramite

Modelli di attività di replica dei messaggi

  • Articolo

La panoramica della federazione e la panoramica delle funzioni del replicatore illustrano la logica per e gli elementi di base delle attività di replica ed è consigliabile acquisire familiarità con loro prima di continuare con questo articolo.

In questo articolo vengono illustrate in dettaglio le linee guida per l'implementazione per diversi modelli evidenziati nella sezione panoramica.

Replica

Il modello di replica copia i messaggi da una coda o argomento alla successiva oppure da una coda o 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 bus di servizio di Azure esempio.

Sequenze e conservazione degli ordini

Il modello di replica non mira a mantenere l'ordine assoluto dei messaggi di una coda di origine o di un argomento in una coda o 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 lo abilita abilitando il supporto della sessione per l'entità di origine e raggruppando i messaggi correlati con la stessa chiave di sessione.

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

Metadati assegnati al servizio

I metadati assegnati dal servizio di un messaggio ottenuto dalla coda di origine o dall'argomento, l'ora di accodamento originale e il numero di sequenza, 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 (ISO8601 stringa) e repl-sequence.

Tali proprietà sono di tipo string e contengono il valore stringaficato delle rispettive proprietà originali. Se il messaggio viene inoltrato più volte, i metadati assegnati dal servizio dell'origine immediata vengono accodati alle proprietà già esistenti, con valori separati da punto e virgola.

Failover

Se si usa la replica a scopo di ripristino di emergenza, per proteggersi dai messaggi di disponibilità a livello di area nel servizio bus di servizio o dalle interruzioni di rete, qualsiasi scenario di errore di questo tipo richiederà l'esecuzione di un failover da una coda o argomento alla successiva, indicando ai produttori e/o ai consumer di usare l'endpoint secondario.

Per tutti gli scenari di failover, si presuppone che gli elementi obbligatori degli spazi dei nomi siano strutturalmente identici, vale a dire che le code e gli argomenti sono 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 vengono 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 consumer riscontrano errori frequenti o persistenti, devono consultare tale posizione e regolare la configurazione. Esistono diversi modi per condividere tale configurazione, ma vengono indicati due nei modi seguenti: DNS e condivisioni file.

Configurazione del failover basato su DNS

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

Si supponga di essere proprietari del dominio example.com e, per l'applicazione, di una zona test.example.com. Per due bus di servizio alternative, verranno ora create due zone annidate e un record SRV in ognuno.

I record SRV sono, seguendo la convenzione comune, preceduti _azure_servicebus._amqp da 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 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 si creerà quindi 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 con alias con CNAME, come illustrato in precedenza.

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

Il vantaggio dell'uso di DNS e, in particolare di DNS di Azure, è che le informazioni DNS di Azure vengono replicate a livello globale e quindi resilienti in caso di interruzioni a singola area.

Questa procedura è simile al funzionamento del ripristino di emergenza geografico 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 del DNS per la condivisione delle informazioni sugli endpoint consiste nell'inserire il nome dell'endpoint primario in un file di testo normale e gestire il file da un'infrastruttura affidabile contro le interruzioni e consente comunque gli aggiornamenti.

Se si esegue già un'infrastruttura del sito Web a disponibilità elevata con disponibilità globale e replica del contenuto, aggiungere tale file e ripubblicare il file se è necessario un commutatore.

Unire

Il modello di unione ha una o più attività di replica che puntano a una destinazione, possibilmente contemporaneamente ai producer normali 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.
  • Un'altra funzione di replica che acquisisce messaggi da un'origine mentre la destinazione viene usata direttamente dai producer.
  • Il modello precedente, ma i messaggi con mirroring tra due o più argomenti, determinando tali argomenti contenenti gli stessi messaggi, indipendentemente dalla posizione in cui vengono generati 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 dalla replica. La tecnica viene illustrata e illustrata nell'esempio attivo/attivo.

Editor

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

  • Transcodifica: se il contenuto del messaggio (detto anche "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 venga codificato in formato JSON, un'attività di replica transcodifica deserializza prima il payload da Apache Avro in un grafico di oggetti in memoria e quindi serializza il grafico nel codice JSON formato per il messaggio che viene inoltrato. La transcodifica include anche attività di compressione e decompressione del contenuto.
  • Trasformazione: i messaggi che contengono dati strutturati possono richiedere la rielaborazione dei dati per facilitare l'utilizzo da parte dei consumer downstream. Questo può comportare operazioni come l'appiattimento di strutture annidate, l'eliminazione di elementi di dati estranei o la modifica del payload per adattarsi esattamente a uno schema specifico.
  • Invio in batch: i messaggi possono essere ricevuti in batch (più messaggi in un singolo trasferimento) da un'origine, ma devono essere inoltrati in modo singly 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 verificati se sono conformi a 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 contesto aggiuntivo per renderli utilizzabili nei sistemi di destinazione. Ciò può comportare la ricerca dei 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 provenienti da un'origine potrebbero dover essere trattenuti dalla destinazione in base a una regola. Un filtro testa il messaggio in base a una regola e elimina il messaggio se il messaggio non corrisponde alla regola. Filtrare i messaggi duplicati osservando determinati criteri ed 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 è il 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 potrebbe dover decrittografare il contenuto proveniente dall'origine e/o crittografare il contenuto inoltrato a una destinazione e/o deve verificare l'integrità del contenuto e dei metadati relativi a una firma inserita nel messaggio o allegare tale firma.
  • Attestazione : un'attività di replica può allegare 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 a sequenze di messaggi in modo che l'integrità della sequenza sia protetta e che sia possibile rilevare messaggi mancanti.

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

Definizione dei percorsi di trasferimento

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 scegli una delle destinazioni disponibili a cui inviare.

Passaggi successivi