Delen via

Patronen voor berichtreplicatietaken

  • Artikel

In het overzicht van federatie- en replicatorfuncties wordt uitgelegd wat de redenen zijn voor en de basiselementen van replicatietaken. Het is raadzaam om uzelf vertrouwd te maken met deze taken voordat u verdergaat met dit artikel.

In dit artikel beschrijven we de implementatierichtlijnen voor verschillende patronen die in de overzichtssectie zijn gemarkeerd.

Replicatie

Het replicatiepatroon kopieert berichten van de ene wachtrij of het volgende onderwerp naar een andere bestemming, zoals een Event Hub. De berichten worden doorgestuurd zonder wijzigingen aan te brengen in de nettolading van het bericht.

De implementatie van dit patroon wordt gedekt door de berichtreplicatie van en naar het Azure Service Bus-voorbeeld .

Volgordes en volgordebehoud

Het replicatiemodel is niet gericht op het behouden van de absolute volgorde van berichten van een bronwachtrij of onderwerp in een doelwachtrij of -onderwerp, maar is, indien nodig, gericht op het behouden van de relatieve volgorde van berichten waarvoor de toepassing dit vereist. De toepassing schakelt dit in door sessieondersteuning in te schakelen voor de bronentiteit en het groeperen van gerelateerde berichten met dezelfde sessiesleutel.

De vooraf gebouwde replicatiefuncties voor sessiebewust zorgen ervoor dat berichtenreeksen met dezelfde sessie-id die zijn opgehaald uit een bronentiteit, worden verzonden naar de doelwachtrij of het onderwerp als een batch in de oorspronkelijke volgorde en met dezelfde sessie-id.

Door de service toegewezen metagegevens

De door de service toegewezen metagegevens van een bericht dat is verkregen uit de bronwachtrij of het oorspronkelijke onderwerp, de oorspronkelijke tijd en het volgnummer, worden vervangen door nieuwe service toegewezen waarden in de doelwachtrij of het doelonderwerp, maar met de standaardreplicatietaken die in onze voorbeelden worden verstrekt, blijven de oorspronkelijke waarden behouden in gebruikerseigenschappen: repl-enqueue-time (ISO8601 tekenreeks) en repl-sequence.

Deze eigenschappen zijn van het type tekenreeks en bevatten de tekenreekswaarde van de respectieve oorspronkelijke eigenschappen. Als het bericht meerdere keren wordt doorgestuurd, worden de door de service toegewezen metagegevens van de onmiddellijke bron toegevoegd aan de reeds bestaande eigenschappen, met waarden gescheiden door puntkomma's.

Failover

Als u replicatie gebruikt voor herstel na noodgevallen, om te beschermen tegen regionale beschikbaarheidsberichten in de Service Bus-service of tegen netwerkonderbrekingen, moet voor dergelijke fouten een failover van de ene wachtrij of het volgende onderwerp worden uitgevoerd, waarbij producenten en/of consumenten het secundaire eindpunt moeten gebruiken.

Voor alle failoverscenario's wordt ervan uitgegaan dat de vereiste elementen van de naamruimten structureel identiek zijn, wat betekent dat wachtrijen en onderwerpen identiek zijn benoemd en dat regels voor handtekeningen voor gedeelde toegang en/of op rollen gebaseerd toegangsbeheer op dezelfde manier worden ingesteld. U kunt een secundaire naamruimte maken (en bijwerken) door de richtlijnen te volgen voor het verplaatsen van naamruimten en het weglaten van de opschoonstap.

Als u wilt afdwingen dat producenten en consumenten overschakelen, moet u de informatie over welke naamruimte beschikbaar moet worden gemaakt voor zoeken op een locatie die gemakkelijk te bereiken en bij te werken is. Als producenten of consumenten frequente of permanente fouten ondervinden, moeten ze die locatie raadplegen en hun configuratie aanpassen. Er zijn talloze manieren om die configuratie te delen, maar we wijzen op twee in het volgende: DNS en bestandsshares.

Failoverconfiguratie op basis van DNS

Een kandidaatbenadering is het opslaan van de informatie in DNS SRV-records in een DNS die u beheert en verwijst naar de respectieve wachtrij- of onderwerpeindpunten. Houd er rekening mee dat message Hubs niet toestaat dat de eindpunten rechtstreeks worden gealiaseerd met CNAME-records. Dit betekent dat u DNS gebruikt als een tolerant opzoekmechanisme voor eindpuntadressen en niet om IP-adresgegevens rechtstreeks om te zetten.

