Vzor kontrolního nároku

Azure Event Grid

Azure Blob Storage

Model Kontroly deklarací identity umožňuje úlohám přenášet datové části bez uložení datové části do systému zasílání zpráv. Model ukládá datovou část do externího úložiště dat a k načtení datové části používá "žádankovou kontrolu". Kontrola deklarace identity je jedinečný, nejasný token nebo klíč. Aby aplikace mohly načíst datovou část, musí předložit token pro kontrolu žádosti do externího úložiště dat.

Kontext a problém

Tradiční systémy zasílání zpráv jsou optimalizované pro správu velkého objemu malých zpráv a často mají omezení velikosti zprávy, kterou můžou zpracovat. Velké zprávy nejen riskují překročení těchto limitů, ale mohou také snížit výkon celého systému, když je systém zasílání zpráv ukládá.

Řešení

Použijte vzor Kontroly deklarací identity a neodesílejte velké zprávy do systému zasílání zpráv. Místo toho odešlete datovou část do externího úložiště dat a vygenerujte token kontroly deklarací identity pro danou datovou část. Systém zasílání zpráv odešle zprávu s tokenem kontroly žádosti přijímajícím aplikacím, aby mohly načíst datovou část z úložiště dat. Systém zasílání zpráv nikdy neuvidí ani neuloží datovou část.

Diagram vzoru Claim-Check.

1. Užitečné zatížení
2. Uložte payload do datového úložiště.
3. Vygenerujte token kontroly deklarací identity a odešlete zprávu pomocí tokenu deklarace identity.
4. Přijmout zprávu a přečíst token pro kontrolu identity.
5. Načtěte datovou část.
6. Zpracujte datovou část

Problémy a úvahy ohledně vzoru Claim-Check

Při implementaci modelu Deklarace identity zvažte následující doporučení:

• Odstraňte spotřebované zprávy. Pokud zprávu nepotřebujete archivovat, odstraňte zprávu a datovou část poté, co ji přijímající aplikace zpracují. Použijte buď synchronní nebo asynchronní strategii odstranění:

  • Synchronní odstranění: Spotřebová aplikace odstraní zprávu a datovou část hned po spotřebě. Sváže odstranění s pracovním postupem zpracování zpráv a používá výpočetní kapacitu pracovního postupu zasílání zpráv.

  • Asynchronní odstranění: Proces mimo pracovní postup zpracování zpráv odstraní zprávu a datovou část. Oddělí proces odstranění od pracovního postupu zpracování zpráv a minimalizuje použití výpočetních postupů zasílání zpráv.

• Podmíněně implementujte vzor. Začleňte logiku do odesílající aplikace, která používá vzor Deklarace identity, pokud velikost zprávy překročí limit systému zasílání zpráv. U menších zpráv obejděte vzor a odešlete menší zprávu do systému zasílání zpráv. Tento podmíněný přístup snižuje latenci, optimalizuje využití prostředků a zlepšuje propustnost.

Kdy použít vzor Claim-Check

Následující scénáře jsou hlavními případy použití pro vzor Claim-Check:

• Omezení systému zasílání zpráv: Použijte model Kontroly deklarací identity, když velikosti zpráv překračují limity systému zasílání zpráv. Přesměrujte datovou část do externího úložiště. Odešlete do zprávového systému pouze zprávu s kontrolním tokenem.

• Výkon systému zasílání zpráv: Použijte model Kontroly deklarací identity, když velké zprávy zatěžují systém zasílání zpráv a snižují výkon systému.

Následující scénáře jsou sekundární případy použití pro model Kontroly deklarací identity:

• Ochrana citlivých dat: Pokud datová část obsahuje citlivá data, která nechcete vidět v systému zasílání zpráv, použijte vzor Claim-Check. Použijte vzor u všech citlivých informací nebo jejich částí v datové části. Zabezpečte citlivá data, aniž byste je přenášeli přímo přes systém zasílání zpráv.

• Složité scénáře směrování: Zprávy procházející více komponent mohou způsobit výkonnostní problémy kvůli serializaci, deserializaci, šifrování a dešifrování činnostem. Pomocí vzoru deklarací identity můžete zabránit přímému zpracování zpráv zprostředkujícími komponentami.

Návrh zatížení se vzorem Claim-Check

