Berichtreplicatie en federatie in meerdere regio's
Binnen naamruimten ondersteunt Azure Service Bus het maken van topologieën van gekoppelde wachtrijen en onderwerpabonnementen met behulp van automatisch doorsturen om de implementatie van verschillende routeringspatronen mogelijk te maken. U kunt partners bijvoorbeeld voorzien van speciale wachtrijen waarnaar ze machtigingen hebben voor verzenden of ontvangen en die indien nodig tijdelijk kunnen worden opgeschort en flexibel verbinding maken met andere entiteiten die privé zijn voor de toepassing. U kunt ook complexe routeringstopologieën met meerdere fasen maken of wachtrijen in postvakstijl maken, die de wachtrijachtige abonnementen van onderwerpen leegmaken en meer opslagcapaciteit per abonnee mogelijk maken.
Veel geavanceerde oplossingen vereisen ook dat berichten worden gerepliceerd over de grenzen van naamruimten om deze en andere patronen te implementeren. Berichten moeten mogelijk stromen tussen naamruimten die zijn gekoppeld aan meerdere, verschillende toepassingstenants of tussen meerdere, verschillende Azure-regio's.
Uw oplossing onderhoudt meerdere Service Bus-naamruimten in verschillende regio's en repliceert berichten tussen wachtrijen en onderwerpen en/of dat u berichten uitwisselt met bronnen en doelen zoals Azure Event Hubs, Azure IoT Hub of Apache Kafka.
Deze scenario's zijn de focus van dit artikel.
Federatiepatronen
Er zijn talloze mogelijke redenen waarom u berichten wilt verplaatsen tussen Service Bus-entiteiten, zoals wachtrijen of onderwerpen, of tussen Service Bus en andere bronnen en doelen.
Vergeleken met de vergelijkbare set patronen voor Event Hubs, is federatie voor wachtrijachtige entiteiten complexer omdat berichtenwachtrijen hun consumenten exclusieve eigendom van elk bericht beloven, dat de aankomstvolgorde bij de bezorging van berichten behouden blijft en de broker een eerlijke distributie van berichten tussen concurrerende consumenten coördineert.
Er zijn praktische belemmeringen, waaronder de beperkingen van het GLB-theorema, die het moeilijk maken om een uniforme weergave te bieden van een wachtrij die tegelijkertijd beschikbaar is in meerdere regio's, en waardoor regionaal gedistribueerde, concurrerende consumenten exclusieve eigendom van berichten kunnen nemen. Een dergelijke geo-gedistribueerde wachtrij vereist een volledig consistente replicatie, niet alleen van berichten, maar ook van de bezorgingsstatus van elk bericht voordat berichten beschikbaar kunnen worden gesteld aan consumenten. Een doel van een volledige consistentie voor een hypothetische, regionaal gedistribueerde wachtrij is in directe strijd met het belangrijkste doel dat vrijwel alle Azure Service Bus klanten hebben bij het overwegen van federatiescenario's: maximale beschikbaarheid en betrouwbaarheid voor hun oplossingen.
De hier gepresenteerde patronen zijn daarom gericht op beschikbaarheid en betrouwbaarheid, terwijl ook wordt geprobeerd om zowel informatieverlies als dubbele verwerking van berichten zo goed mogelijk te voorkomen.
Tolerantie tegen regionale beschikbaarheidsgebeurtenissen
Hoewel maximale beschikbaarheid en betrouwbaarheid de belangrijkste operationele prioriteiten zijn voor Service Bus, zijn er toch veel manieren waarop een producent of consument mogelijk niet kan praten met de toegewezen 'primaire' Service Bus vanwege problemen met netwerken of naamomzetting, of waarbij de Service Bus-entiteit mogelijk tijdelijk niet reageert of fouten retourneert. De aangewezen berichtverwerker is mogelijk ook niet meer beschikbaar.
Dergelijke omstandigheden zijn niet 'rampzalig', zodat u de regionale implementatie helemaal wilt stopzetten, net als in een noodherstelsituatie, maar het bedrijfsscenario van sommige toepassingen kan al worden beïnvloed door beschikbaarheidsgebeurtenissen die niet langer dan een paar minuten of zelfs seconden duren. Azure Service Bus wordt vaak gebruikt in hybride cloudomgevingen en bij klanten die zich aan de netwerkrand bevinden, bijvoorbeeld in winkels, restaurants, bankkantoren, productiesites, logistieke faciliteiten en luchthavens. Het is mogelijk dat een probleem met netwerkroutering of congestie van invloed is op het vermogen van een site om het toegewezen Service Bus-eindpunt te bereiken, terwijl een secundair eindpunt in een andere regio mogelijk bereikbaar is. Tegelijkertijd hebben systemen die berichten verwerken die afkomstig zijn van deze sites mogelijk nog steeds ongehinderd toegang tot zowel de primaire als de secundaire Service Bus-eindpunten.
Er zijn veel praktische voorbeelden van dergelijke hybride cloud- en edge-toepassingen met een lage bedrijfstolerantie voor de impact van netwerkrouteringsproblemen of tijdelijke beschikbaarheidsproblemen van een Service Bus-entiteit. Deze omvatten de verwerking van betalingen op winkelsites, het instappen bij luchthavenpoorten en mobiele telefoonbestellingen in restaurants, die allemaal tot een moment komen, en volledige stilstand wanneer het betrouwbare communicatiepad niet beschikbaar is.
In deze categorie bespreken we drie verschillende gedistribueerde patronen: 'all-active' replicatie, 'actief-passieve' replicatie en 'spillover'-replicatie.
All-Active replicatie
Het replicatiepatroon 'all-active' maakt het mogelijk dat een actieve replica van hetzelfde logische onderwerp (of dezelfde wachtrij) beschikbaar is in meerdere naamruimten (en regio's), en dat alle berichten beschikbaar zijn in alle replica's, ongeacht waar ze zijn geceueerd. Het patroon behoudt over het algemeen de volgorde van berichten ten opzichte van elke uitgever.
Zoals in de afbeelding wordt weergegeven, is het patroon over het algemeen gebaseerd op Service Bus-onderwerpen. Eén onderwerp voor elke naamruimte die deelneemt aan het replicatieschema. Elk van deze onderwerpen heeft één replicatieabonnement voor elk van de andere onderwerpen waarnaar berichten moeten worden gerepliceerd. In de bovenstaande afbeelding hebben we gewoon een paar onderwerpen en dus één replicatieabonnement voor het betreffende andere onderwerp. In een scenario met drie naamruimten {n1, n2, n3} heeft een onderwerp in naamruimte n1 twee replicatieabonnementen, één voor het bijbehorende onderwerp in n2 en één voor het bijbehorende onderwerp in n3.
Elk replicatieabonnement heeft een regel die een SQL-filterexpressie (replicated <> 1) en een SQL-actie () combineert.set replicated = 1 Het filter van de regel zorgt ervoor dat alleen berichten waarin de aangepaste eigenschap replication niet is ingesteld of waarvoor de waarde 1 niet is ingesteld, in aanmerking komen voor dit abonnement, en dat de actie die exacte eigenschap instelt op de waarde 1 voor elk geselecteerd bericht direct daarna. Het effect is dat wanneer het bericht wordt gekopieerd naar het bijbehorende onderwerp, het niet langer in aanmerking komt voor replicatie in de tegenovergestelde richting en daarom wordt voorkomen dat berichten tussen replica's stuiteren.
Een abonnement met een respectieve regel kan eenvoudig worden toegevoegd aan elk onderwerp met behulp van de Azure CLI op deze manier.
az servicebus topic subscription rule create --resource-group myresourcegroup \
--namespace mynamespace --topic-name mytopic \
--subscription-name replication --name replication \
--action-sql-expression "set replication = 1" \
--filter-sql-expression "replication IS NULL"
Als u een wachtrij wilt modelleren, is elk onderwerp beperkt tot slechts één gewoon abonnement (behalve de replicatieabonnementen) dat alle consumenten delen.
Het volledig actieve replicatiemodel plaatst een kopie van elk bericht dat naar een van de onderwerpen wordt verzonden in elk van de onderwerpen. Dit betekent dat uw toepassingscode in elke regio alle berichten ziet en verwerkt. Dit patroon is geschikt voor scenario's waarin gegevens worden gedeeld in meerdere regio's of als redundante verwerking over het algemeen gewenst is. Als u elk bericht slechts eenmaal hoeft te verwerken, zoals bij een normale wachtrij, moet u rekening houden met een van de volgende twee patronen.
Active-Passive replicatie
Het replicatiepatroon 'actief-passief' is een variant van het eerdere patroon waarbij slechts één van de onderwerpen (de 'primaire') actief wordt gebruikt door de toepassing voor het verzenden en ontvangen van berichten en berichten worden gerepliceerd naar een secundair onderwerp voor het geval het primaire onderwerp mogelijk niet meer beschikbaar of onbereikbaar is.
Het belangrijkste verschil tussen dit patroon en het vorige patroon is dat replicatie unidirectioneel is van het primaire onderwerp naar het secundaire onderwerp. Het secundaire onderwerp wordt nooit het primaire onderwerp, maar is een back-upoptie wanneer het primaire onderwerp tijdelijk onbruikbaar is.
Het voordeel van het gebruik van dit patroon is dat hiermee dubbele verwerking wordt geminimaliseerd. Tijdens de replicatie wordt de TimeToLive berichteigenschap ingesteld op een duur voor de gerepliceerde berichten die overeenkomt met de verwachte tijd waarin een storing van de primaire berichten leidt tot een failover. Als uw use-casescenario bijvoorbeeld vereist dat de consument binnen maximaal 1 minuut na het ophalen van berichten van het primaire begin problemen vertoont, moet de secundaire in het ideale geval alle berichten beschikbaar hebben waartoe u geen toegang had in de primaire, maar een minimaal aantal berichten dat u al had verwerkt van de primaire voordat de problemen verschenen. Als we de TimeToLive instellen op twee keer die periode, 2 minuten, tijdens de replicatie (set sys.TimeToLive = '0:2:0' in de regelactie), worden berichten slechts 2 minuten bewaard en worden oudere berichten verwijderd. Dat betekent dat wanneer de ontvanger overschakelt naar de secundaire, berichten die ouder zijn dan de laatste die is verwerkt, snel kan worden doorgelezen en verwijderd en vervolgens het eerste bericht kan verwerken dat nog niet is gezien. De werkelijke retentieduur is afhankelijk van de specifieke use-case en van die u snel wilt en kunt overschakelen naar de secundaire in uw toepassing. De TimeToLive instelling wordt gehonoreerd in het bereik van een paar seconden tot dagen.
Terwijl de toepassing gebruikmaakt van de secundaire, kan deze ook rechtstreeks publiceren naar het secundaire onderwerp, dat vervolgens op dezelfde manier fungeert als een normaal onderwerp. Na de overgang naar de secundaire ziet de consument daarom een combinatie van gerepliceerde berichten en berichten die rechtstreeks naar de secundaire worden gepubliceerd. De toepassing moet daarom eerst terugschakelen naar de primaire publicatie en toch het leegmaken van de lokaal gepubliceerde berichten toestaan voordat de consument teruggaat naar de secundaire. Omdat de replicatie automatisch wordt hervat zodra de primaire versie weer beschikbaar is, krijgt de consument in die periode ook nieuwe berichten die naar de primaire server worden gepubliceerd, zij het met een iets hogere latentie.
Dit patroon is geschikt voor scenario's waarin berichten slechts eenmaal moeten worden verwerkt. De toepassing moet samenwerken bij het bijhouden van berichten die zijn verwerkt van de primaire, omdat er duplicaten worden gevonden voor de duur van het failovervenster in het secundaire venster en er opnieuw duplicaten worden gevonden tijdens het terugschakelen. Het criterium voor het ongedaan maken van duplicatie moet het beste een door de toepassing opgegeven
MessageIdzijn. DeEnqueuedTimeUtcwaarde is ook geschikt als watermerkindicator, maar de toepassing moet een bepaalde hoeveelheid klokdrift (enkele seconden) tussen het primaire en secundaire systeem toestaan, net als bij elk gedistribueerd systeem.
Overloopreplicatie
Het replicatiepatroon 'overloop' maakt actief/actief gebruik van meerdere Service Bus-entiteiten in meerdere regio's mogelijk om het scenario af te handelen waarin Service Bus in orde is, maar de consument overweldigd raakt met het aantal berichten in behandeling of volledig niet beschikbaar is. Een reden hiervoor kan zijn dat een database die back-up maakt van het consumentenproces traag of niet beschikbaar is. Dit patroon werkt met gewone wachtrijen en met onderwerpabonnementen.
Zoals weergegeven in de afbeelding, repliceert het overloopreplicatiepatroon berichten van de bijbehorende wachtrij met onbestelbare berichten van een wachtrij of abonnement naar een gekoppelde wachtrij of onderwerp in een andere naamruimte.
Zonder dat er een foutsituatie is, worden de twee naamruimten parallel gebruikt, waarbij elk een subset van het algemene berichtverkeer ontvangt en de bijbehorende consumenten die die subset verwerken. Zodra een van de consumenten hoge foutpercentages begint te vertonen of direct stopt, komen de respectieve berichten in de wachtrij voor onbestelbare berichten terecht omdat het aantal bezorgingen wordt overschreden of omdat het verloopt. De replicatietaken worden vervolgens opgehaald en opnieuw in de gekoppelde wachtrij geplaatst, waar ze vervolgens worden weergegeven aan de vermoedelijk gezonde consument.
Als de verwerking binnen een bepaalde deadline moet plaatsvinden, moeten de TimeToLive voor de wachtrij en/of berichten zodanig worden ingesteld dat de verwerking nog steeds op tijd kan plaatsvinden door de secundaire overloop, bijvoorbeeld TimeToLive op de helft van de toegestane tijd.
Net als bij het all-actieve patroon kan de toepassing een indicator aan het bericht toevoegen of het bericht al eenmaal is gerepliceerd, zodat het niet tussen het paar wachtrijen stuitert, maar in plaats daarvan in een hulpwachtrij wordt geplaatst die fungeert als de wachtrij met onbestelbare berichten voor het samengestelde patroon.
Dit patroon is geschikt voor scenario's waarbij de belangrijkste zorg is om bescherming te bieden tegen beschikbaarheidsproblemen bij consumenten of resources waarvan de consumenten afhankelijk zijn, en ook om pieken in verkeer op een van de gekoppelde wachtrijen opnieuw te distribueren. Het biedt ook bescherming tegen dat een van de naamruimten niet meer beschikbaar is als gebruikers uit beide wachtrijen lezen, maar de replicatievertraging die wordt opgelegd door de
TimeToLivevervaldatum, kan ertoe leiden dat berichten binnen dat tijdvenster vastlopen in de niet-beschikbare naamruimte.
Optimalisatie van latentie
Onderwerpen worden gebruikt om informatie te distribueren naar meerdere consumenten. In sommige gevallen, met name de consumenten met een brede geografische spreiding, kan het nuttig zijn om berichten van een onderwerp te repliceren naar een onderwerp in een secundaire naamruimte dichter bij consumenten.
Wanneer u bijvoorbeeld gegevens deelt tussen regionale, continentale hubs, is het efficiënter om slechts eenmaal informatie over te dragen tussen hubs en consumenten hun kopie van de gegevens van die hubs te laten ophalen.
Replicatieoverdrachten kunnen worden uitgevoerd in batches, die gebruikers vaak één voor één ontvangen en berichten vereffenen. Met een basisnetwerklatentie van 100 ms tussen bijvoorbeeld Noord-Amerika en Europa duurt de verwerking van elk bericht 200 ms langer voor de twee retouren naar een externe entiteit voor het verkrijgen en vereffenen van de berichten, vergeleken met een entiteit in dezelfde regio.
Validatie, reductie en verrijking
Berichten kunnen worden verzonden naar een Service Bus-wachtrij of -onderwerp door clients buiten uw eigen oplossing.
Voor dergelijke berichten moet mogelijk worden gecontroleerd op naleving van een bepaald schema en of niet-compatibele berichten moeten worden verwijderd of onbestelbaar zijn. Sommige berichten moeten mogelijk worden beperkt in complexiteit door gegevens weg te laten en sommige moeten mogelijk worden verrijkt door gegevens toe te voegen op basis van zoekacties voor referentiegegevens. De bewerkingen kunnen worden uitgevoerd met aangepaste functionaliteit in de replicatietaak.
Replicatie van stream naar wachtrij
Azure Event Hubs is een ideale oplossing voor het verwerken van extreme hoeveelheden binnenkomende gebeurtenissen. Maar Event Hubs of vergelijkbare engines zoals Apache Kafka bieden geen door de service beheerd concurrerend consumentenmodel waarbij meerdere consumenten berichten van dezelfde bron gelijktijdig kunnen afhandelen zonder het risico te lopen op dubbele verwerking en deze berichten uiteindelijk kunnen vereffenen zodra ze zijn verwerkt.
Een replicatie van stroom naar wachtrij draagt de inhoud van één Event Hub-partitie of de inhoud van een volledige Event Hub over naar een Service Bus-wachtrij, van waaruit de berichten veilig, transactioneel en met concurrerende consumenten kunnen worden verwerkt. Met deze replicatie kunt u ook alle andere Service Bus-mogelijkheden voor deze berichten gebruiken, inclusief routering met onderwerpen en demultiplexing op basis van sessies.
Consolidatie en normalisatie
Globale oplossingen bestaan vaak uit regionale voetafdrukken die grotendeels onafhankelijk zijn, inclusief hun eigen verwerkingscapaciteiten, maar supraregionale en globale perspectieven vereisen gegevensintegratie en daarom een centrale consolidatie van dezelfde berichtgegevens die worden geëvalueerd in de respectieve regionale voetafdrukken voor het lokale perspectief.
Normalisatie is een variant van het consolidatiescenario, waarbij twee of meer binnenkomende berichtenreeksen dezelfde soort informatie bevatten, maar met verschillende structuren of verschillende coderingen, en de berichten moeten worden getranscodeerd of getransformeerd voordat ze kunnen worden gebruikt.
Normalisatie kan ook cryptografisch werk omvatten, zoals het ontsleutelen van end-to-end versleutelde nettoladingen en het opnieuw versleutelen ervan met verschillende sleutels en algoritmen voor de downstream-consumentenpubliek.
Splitsen en routeren
Service Bus-onderwerpen en de bijbehorende abonnementsregels worden vaak gebruikt om een stroom berichten voor een bepaalde doelgroep te filteren en die doelgroep heeft vervolgens de gefilterde set van een abonnement verkregen.
In een globaal systeem waarin de doelgroep voor die berichten wereldwijd wordt gedistribueerd of tot verschillende toepassingen behoort, kan replicatie worden gebruikt om berichten van een dergelijk abonnement over te dragen naar een wachtrij of onderwerp in een andere naamruimte van waar ze worden gebruikt.
Replicatietoepassingen in Azure Functions
Voor het implementeren van de bovenstaande patronen is een schaalbare en betrouwbare uitvoeringsomgeving vereist voor de replicatietaken die u wilt configureren en uitvoeren. In Azure is de runtime-omgeving die het meest geschikt is voor staatloze taken Azure Functions.
Azure Functions kunnen worden uitgevoerd onder een door Azure beheerde identiteit, zodat de replicatietaken kunnen worden geïntegreerd met de op rollen gebaseerde regels voor toegangsbeheer van de bron- en doelservices zonder dat u geheimen langs het replicatiepad hoeft te beheren. Voor replicatiebronnen en -doelen waarvoor expliciete referenties zijn vereist, kunnen Azure Functions de configuratiewaarden voor deze referenties bewaren in een opslag met strikt toegangsbeheer binnen Azure Key Vault.
Azure Functions maakt het bovendien mogelijk om de replicatietaken rechtstreeks te integreren met virtuele Azure-netwerken en service-eindpunten voor alle Azure-berichtenservices, en is deze direct geïntegreerd met Azure Monitor.
Het belangrijkste is dat Azure Functions vooraf samengestelde, schaalbare triggers en uitvoerbindingen heeft voor Azure Event Hubs, Azure IoT Hub, Azure Service Bus, Azure Event Grid en Azure Queue Storage, aangepaste extensies voor RabbitMQ en Apache Kafka. De meeste triggers worden dynamisch aangepast aan de doorvoerbehoeften door het aantal gelijktijdig uitgevoerde exemplaren omhoog en omlaag te schalen op basis van gedocumenteerde metrische gegevens.
Met het Azure Functions verbruiksabonnement kunnen de vooraf gemaakte triggers zelfs omlaag schalen naar nul terwijl er geen berichten beschikbaar zijn voor replicatie. Dit betekent dat er geen kosten in rekening worden gebracht om de configuratie gereed te houden om weer omhoog te schalen. Het belangrijkste nadeel van het gebruik van het verbruiksabonnement is dat de latentie voor replicatietaken die vanuit deze status worden geactiveerd, aanzienlijk hoger is dan bij de hostingabonnementen waar de infrastructuur actief blijft.
In tegenstelling tot dit alles moeten de meest voorkomende replicatie-engines voor berichten en gebeurtenissen, zoals MirrorMaker van Apache Kafka, een hostingomgeving bieden en de replicatie-engine zelf schalen. Dit omvat het configureren en integreren van de beveiligings- en netwerkfuncties en het vergemakkelijken van de stroom van bewakingsgegevens. Vervolgens hebt u nog steeds geen mogelijkheid om aangepaste replicatietaken in de stroom te injecteren.
Replicatietaken met Azure Logic Apps
Een alternatief dat niet codeert voor het uitvoeren van replicatie met behulp van Functions, is om in plaats daarvan Logic Apps te gebruiken. Logic Apps hebben vooraf gedefinieerde replicatietaken voor Service Bus. Deze kunnen helpen bij het instellen van replicatie tussen verschillende exemplaren en kunnen worden aangepast voor verdere aanpassingen.
Volgende stappen
In dit artikel hebben we een reeks federatiepatronen verkend en de rol van Azure Functions uitgelegd als de replicatieruntime voor gebeurtenissen en berichten in Azure.
Vervolgens kunt u lezen hoe u een replicatortoepassing instelt met Azure Functions en vervolgens hoe u gebeurtenisstromen repliceert tussen Event Hubs en verschillende andere gebeurtenis- en berichtensystemen: