Läs på engelska

Dela via

Mönster för meddelandereplikeringsuppgifter

  • Artikel

Översikten över federationsöversikten och replikeringsfunktionerna förklarar grunderna för och de grundläggande elementen i replikeringsuppgifterna, och vi rekommenderar att du bekantar dig med dem innan du fortsätter med den här artikeln.

I den här artikeln beskriver vi implementeringsvägledningen för flera av de mönster som markerats i översiktsavsnittet.

Replikering

Replikeringsmönstret kopierar meddelanden från en kö eller ett ämne till nästa, eller från en kö eller ett ämne till något annat mål som en händelsehubb. Meddelandena vidarebefordras utan att göra några ändringar i meddelandets nyttolast.

Implementeringen av det här mönstret omfattas av meddelandereplikeringen till och från Azure Service Bus-exemplet .

Sekvenser och ordningsbevarande

Replikeringsmodellen syftar inte till att bevara den absoluta ordningen för meddelanden i en källkö eller ett ämne i en målkö eller ett ämne, utan fokuserar, när det behövs, på att bevara den relativa ordningen på meddelanden där programmet kräver det. Programmet aktiverar detta genom att aktivera sessionsstöd för källentiteten och gruppera relaterade meddelanden med samma sessionsnyckel.

De sessionsmedvetna fördefinierade replikeringsfunktionerna säkerställer att meddelandesekvenser med samma sessions-ID som hämtats från en källentitet skickas till målkön eller ämnet som en batch i den ursprungliga sekvensen och med samma sessions-ID.

Tjänsttilldelade metadata

Tjänsttilldelade metadata för ett meddelande som hämtas från källkön eller ämnet, den ursprungliga kötiden och sekvensnumret, ersätts av nya tjänsttilldelade värden i målkön eller ämnet, men med standardreplikeringsuppgifterna som anges i våra exempel bevaras de ursprungliga värdena i användaregenskaperna: repl-enqueue-time (ISO8601 sträng) och repl-sequence.

Dessa egenskaper är av typen sträng och innehåller det strängifierade värdet för respektive ursprungliga egenskaper. Om meddelandet vidarebefordras flera gånger läggs de tjänsttilldelade metadata för den omedelbara källan till i de redan befintliga egenskaperna, med värden avgränsade med semikolon.

Redundans

Om du använder replikering i haveriberedskapssyfte, för att skydda mot regionala tillgänglighetsmeddelanden i Service Bus-tjänsten eller mot nätverksavbrott, kräver ett sådant fel att du utför en redundansväxling från en kö eller ett ämne till nästa, vilket uppmanar producenter och/eller konsumenter att använda den sekundära slutpunkten.

För alla redundansscenarier antas det att de nödvändiga elementen i namnrymderna är strukturellt identiska, vilket innebär att köer och ämnen är identiskt namngivna och att regler för signatur för delad åtkomst och/eller rollbaserade regler för åtkomstkontroll konfigureras på samma sätt. Du kan skapa (och uppdatera) ett sekundärt namnområde genom att följa riktlinjerna för att flytta namnområden och utelämna rensningssteget.

För att tvinga producenter och konsumenter att växla måste du göra informationen om vilket namnområde som ska användas tillgängligt för sökning på en plats som är lätt att nå och uppdatera. Om producenter eller konsumenter stöter på frekventa eller beständiga fel bör de konsultera platsen och justera sin konfiguration. Det finns många sätt att dela den konfigurationen, men vi påpekar två i följande: DNS och filresurser.

DNS-baserad redundanskonfiguration

En kandidatmetod är att lagra informationen i DNS SRV-poster i en DNS som du styr och peka på respektive kö eller ämnesslutpunkter. Tänk på att meddelandehubbar inte tillåter att dess slutpunkter direkt aliaseras med CNAME-poster, vilket innebär att du använder DNS som en elastisk uppslagsmekanism för slutpunktsadresser och inte för att direkt matcha IP-adressinformation.

Anta att du äger domänen example.com och för ditt program en zon test.example.com. För två alternativa Service Bus skapar du nu ytterligare två kapslade zoner och en SRV-post i var och en.

SRV-posterna är, enligt vanlig konvention, prefixade med _azure_servicebus._amqp och innehåller två slutpunktsposter: en för AMQP-over-TLS på port 5671 och en för AMQP-over-WebSockets på port 443, som båda pekar på Service Bus-slutpunkten för namnområdet som motsvarar zonen.

Zon SRV-post
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

I programmets zon skapar du sedan en CNAME-post som pekar på den underordnade zonen som motsvarar din primära kö eller ditt ämne:

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

Med hjälp av en DNS-klient som gör det möjligt att köra frågor mot CNAME- och SRV-poster explicit (de inbyggda klienterna i Java och .NET tillåter endast enkel matchning av namn till IP-adresser) kan du sedan matcha önskad slutpunkt. Med DnsClient.NET är till exempel uppslagsfunktionen:

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

Funktionen returnerar målvärdnamnet som registrerats för port 5671 i zonen som för närvarande är alias med CNAME enligt ovan.

Om du utför en redundansväxling måste du redigera CNAME-posten och peka den mot den alternativa zonen.

Fördelen med att använda DNS, och särskilt Azure DNS, är att Azure DNS-information replikeras globalt och därför är motståndskraftig mot avbrott i en region.

Den här proceduren liknar hur Service Bus Geo-DR fungerar, men helt under din egen kontroll och fungerar även med aktiva/aktiva scenarier.

Filresursbaserad redundanskonfiguration