Stel dat u de eigenaar bent van het domein example.com en, voor uw toepassing, een zone test.example.com. Voor twee alternatieve Service Bus maakt u nu twee andere geneste zones en een SRV-record in elk.

De SRV-records zijn, volgens de algemene conventie, voorafgegaan door _azure_servicebus._amqp en bevatten twee eindpuntrecords: één voor AMQP-over-TLS op poort 5671 en één voor AMQP-over-WebSockets op poort 443, die beide verwijzen naar het Service Bus-eindpunt van de naamruimte die overeenkomt met de zone.

Zone SRV-record
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

In de zone van uw toepassing maakt u vervolgens een CNAME-vermelding die verwijst naar de onderliggende zone die overeenkomt met uw primaire wachtrij of onderwerp:

CNAME-record Alias
servicebus.test.example.com sb1.test.example.com

Met behulp van een DNS-client die het uitvoeren van query's op CNAME- en SRV-records expliciet toestaat (de ingebouwde clients van Java en .NET alleen eenvoudige omzetting van namen naar IP-adressen toestaan), kunt u vervolgens het gewenste eindpunt omzetten. Met DnsClient.NET is de opzoekfunctie bijvoorbeeld:

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('.');
}

De functie retourneert de doelhostnaam die is geregistreerd voor poort 5671 van de zone die momenteel is gealiaseerd met de CNAME, zoals hierboven wordt weergegeven.

Voor het uitvoeren van een failover moet de CNAME-record worden bewerkt en naar de alternatieve zone worden verwijst.

Het voordeel van het gebruik van DNS, en met name Azure DNS, is dat Azure DNS-gegevens wereldwijd worden gerepliceerd en daarom bestand zijn tegen storingen in één regio.

Deze procedure is vergelijkbaar met de werking van de Service Bus Geo-DR , maar volledig onder uw eigen controle en werkt ook met actieve/actieve scenario's.

Failoverconfiguratie op basis van bestandsshares

Het eenvoudigste alternatief voor het gebruik van DNS voor het delen van eindpuntgegevens is het plaatsen van de naam van het primaire eindpunt in een bestand zonder opmaak en het bestand uit een infrastructuur die robuust is tegen storingen en nog steeds updates toestaat.

Als u al een maximaal beschikbare website-infrastructuur uitvoert met globale beschikbaarheid en inhoudsreplicatie, voegt u daar een dergelijk bestand toe en publiceert u het bestand opnieuw als er een switch nodig is.

Samenvoeging

Het samenvoegpatroon heeft een of meer replicatietaken die verwijzen naar één doel, mogelijk gelijktijdig met reguliere producenten die ook berichten naar hetzelfde doel verzenden.

Variaties van dit patroon zijn:

  • Twee of meer replicatiefuncties verzamelen gelijktijdig berichten van afzonderlijke bronnen en verzenden ze naar hetzelfde doel.
  • Nog een replicatiefunctie voor het ophalen van berichten van een bron terwijl het doel ook rechtstreeks door producenten wordt gebruikt.
  • Het vorige patroon, maar berichten die zijn gespiegeld tussen twee of meer onderwerpen, wat resulteert in die onderwerpen die dezelfde berichten bevatten, ongeacht waar berichten worden geproduceerd.

De eerste twee patroonvariaties zijn triviaal en verschillen niet van normale replicatietaken.

In het laatste scenario moeten al gerepliceerde berichten niet opnieuw worden gerepliceerd. De techniek wordt gedemonstreerd en uitgelegd in het actieve/actieve voorbeeld.

Editor

