Upravit

Sdílet prostřednictvím

Systém dynamického pub-sub messaging centra přenosu

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

Nápady na řešení

Tento článek popisuje myšlenku řešení. Váš cloudový architekt může pomocí těchto pokynů vizualizovat hlavní komponenty pro typickou implementaci této architektury. Tento článek slouží jako výchozí bod k návrhu dobře navrženého řešení, které odpovídá konkrétním požadavkům vaší úlohy.

Tento článek popisuje elastický, flexibilní model publikování a odběr pro producenty dat a uživatele k vytváření a využívání ověřeného, kurátorovaného obsahu nebo dat.

Architektura

Diagram systému publikování a odběru zasílání zpráv centra tranzitu

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat

  1. Aplikace Producent dat publikuje data do služby Azure Event Hubs, která odesílá data do funkce Zpracování událostí Azure Functions.

  2. Producent dat také odešle schéma JSON pro úložiště v kontejneru Azure Storage.

  3. Funkce Zpracování událostí načte schéma JSON ze služby Azure Cache for Redis, aby se snížila latence, a pomocí schématu ověří data.

    Pokud schéma ještě není uložené v mezipaměti, funkce Zpracování událostí načte schéma z kontejneru Azure Storage. Požadavek na schéma také ukládá schéma ve službě Azure Cache for Redis pro budoucí načtení.

    Poznámka:

    Azure Schema Registry ve službě Event Hubs může být proveditelnou alternativou k ukládání a ukládání schémat JSON do mezipaměti. Další informace najdete v tématu Azure Schema Registry ve službě Event Hubs (Preview).

  4. Pokud téma již existuje a data jsou platná, funkce Zpracování událostí sloučí data do existujícího tématu Valid Data Azure Service Bus a odešle téma do aplikace Příjemce dat.

  5. Pokud téma již existuje a data jsou neplatná, funkce Zpracování událostí sloučí data do existujícího tématu neplatné služby Data Service Bus a odešle téma zpět producentovi dat. Producent dat se přihlásí k odběru témat o neplatných datech , aby získal zpětnou vazbu o neplatných datech vytvořených producentem.

  6. Pokud téma ještě neexistuje, funkce Zpracování událostí publikuje nová data do tématu New Data Service Bus a odešle téma do funkce Správce témat služby Service Bus.

  7. Pokud jsou nová data platná, funkce Zpracování událostí také vloží data jako nový záznam snapshot data ve službě Azure Cosmos DB.

  8. Pokud jsou nová data platná, funkce Správce témat služby Service Bus vytvoří nové platné téma služby Data Service Bus a odešle téma do služby Event Hubs.

  9. Pokud jsou nová data neplatná, funkce Správce témat služby Service Bus vytvoří nové téma o neplatné službě Data Service Bus a odešle téma zpět do aplikace Producent dat.

  10. Procesor snímků plochých souborů ve službě Azure Data Factory běží podle plánu, který extrahuje všechna data snímků z databáze Azure Cosmos DB snímků . Procesor vytvoří plochý soubor a publikuje ho do souboru Snapshot Data Flat File ve službě Azure Storage ke stažení.

  11. Aplikace Data Consumer načte seznam všech témat služby Service Bus, která má správce témat služby Service Bus k dispozici pro předplatné. Aplikace se zaregistruje ve Správci témat služby Service Bus a přihlásí se k odběru témat služby Service Bus.

Komponenty

Podrobnosti scénáře

Tranzitní centrum je model dynamického publikování a odběru dat pro producenty dat a uživatele dat, který umožňuje vytvářet a využívat ověřený, kurátorovaný obsah nebo data. Model je elastický, aby umožňoval škálování a výkon. Producenti dat můžou rychle připojit a nahrát data do služby. Služba ověří data ve schématu, které poskytuje producent dat. Služba pak zpřístupní ověřená data pro předplatitele, aby mohli využívat data, která mají zájem.

Služba, která ověřuje data, nemusí vědět o datové části, pouze jestli je platná vůči schématu, které producent poskytuje. Tato flexibilita znamená, že služba může přijímat nové typy datových částí bez nutnosti opětovného nasazení. Toto řešení také umožňuje příjemcům dat získat historická data publikovaná před přihlášením příjemce k odběru.

Potenciální případy použití

Tento model je zvlášť užitečný v následujících scénářích:

  • Systémy zasílání zpráv, ve kterých je uživatelský svazek a stav neznámý nebo se liší nepředvídatelně
  • Systémy publikování, které mohou potřebovat podporovat nové nebo neznámé zdroje dat
  • Obchodní systémy nebo systémy lístků, které potřebují průběžně aktualizovat data a ukládat je do mezipaměti pro rychlé doručování

Další kroky