Redigera

Dela via

Överföringshubbens dynamiska pub-sub-meddelandesystem

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

Lösningsidéer

I den här artikeln beskrivs en lösningsidé. Molnarkitekten kan använda den här vägledningen för att visualisera huvudkomponenterna för en typisk implementering av den här arkitekturen. Använd den här artikeln som utgångspunkt för att utforma en välkonstruerad lösning som överensstämmer med arbetsbelastningens specifika krav.

Den här artikeln beskriver en elastisk, flexibel publiceringsprenumereringsmodell för dataproducenter och konsumenter för att skapa och använda verifierat, kuraterat innehåll eller data.

Arkitektur

Diagram över överföringshubbens meddelandesystem för publicering och prenumeration.

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde

  1. Appen Dataproducent publicerar data till Azure Event Hubs, som skickar data till funktionen Händelsebearbetning i Azure Functions.

  2. Dataproducenten skickar också JSON-schemat för lagring i en Azure Storage-container.

  3. Funktionen Händelsebearbetning hämtar JSON-schemat från Azure Cache for Redis för att minska svarstiden och använder schemat för att verifiera data.

    Om schemat inte har cachelagrats ännu hämtar funktionen Händelsebearbetning schemat från Azure Storage-containern. Begäran om schemat lagrar även schemat i Azure Cache for Redis för framtida hämtning.

    Kommentar

    Azure Schema Registry i Event Hubs kan vara ett bra alternativ till att lagra och cachelagra JSON-scheman. Mer information finns i Azure Schema Registry i Event Hubs (förhandsversion).

  4. Om det redan finns ett ämne och data är giltiga sammanfogar funktionen Händelsebearbetning data till det befintliga Azure Service Bus-ämnet för giltiga data och skickar ämnet till appen Datakonsument .

  5. Om det redan finns ett ämne och data är ogiltiga sammanfogar funktionen Händelsebearbetning data till det befintliga avsnittet Invalid Data Service Bus och skickar tillbaka ämnet till dataproducenten. Dataproducenten prenumererar på avsnitten Ogiltiga data för att få feedback om ogiltiga data som producenten skapade.

  6. Om det inte finns något ämne ännu publicerar funktionen Händelsebearbetning nya data till ett nytt Data Service Bus-ämne och skickar ämnet till funktionen Service Bus Topic Manager .

  7. Om de nya data är giltiga infogar funktionen Händelsebearbetning även data som en ny post för ögonblicksbilddata i Azure Cosmos DB.

  8. Om de nya data är giltiga skapar Service Bus Topic Manager-funktionen ett nytt giltigt Data Service Bus-ämne och skickar ämnet till Event Hubs.

  9. Om de nya data är ogiltiga skapar Service Bus Topic Manager-funktionen ett nytt ogiltigt Data Service Bus-ämne och skickar tillbaka ämnet till appen Dataproducent .

  10. Den flata processorn för ögonblicksbilddata i Azure Data Factory körs enligt ett schema för att extrahera alla ögonblicksbildsdata från Azure Cosmos DB-databasen för ögonblicksbilddata . Processorn skapar en platt fil och publicerar den till en flat ögonblicksbildsfil i Azure Storage för nedladdningar.

  11. Appen Datakonsument hämtar en lista över alla Service Bus-ämnen som Service Bus Topic Manager har tillgängliga för prenumeration. Appen registreras med Service Bus Topic Manager för att prenumerera på Service Bus-ämnen.

Komponenter

Information om scenario

Transit Hub är en dynamisk publiceringsprenumereringsmodell för dataproducenter och datakonsumenter för att skapa och använda verifierat, kuraterat innehåll eller data. Modellen är elastisk för att möjliggöra skalning och prestanda. Dataproducenter kan snabbt registrera och ladda upp data till en tjänst. Tjänsten validerar data mot ett schema som dataproducenten tillhandahåller. Tjänsten gör sedan verifierade data tillgängliga för prenumeranter att använda data som de är intresserade av.

Tjänsten som verifierar data behöver inte veta om nyttolasten, bara om den är giltig mot det schema som producenten tillhandahåller. Den här flexibiliteten innebär att tjänsten kan acceptera nya nyttolasttyper utan att behöva distribueras om. Med den här lösningen kan datakonsumenter också hämta historiska data som publicerades innan konsumenten prenumererade.

Potentiella användningsfall

Den här modellen är särskilt användbar i följande scenarier:

  • Meddelandesystem där användarvolym och status är okända eller varierar oförutsägbart
  • Publiceringssystem som potentiellt behöver stöd för nya eller okända datakällor
  • Handels- eller biljettsystem som kontinuerligt behöver uppdatera data och cachelagrar dem för snabb leverans

Nästa steg