Architekt by měl vyhodnotit způsob použití modelu Claim-Check v návrhu úlohy k řešení cílů a principů popsaných v pilířích Azure Well-Architected Framework. Příklad:

Pilíř	Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, že se po selhání plně obnoví .	Systémy zasílání zpráv neposkytují stejnou spolehlivost a zotavení po havárii, které jsou často přítomné ve vyhrazených úložištích dat. Oddělení dat od zprávy může zvýšit spolehlivost datové části. Toto oddělení usnadňuje redundanci dat, která umožňuje obnovit datové části po havárii. RE:03 Analýza režimu selhání RE:09 Zotavení po havárii
Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů úloh.	Model Kontroly deklarací identity může extrahovat citlivá data ze zpráv a ukládat je do zabezpečeného úložiště dat. Toto nastavení umožňuje implementovat přísnější řízení přístupu a zajistit tak, aby k němu měly přístup jenom služby určené k používání citlivých dat. Zároveň skryje tato data před nesouvisejícími službami, jako jsou například data používaná pro monitorování front. SE:03 Klasifikace dat SE:04 Segmentace
Optimalizace nákladů se zaměřuje na udržení a zlepšení návratnosti vašich úloh.	Systémy zasílání zpráv často omezují velikost zpráv a vyšší limity velikosti jsou často prémiovou funkcí. Zmenšení velikosti textu zpráv vám může umožnit používat levnější řešení zasílání zpráv. CO:07 Náklady na komponenty CO:09 Náklady na tok
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky optimalizací škálování, přenosu dat a spouštěním kódu.	Model Kontroly deklarací identity zlepšuje efektivitu odesílání a přijímání aplikací a systému zasílání zpráv díky efektivnější správě velkých zpráv. Zmenšuje velikost zpráv odesílaných do systému zasílání zpráv a zajišťuje, že aplikace přistupují k velkým zprávám jenom v případě potřeby. PE:05 Škálování a dělení PE:12 Průběžná optimalizace výkonu

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklady vzorů kontroly deklarací identity

Následující příklady ukazují, jak Azure usnadňuje implementaci modelu Claim-Check:

• Azure systémů zasílání zpráv: Příklady zahrnují čtyři různé scénáře systému zasílání zpráv Azure: Azure Queue Storage, Azure Event Hubs (standardní rozhraní API), Azure Service Bus a Azure Event Hubs ( Kafka API).

• Automatické vs. ruční generování tokenů deklarací identity: Tyto příklady také ukazují dvě metody generování tokenu kontroly deklarací identity. V příkladech kódu 1–3 Azure Event Grid automaticky vygeneruje token, když aplikace odešle payload do Azure Blob Storage. Příklad kódu 4 ukazuje proces ručního generování tokenů pomocí spustitelného klienta příkazového řádku.

Zvolte příklad, který vyhovuje vašim potřebám, a podle zadaného odkazu zobrazte kód na GitHub:

Ukázkový kód	Scénáře systému zasílání zpráv	Generátor tokenů	Příjem softwarové aplikace	Úložiště dat
Příklad kódu 1	Azure Queue Storage	Azure Event Grid	Funkce	Azure Blob Storage (úložiště objektů Azure)
Příklad kódu 2	Azure Event Hubs (standardní rozhraní API)	Azure Event Grid	Spustitelný klient příkazového řádku	Azure Blob Storage (úložiště objektů Azure)
Příklad kódu 3	Azure Service Bus	Azure Event Grid	Funkce	Azure Blob Storage (úložiště objektů Azure)
Příklad kódu 4	Azure Event Hubs (Kafka API)	Spustitelný klient příkazového řádku	Funkce	Azure Blob Storage (úložiště objektů Azure)

Další kroky

• Web Vzory podnikové integrace má popis tohoto modelu.
• Další příklad najdete v článku Řešení problémů s velkými zprávami v Service Bus pomocí vzoru Claim-Check (blog).
• Alternativním vzorem pro zpracování velkých zpráv je Rozdělení a Agregace.
• Knihovny, jako je NServiceBus, poskytují podporu tohoto modelu pomocí funkce DataBus.

Související prostředky

• Model asynchronní odpovědi na požadavek
• Model konkurenčních spotřebitelů
• Sekvenční vzor convoy