Det enklaste alternativet till att använda DNS för att dela slutpunktsinformation är att placera namnet på den primära slutpunkten i en oformaterad textfil och hantera filen från en infrastruktur som är robust mot avbrott och fortfarande tillåter uppdateringar.

Om du redan kör en webbplatsinfrastruktur med hög tillgänglighet med global tillgänglighet och innehållsreplikering lägger du till en sådan fil där och publicerar om filen om det behövs en växel.

Slå ihop

Kopplingsmönstret har en eller flera replikeringsuppgifter som pekar på ett mål, eventuellt samtidigt med vanliga producenter som också skickar meddelanden till samma mål.

Varianter av det här mönstret är:

  • Två eller flera replikeringsfunktioner hämtar samtidigt meddelanden från separata källor och skickar dem till samma mål.
  • Ytterligare en replikeringsfunktion som hämtar meddelanden från en källa medan målet också används direkt av producenter.
  • Det tidigare mönstret, men meddelanden speglas mellan två eller flera ämnen, vilket resulterar i de ämnen som innehåller samma meddelanden, oavsett var meddelanden skapas.

De två första mönstervariationerna är triviala och skiljer sig inte från vanliga replikeringsuppgifter.

Det sista scenariot kräver att redan replikerade meddelanden inte replikeras igen. Tekniken demonstreras och förklaras i det aktiva/aktiva exemplet.

Editor

Redigeringsmönstret bygger på replikeringsmönstret , men meddelanden ändras innan de vidarebefordras. Exempel på sådana ändringar är:

  • Transcoding – Om meddelandeinnehållet (kallas även "brödtext" eller "nyttolast") kommer från källan som kodas med Apache Avro-formatet eller något eget serialiseringsformat, men förväntningen av att systemet äger målet är att innehållet ska vara JSON-kodat , kommer en transkodningsreplikeringsuppgift först att deserialisera nyttolasten från Apache Avro till ett minnesinternt objektdiagram och sedan serialisera den grafen till JSON format för meddelandet som vidarebefordras. Transkodning omfattar även uppgifter för innehållskomprimering och dekomprimering.
  • Transformering – meddelanden som innehåller strukturerade data kan kräva omformning av dessa data för enklare förbrukning av nedströmsanvändare. Detta kan innebära arbete som att platta ut kapslade strukturer, rensa överflödiga dataelement eller omforma nyttolasten så att den passar exakt för ett visst schema.
  • Batchbearbetning – meddelanden kan tas emot i batchar (flera meddelanden i en enda överföring) från en källa, men måste vidarebefordras singly till ett mål, eller vice versa. En uppgift kan därför vidarebefordra flera meddelanden baserat på en enda överföring av indatameddelanden eller aggregera en uppsättning meddelanden som sedan överförs tillsammans.
  • Validering – meddelandedata från externa källor måste ofta kontrolleras om de följer en uppsättning regler innan de kan vidarebefordras. Reglerna kan uttryckas med hjälp av scheman eller kod. meddelanden som inte är i kompatibilitet kan tas bort, med problemet antecknade i loggar, eller vidarebefordras till ett särskilt målmål för att hantera dem ytterligare.
  • Berikning – meddelandedata som kommer från vissa källor kan kräva berikning med ytterligare kontext för att de ska kunna användas i målsystem. Det kan handla om att söka efter referensdata och bädda in dessa data med meddelandet, eller att lägga till information om källan som är känd för replikeringsuppgiften, men som inte finns i meddelandena.
  • Filtrering – Vissa meddelanden som kommer från en källa kan behöva undanhållas från målet baserat på någon regel. Ett filter testar meddelandet mot en regel och släpper meddelandet om meddelandet inte matchar regeln. Att filtrera bort dubblettmeddelanden genom att observera vissa kriterier och släppa efterföljande meddelanden med samma värden är en form av filtrering.
  • Routning och partitionering – Vissa replikeringsuppgifter kan tillåta två eller flera alternativa mål och definiera regler för vilka replikeringsmål väljs för ett visst meddelande baserat på metadata eller innehållet i meddelandet. En särskild form av routning är partitionering, där uppgiften uttryckligen tilldelar partitioner i ett replikeringsmål baserat på regler.
  • Kryptografi – En replikeringsuppgift kan behöva dekryptera innehåll som kommer från källan och/eller kryptera innehåll som vidarebefordras vidare till ett mål och/eller måste verifiera innehållets och metadatas integritet i förhållande till en signatur som bärs i meddelandet eller bifoga en sådan signatur.
  • Attestering – En replikeringsuppgift kan bifoga metadata, som kan skyddas av en digital signatur, till ett meddelande som intygar att meddelandet har tagits emot via en viss kanal eller vid en viss tidpunkt.
  • Länkning – En replikeringsaktivitet kan använda signaturer för sekvenser av meddelanden så att sekvensens integritet skyddas och att meddelanden som saknas kan identifieras.

Alla dessa mönster kan implementeras med Hjälp av Azure Functions, med hjälp av meddelandehubbarutlösaren för att hämta meddelanden och utdatabindningen för kö eller ämne för att leverera dem.

Routning

Routningsmönstret bygger på replikeringsmönstret , men i stället för att ha en källa och ett mål har replikeringsaktiviteten flera mål, vilket illustreras här i C#:

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 
    }
}

Routningsfunktionen tar hänsyn till meddelandets metadata och/eller meddelandets nyttolast och väljer sedan något av de tillgängliga mål som ska skickas till.

Nästa steg