Claim-Check vzor

Rozdělte velkou zprávu na kontrolu deklarace identity a datovou část. Odešlete kontrolu deklarace identity na platformu zasílání zpráv a datovou část uložte do externí služby. Tento model umožňuje zpracování velkých zpráv při ochraně sběrnice zpráv a klienta před zahlcení nebo zpomalování. Tento model také pomáhá snižovat náklady, protože úložiště je obvykle levnější než jednotky prostředků používané platformou pro zasílání zpráv.

Tento model se také označuje jako Reference-Based Messaging a původně ho popsali v knize Enterprise Integration Patterns, kterou napsali Gregor Hohpe af.

Kontext a problém

Architektura založená na zasílání zpráv v nějakém okamžiku musí být schopná odesílat velké zprávy, přijímat je a manipulovat s nimi. Takové zprávy mohou obsahovat cokoli, včetně obrázků (například prohledávání MRI), zvukových souborů (například volání call centra), textových dokumentů nebo jakéhokoli druhu binárních dat libovolné velikosti.

Odesílání takových velkých zpráv přímo na sběrnici zpráv se nedoporučuje, protože vyžadují více prostředků a šířky pásma. Velké zprávy mohou také zpomalit celé řešení, protože platformy zasílání zpráv jsou obvykle jemně vyladěné tak, aby zvládly velké množství malých zpráv. Většina platforem zasílání zpráv má také omezení velikosti zpráv, takže možná budete muset tato omezení u velkých zpráv obcházet.

Řešení

Celou datovou část zprávy uložte do externí služby, jako je databáze. Získejte odkaz na uloženou datovou část a odešlete jenom tento odkaz na sběrnici zpráv. Referenční informace se chová jako kontrola deklarace identity, která se používá k načtení kuse suce, a proto se jedná o název vzoru. Klienti, kteří mají zájem o zpracování této konkrétní zprávy, mohou v případě potřeby použít získaný odkaz k načtení datové části.

Diagram vzoru Claim-Check dat

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

  • Pokud nepotřebujete zprávy archivovat, zvažte jejich odstranění po jejich použití. I když je úložiště objektů blob poměrně levné, stojí to z dlouhodobého horizontu určité peníze, zejména pokud je k dispozici velké množství dat. Odstranění zprávy může provést synchronně aplikace, která zprávu přijme a zpracuje, nebo asynchronně samostatným vyhrazeným procesem. Asynchronní přístup odebere stará data bez dopadu na propustnost a výkon zpracování zpráv přijímající aplikace.

  • Uložení a načtení zprávy způsobí další režii a latenci. V odesílající aplikaci můžete implementovat logiku, která tento model použije jenom v případě, že velikost zprávy překročí limit dat sběrnice zpráv. U menších zpráv by se vzor přeskočil. Výsledkem tohoto přístupu by byl model podmíněné kontroly deklarací identity.

Kdy se má tento model použít

Tento model by se měl použít vždy, když zpráva není vhodná pro podporovaný limit zpráv zvolené technologie sběrnice zpráv. Například pro Event Hubs limit 256 kB (úroveň Basic), zatímco Event Grid podporuje pouze 64kB zprávy.

Tento vzor lze použít také v případě, že by k datové části měly přistupovat pouze služby, které mají oprávnění ji zobrazit. Díky snižování zátěže datové části na externí prostředek je možné použít přísnější ověřovací a autorizační pravidla, která zajistí vynucení zabezpečení při uložení citlivých dat v datové části.

Příklady

V Azure je možné tento model implementovat několika způsoby a s různými technologiemi, ale existují dvě hlavní kategorie. V obou případech je příjemce zodpovědný za přečtení kontroly deklarace identity a použití této kontroly k načtení datové části.

  • Automatické generování kontroly deklarací identity. Tento přístup používá Azure Event Grid k automatickému vygenerování kontroly deklarací identity a nasoudí ji do sběrnice zpráv.

  • Ruční generování kontroly deklarací identity. Při tomto přístupu je za správu datové části zodpovědný odesílatel. Odesílatel uloží datovou část pomocí příslušné služby, získá nebo vygeneruje kontrolu deklarace identity a odešle kontrolu deklarace do sběrnice zpráv.