Model Kontroly deklarací identity umožňuje úlohám přenášet datové části bez uložení datové části do systému zasílání zpráv. Model ukládá datovou část do externího úložiště dat a k načtení datové části používá "žádankovou kontrolu". Kontrola deklarace identity je jedinečný, nejasný token nebo klíč. Aby aplikace mohly načíst datovou část, musí předložit token pro kontrolu žádosti do externího úložiště dat.

Kontext a problém

Tradiční systémy zasílání zpráv jsou optimalizované pro správu velkého objemu malých zpráv a často mají omezení velikosti zprávy, kterou můžou zpracovat. Velké zprávy nejen riskují překročení těchto limitů, ale mohou také snížit výkon celého systému, když je systém zasílání zpráv ukládá.

Řešení

Použijte vzor Kontroly deklarací identity a neodesílejte velké zprávy do systému zasílání zpráv. Místo toho odešlete datovou část do externího úložiště dat a vygenerujte token kontroly deklarací identity pro danou datovou část. Systém zasílání zpráv odešle zprávu s tokenem kontroly žádosti přijímajícím aplikacím, aby mohly načíst datovou část z úložiště dat. Systém zasílání zpráv nikdy neuvidí ani neuloží datovou část.

Diagram vzoru Claim-Check.

1. Užitečné zatížení
2. Uložte payload do datového úložiště.
3. Vygenerujte token kontroly deklarací identity a odešlete zprávu pomocí tokenu deklarace identity.
4. Přijmout zprávu a přečíst token pro kontrolu identity.
5. Načtěte datovou část.
6. Zpracujte datovou část

Problémy a úvahy ohledně vzoru Claim-Check

Při implementaci modelu Deklarace identity zvažte následující doporučení:

• Odstraňte spotřebované zprávy. Pokud zprávu nepotřebujete archivovat, odstraňte zprávu a datovou část poté, co ji přijímající aplikace zpracují. Použijte buď synchronní nebo asynchronní strategii odstranění:

  • Synchronní odstranění: Spotřebová aplikace odstraní zprávu a datovou část hned po spotřebě. Sváže odstranění s pracovním postupem zpracování zpráv a používá výpočetní kapacitu pracovního postupu zasílání zpráv.

  • Asynchronní odstranění: Proces mimo pracovní postup zpracování zpráv odstraní zprávu a datovou část. Oddělí proces odstranění od pracovního postupu zpracování zpráv a minimalizuje použití výpočetních postupů zasílání zpráv.

• Podmíněně implementujte vzor. Začleňte logiku do odesílající aplikace, která používá vzor Deklarace identity, pokud velikost zprávy překročí limit systému zasílání zpráv. U menších zpráv obejděte vzor a odešlete menší zprávu do systému zasílání zpráv. Tento podmíněný přístup snižuje latenci, optimalizuje využití prostředků a zlepšuje propustnost.

Kdy použít vzor Claim-Check

Následující scénáře jsou hlavními případy použití pro vzor Claim-Check:

• Omezení systému zasílání zpráv: Použijte model Kontroly deklarací identity, když velikosti zpráv překračují limity systému zasílání zpráv. Přesměrujte datovou část do externího úložiště. Odešlete do zprávového systému pouze zprávu s kontrolním tokenem.

• Výkon systému zasílání zpráv: Použijte model Kontroly deklarací identity, když velké zprávy zatěžují systém zasílání zpráv a snižují výkon systému.

Následující scénáře jsou sekundární případy použití pro model Kontroly deklarací identity:

• Ochrana citlivých dat: Pokud datová část obsahuje citlivá data, která nechcete vidět v systému zasílání zpráv, použijte vzor Claim-Check. Použijte vzor u všech citlivých informací nebo jejich částí v datové části. Zabezpečte citlivá data, aniž byste je přenášeli přímo přes systém zasílání zpráv.

• Složité scénáře směrování: Zprávy procházející více komponent mohou způsobit výkonnostní problémy kvůli serializaci, deserializaci, šifrování a dešifrování činnostem. Pomocí vzoru deklarací identity můžete zabránit přímému zpracování zpráv zprostředkujícími komponentami.

Návrh zatížení se vzorem Claim-Check

