Bewerken

Delen via

Transit hub dynamic pub-sub messaging system

Azure Cache for Redis
Azure Cosmos DB
Azure Event Hubs
Azure Functions
Azure Service Bus

Oplossingsideeën

In dit artikel wordt een oplossingsidee beschreven. Uw cloudarchitect kan deze richtlijnen gebruiken om de belangrijkste onderdelen te visualiseren voor een typische implementatie van deze architectuur. Gebruik dit artikel als uitgangspunt om een goed ontworpen oplossing te ontwerpen die overeenkomt met de specifieke vereisten van uw workload.

In dit artikel wordt een elastisch, flexibel model voor publiceren/abonneren voor gegevensproducenten en consumenten beschreven voor het maken en gebruiken van gevalideerde, samengestelde inhoud of gegevens.

Architectuur

Diagram van het Transit Hub publish-subscribe messaging system.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom

  1. De data producer-app publiceert gegevens naar Azure Event Hubs, waarmee de gegevens worden verzonden naar de functie Gebeurtenisverwerking van Azure Functions.

  2. De gegevensproducent verzendt ook het JSON-schema voor opslag in een Azure Storage-container.

  3. Met de functie Gebeurtenisverwerking wordt het JSON-schema opgehaald uit Azure Cache voor Redis om de latentie te verminderen en wordt het schema gebruikt om de gegevens te valideren.

    Als het schema nog niet in de cache is opgeslagen, haalt de functie Gebeurtenisverwerking het schema op uit de Azure Storage-container. De aanvraag voor het schema slaat het schema ook op in Azure Cache voor Redis voor toekomstig ophalen.

    Notitie

    Azure Schema Registry in Event Hubs kan een bruikbaar alternatief zijn voor het opslaan en opslaan van JSON-schema's in cache. Zie Azure Schema Registry in Event Hubs (preview) voor meer informatie.

  4. Als er al een onderwerp bestaat en de gegevens geldig zijn, voegt de functie Gebeurtenisverwerking de gegevens samen in het bestaande Azure Service Bus-onderwerp Geldige gegevens en verzendt het onderwerp naar de data consumer-app .

  5. Als er al een onderwerp bestaat en de gegevens ongeldig zijn, voegt de functie Gebeurtenisverwerking de gegevens samen in het bestaande ongeldige Data Service Bus-onderwerp en stuurt het onderwerp terug naar de gegevensproducent. De gegevensproducent abonneert zich op de onderwerpen Ongeldige gegevens om feedback te krijgen over ongeldige gegevens die de producent heeft gemaakt.

  6. Als er nog geen onderwerp bestaat, publiceert de functie Gebeurtenisverwerking de nieuwe gegevens naar een Nieuw Data Service Bus-onderwerp en verzendt het onderwerp naar de functie Service Bus Topic Manager .

  7. Als de nieuwe gegevens geldig zijn, worden met de functie Gebeurtenisverwerking ook de gegevens ingevoegd als een nieuwe record voor momentopnamegegevens in Azure Cosmos DB.

  8. Als de nieuwe gegevens geldig zijn, maakt de functie Service Bus Topic Manager een nieuw Geldig Data Service Bus-onderwerp en verzendt het onderwerp naar Event Hubs.

  9. Als de nieuwe gegevens ongeldig zijn, wordt met de functie Service Bus-onderwerpbeheer een nieuw Data Service Bus-onderwerp gemaakt en wordt het onderwerp teruggestuurd naar de Data Producer-app .

  10. De platte bestandsprocessor voor momentopnamegegevens in Azure Data Factory wordt volgens een schema uitgevoerd om alle momentopnamegegevens uit de Azure Cosmos DB-database voor momentopnamegegevens te extraheren. De processor maakt een plat bestand en publiceert het naar een Momentopnamegegevens plat bestand in Azure Storage voor downloads.

  11. De Data Consumer-app haalt een lijst op met alle Service Bus-onderwerpen die de Service Bus-onderwerpmanager beschikbaar heeft voor een abonnement. De app wordt geregistreerd bij Service Bus Topic Manager om u te abonneren op Service Bus-onderwerpen.

Onderdelen

Scenariodetails

De Transit Hub is een dynamisch model voor publiceren-abonneren voor gegevensproducenten en gegevensgebruikers om gevalideerde, samengestelde inhoud of gegevens te maken en te gebruiken. Het model is elastisch om schaal en prestaties mogelijk te maken. Gegevensproducenten kunnen snel gegevens onboarden en uploaden naar een service. De service valideert de gegevens op basis van een schema dat de gegevensproducent levert. De service maakt vervolgens de gevalideerde gegevens beschikbaar voor abonnees om gegevens te gebruiken waarin ze geïnteresseerd zijn.

De service die de gegevens valideert, hoeft niet op de hoogte te zijn van de nettolading, alleen of deze geldig is voor het schema dat de producent levert. Deze flexibiliteit betekent dat de service nieuwe payloadtypen kan accepteren zonder dat deze opnieuw hoeft te worden geïmplementeerd. Met deze oplossing kunnen gegevensgebruikers ook historische gegevens ophalen die zijn gepubliceerd voordat de consument zich abonneert.

Potentiële gebruikscases

Dit model is vooral handig in de volgende scenario's:

  • Berichtensystemen waarbij gebruikersvolume en -status onbekend zijn of onvoorspelbaar zijn
  • Publicatiesystemen die mogelijk nieuwe of onbekende gegevensbronnen moeten ondersteunen
  • Commerce- of ticketingsystemen die voortdurend gegevens moeten bijwerken en in de cache moeten opslaan voor snelle levering

Volgende stappen