Event Grid je služba směrování událostí a pokouší se doručovat události během konfigurovatelné doby až 24 hodin. Potom se události buď zahodí, nebo se zahodí jako neschůdné. Pokud potřebujete archivovat datové části událostí nebo přehrát datový proud událostí, můžete přidat odběr Event Grid do služby Event Hubs nebo Queue Storage, kde se zprávy mohou uchovávat po delší dobu a zprávy archivace se podporují. Informace o doladění Event Grid zpráv a opakování a konfiguraci zpráv o doručení a opakování zpráv najdete v tématu Zásady pro doručení a opakovánízpráv.

Automatické generování kontroly deklarací identity s Storage a Event Grid

Při tomto přístupu odesílatel zahodí datovou část zprávy do určeného kontejneru azure blob Storage kontejneru. Event Grid automaticky vygeneruje značku nebo odkaz a odešle ji do podporované sběrnice zpráv, například Azure Storage fronty. Příjemce se může dotazovat fronty, získat zprávu a pak pomocí uložených referenčních dat stáhnout datovou část přímo z úložiště Storage.

Stejnou Event Grid může přímo využívat Azure Functions ,aniž by bylo nutné procházet sběrnici zpráv. Tento přístup plně využívá bez serverové povahy služby Event Grid a Functions.

Příklad kódu pro tento přístup najdete tady.

Event Grid s Event Hubs

Podobně jako v předchozím příkladu Event Grid automaticky vygeneruje zprávu při zápisu datové části do kontejneru objektů blob Azure. V tomto příkladu je ale sběrnice zpráv implementovaná pomocí Event Hubs. Klient se může zaregistrovat, aby při zápisu do centra událostí přijímal datový proud zpráv. Centrum událostí je také možné nakonfigurovat tak, aby archivoval zprávy, takže je dostupné jako soubor Avro, na který se můžete dotazovat pomocí nástrojů, jako je Apache Spark, Apache Drill nebo kterákoli z dostupných knihoven Avro.

Příklad kódu pro tento přístup najdete tady.

Generování kontroly deklarací identity s Service Bus

Toto řešení využívá konkrétní modul plug-in Service Bus ServiceBus.AttachmentPlugin,který usnadňuje implementaci pracovního postupu kontroly deklarací identity. Modul plug-in převede všechny texty zprávy na přílohu, která se při Storage uloží do služby Azure Blob.

using ServiceBus.AttachmentPlugin;
...

// Getting connection information
var serviceBusConnectionString = Environment.GetEnvironmentVariable("SERVICE_BUS_CONNECTION_STRING");
var queueName = Environment.GetEnvironmentVariable("QUEUE_NAME");
var storageConnectionString = Environment.GetEnvironmentVariable("STORAGE_CONNECTION_STRING");

// Creating config for sending message
var config = new AzureStorageAttachmentConfiguration(storageConnectionString);

// Creating and registering the sender using Service Bus Connection String and Queue Name
var sender = new MessageSender(serviceBusConnectionString, queueName);
sender.RegisterAzureStorageAttachmentPlugin(config);

// Create payload
var payload = new { data = "random data string for testing" };
var serialized = JsonConvert.SerializeObject(payload);
var payloadAsBytes = Encoding.UTF8.GetBytes(serialized);
var message = new Message(payloadAsBytes);

// Send the message
await sender.SendAsync(message);

Zpráva Service Bus funguje jako fronta oznámení, ke které se klient může přihlásit k odběru. Když příjemce obdrží zprávu, modul plug-in umožňuje přímo číst data zprávy z blob Storage. Pak můžete zvolit, jak zprávu dále zpracovat. Výhodou tohoto přístupu je, že abstrahuje pracovní postup kontroly deklarací identity od odesílatele a příjemce.

Příklad kódu pro tento přístup najdete tady.

Ruční generování kontroly deklarací identity s kafka

V tomto příkladu klient Kafka zapíše datovou část do služby Azure Blob Storage. Pak odešle zprávu s oznámením pomocí příkazu s podporou Kafka Event Hubs. Příjemce obdrží zprávu a může k datové části přistupovat z úložiště objektů Storage. Tento příklad ukazuje, jak lze k implementaci vzoru kontroly deklarací identity v Azure použít jiný protokol zasílání zpráv. Možná budete muset například podporovat stávající klienty Kafka.

Příklad kódu pro tento přístup najdete tady.

Další kroky