Architekt by měl vyhodnotit způsob použití modelu Claim-Check v návrhu úlohy k řešení cílů a principů popsaných v pilířích Azure Well-Architected Framework. Příklad:

Pilíř	Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, že se po selhání plně obnoví .	Systémy zasílání zpráv neposkytují stejnou spolehlivost a zotavení po havárii, které jsou často přítomné ve vyhrazených úložištích dat. Oddělení dat od zprávy může zvýšit spolehlivost datové části. Toto oddělení usnadňuje redundanci dat, která umožňuje obnovit datové části po havárii. RE:03 Analýza režimu selhání RE:09 Zotavení po havárii
Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů úloh.	Model Kontroly deklarací identity může extrahovat citlivá data ze zpráv a ukládat je do zabezpečeného úložiště dat. Toto nastavení umožňuje implementovat přísnější řízení přístupu a zajistit tak, aby k němu měly přístup jenom služby určené k používání citlivých dat. Zároveň skryje tato data před nesouvisejícími službami, jako jsou například data používaná pro monitorování front. SE:03 Klasifikace dat SE:04 Segmentace
Optimalizace nákladů se zaměřuje na udržení a zlepšení návratnosti vašich úloh.	Systémy zasílání zpráv často omezují velikost zpráv a vyšší limity velikosti jsou často prémiovou funkcí. Zmenšení velikosti textu zpráv vám může umožnit používat levnější řešení zasílání zpráv. CO:07 Náklady na komponenty CO:09 Náklady na tok
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky optimalizací škálování, přenosu dat a spouštěním kódu.	Model Kontroly deklarací identity zlepšuje efektivitu odesílání a přijímání aplikací a systému zasílání zpráv díky efektivnější správě velkých zpráv. Zmenšuje velikost zpráv odesílaných do systému zasílání zpráv a zajišťuje, že aplikace přistupují k velkým zprávám jenom v případě potřeby. PE:05 Škálování a dělení PE:12 Průběžná optimalizace výkonu

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklady vzorů kontroly deklarací identity

Následující příklady ukazují, jak Azure usnadňuje implementaci modelu Claim-Check:

• Azure systémů zasílání zpráv: Příklady zahrnují čtyři různé scénáře systému zasílání zpráv Azure: Azure Queue Storage, Azure Event Hubs (standardní rozhraní API), Azure Service Bus a Azure Event Hubs ( Kafka API).

• Automatické vs. ruční generování tokenů deklarací identity: Tyto příklady také ukazují dvě metody generování tokenu kontroly deklarací identity. V příkladech kódu 1–3 Azure Event Grid automaticky vygeneruje token, když aplikace odešle payload do Azure Blob Storage. Příklad kódu 4 ukazuje proces ručního generování tokenů pomocí spustitelného klienta příkazového řádku.

Zvolte příklad, který vyhovuje vašim potřebám, a podle zadaného odkazu zobrazte kód na GitHub:

Ukázkový kód	Scénáře systému zasílání zpráv	Generátor tokenů	Příjem softwarové aplikace	Úložiště dat
Příklad kódu 1	Azure Queue Storage	Azure Event Grid	Funkce	Azure Blob Storage (úložiště objektů Azure)
Příklad kódu 2	Azure Event Hubs (standardní rozhraní API)	Azure Event Grid	Spustitelný klient příkazového řádku	Azure Blob Storage (úložiště objektů Azure)
Příklad kódu 3	Azure Service Bus	Azure Event Grid	Funkce	Azure Blob Storage (úložiště objektů Azure)
Příklad kódu 4	Azure Event Hubs (Kafka API)	Spustitelný klient příkazového řádku	Funkce	Azure Blob Storage (úložiště objektů Azure)

Další kroky

• Web Vzory podnikové integrace má popis tohoto modelu.
• Další příklad najdete v článku Řešení problémů s velkými zprávami v Service Bus pomocí vzoru Claim-Check (blog).
• Alternativním vzorem pro zpracování velkých zpráv je Rozdělení a Agregace.
• Knihovny, jako je NServiceBus, poskytují podporu tohoto modelu pomocí funkce DataBus.

Související prostředky

• Model asynchronní odpovědi na požadavek
• Model konkurenčních spotřebitelů
• Sekvenční vzor convoy