Het editorpatroon is gebaseerd op het replicatiepatroon , maar berichten worden gewijzigd voordat ze worden doorgestuurd. Voorbeelden voor dergelijke wijzigingen zijn:

  • Transcodering : als de berichtinhoud (ook wel 'body' of 'payload' genoemd) afkomstig is van de bron die is gecodeerd met behulp van de Apache Avro-indeling of een eigen serialisatie-indeling, maar de verwachting van het systeem dat eigenaar is van het doel, is dat de inhoud JSON wordt gecodeerd, een transcoderingsreplicatietaak eerst deserialiseert de nettolading van Apache Avro in een objectgrafiek in het geheugen en die grafiek vervolgens serialiseert in de JSON indeling voor het bericht dat wordt doorgestuurd. Transcodering omvat ook inhoudscompressie - en decompressietaken.
  • Transformatie : berichten die gestructureerde gegevens bevatten, moeten die gegevens mogelijk opnieuw worden aangepast voor eenvoudiger verbruik door downstreamgebruikers. Dit kan betrekking hebben op het platmaken van geneste structuren, het verwijderen van overbodige gegevenselementen of het opnieuw vormgeven van de nettolading zodat deze exact in een bepaald schema past.
  • Batchverwerking : berichten kunnen in batches (meerdere berichten in één overdracht) van een bron worden ontvangen, maar moeten singly worden doorgestuurd naar een doel of omgekeerd. Een taak kan daarom meerdere berichten doorsturen op basis van één invoerberichtoverdracht of een set berichten samenvoegen die vervolgens samen worden overgebracht.
  • Validatie : berichtgegevens van externe bronnen moeten vaak worden gecontroleerd of ze voldoen aan een set regels voordat ze kunnen worden doorgestuurd. De regels kunnen worden uitgedrukt met behulp van schema's of code. berichten die niet in overeenstemming zijn, kunnen worden verwijderd, met het probleem dat in logboeken wordt vermeld, of kunnen worden doorgestuurd naar een speciale doelbestemming om ze verder te verwerken.
  • Verrijking : berichtgegevens die afkomstig zijn van sommige bronnen, vereisen mogelijk verrijking met verdere context, zodat deze bruikbaar zijn in doelsystemen. Dit kan betrekking hebben op het opzoeken van referentiegegevens en het insluiten van die gegevens met het bericht, of het toevoegen van informatie over de bron die bekend is bij de replicatietaak, maar niet in de berichten.
  • Filteren : sommige berichten die afkomstig zijn van een bron, moeten mogelijk worden ingehouden vanuit het doel op basis van een bepaalde regel. Met een filter wordt het bericht getest op basis van een regel en wordt het bericht verwijderd als het bericht niet overeenkomt met de regel. Dubbele berichten filteren door bepaalde criteria te observeren en volgende berichten met dezelfde waarden te verwijderen, is een vorm van filteren.
  • Routering en partitionering : sommige replicatietaken kunnen twee of meer alternatieve doelen toestaan en regels definiëren waarvoor het replicatiedoel wordt gekozen voor een bepaald bericht op basis van de metagegevens of inhoud van het bericht. Een speciale vorm van routering is partitioneren, waarbij de taak expliciet partities toewijst in één replicatiedoel op basis van regels.
  • Cryptografie : een replicatietaak moet mogelijk inhoud ontsleutelen die afkomstig is van de bron en/of inhoud versleutelen die wordt doorgestuurd naar een doel, en/of het moet mogelijk de integriteit van inhoud en metagegevens verifiëren ten opzichte van een handtekening die in het bericht wordt uitgevoerd, of een dergelijke handtekening bijvoegen.
  • Attestation : een replicatietaak kan metagegevens, mogelijk beveiligd door een digitale handtekening, toevoegen aan een bericht dat bevestigt dat het bericht is ontvangen via een specifiek kanaal of op een bepaald tijdstip.
  • Koppelen: een replicatietaak kan handtekeningen toepassen op reeksen berichten, zodat de integriteit van de reeks wordt beveiligd en ontbrekende berichten kunnen worden gedetecteerd.

Al deze patronen kunnen worden geïmplementeerd met behulp van Azure Functions, met behulp van de message Hubs-trigger voor het verkrijgen van berichten en de wachtrij- of onderwerpuitvoerbinding voor het leveren ervan.

Routering

Het routeringspatroon is gebaseerd op het replicatiepatroon , maar in plaats van één bron en één doel te hebben, heeft de replicatietaak meerdere doelen, zoals hier wordt geïllustreerd 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 
    }
}

De routeringsfunctie houdt rekening met de metagegevens van het bericht en/of de nettolading van het bericht en kiest vervolgens een van de beschikbare bestemmingen om naar te verzenden.

Volgende stappen