Model konkurujících si příjemců

Umožňuje několika souběžným příjemcům zpracovávat zprávy přijaté ve stejném kanálu pro zasílání zpráv. Díky více souběžným příjemcům může systém zpracovávat více zpráv současně za účelem optimalizace propustnosti, zlepšení škálovatelnosti a dostupnosti a vyrovnávání zatížení.

Kontext a problém

Cloudová aplikace často zpracovává velký počet požadavků. Místo synchronního zpracování jednotlivých požadavků může aplikace předávat žádosti prostřednictvím systému zasílání zpráv do služby příjemce, která je zpracovává asynchronně. Tato strategie pomáhá bránit tomu, aby zpracování požadavků blokovalo obchodní logiku aplikace.

Počet požadavků se v průběhu času může výrazně lišit. Náhlé zvýšení aktivity uživatelů nebo agregovaných požadavků z více tenantů může vytvořit nepředvídatelnou úlohu. Ve špičkách může systém potřebovat zpracovat mnoho stovek požadavků za sekundu. Jindy může být číslo malé. Práce potřebná ke zpracování těchto požadavků se také může značně lišit. Pokud používáte jednu instanci spotřebitelské služby, žádosti mohou tuto instanci zahltit. Nebo příliv aplikačních zpráv může přetížit systém zasílání zpráv.

Aby se tato proměnlivá úloha zvládla, může systém spustit více instancí služby příjemce. Systém však musí tyto příjemce koordinovat, aby se zajistilo, že se každá zpráva doručí pouze jednomu příjemci. Systém musí také vyrovnávat zatížení napříč spotřebiteli, aby se zabránilo kritickým bodům jedné instance.

Řešení

Fronta zpráv slouží k implementaci komunikačního kanálu mezi aplikací a instancemi služby příjemce. Aplikace odesílá požadavky jako zprávy do fronty a instance služby spotřebitele přijímají a zpracovávají zprávy z fronty. Tento přístup umožňuje stejnému fondu instancí služby příjemce zpracovávat zprávy z libovolné instance aplikace. Následující diagram znázorňuje, jak fronta zpráv distribuuje práci do instancí služby.

Diagram má tři klíčové části. Na levé straně ukazují šipky z instancí aplikace do fronty zpráv uprostřed. Na pravé straně ukazují šipky z fronty zpráv do fondu instancí služby příjemce, který zpracovává zprávy.

Poznámka:

Tyto zprávy obdrží více příjemců, ale vzor Konkurenční spotřebitelé se liší od vzoru Publisher-Subscriber. V modelu Konkurující příjemci obdrží jeden příjemce každou zprávu ke zpracování. Ve vzoru Publisher-Subscriber obdrží všichni příjemci každou zprávu.

Toto řešení má tyto výhody:

• Poskytuje vyvážený systém zatížení, který dokáže zpracovávat široké variace objemu požadavků z instancí aplikace. Fronta funguje jako vyrovnávací paměť mezi instancemi aplikací a instancemi služeb spotřebitele. Tento buffer může minimalizovat dopad na dostupnost a odezvu pro instance aplikace i služby. Další informace naleznete v vzorovém postupu vyrovnávání zatížení na základě fronty. Zpráva, která potřebuje dlouhotrvající zpracování, nebrání jiným instancím spotřebitelské služby ve zpracování dalších zpráv současně.

• Zvyšuje spolehlivost. Pokud producent komunikuje přímo se spotřebitelem místo použití tohoto vzoru a nemonitoruje příjemce, je velmi pravděpodobné, že přijde o zprávy nebo je nezpracuje, když příjemce selže. V tomto modelu systém neodesílá zprávy do konkrétní instance služby. Instance služby, která selhala, neblokuje producenta a jakákoli funkční instance služby může zpracovávat zprávy.

• Nevyžaduje složitou koordinaci mezi spotřebiteli nebo mezi instancemi producenta a příjemce. Fronta zpráv zajišťuje, že každá zpráva se doručí aspoň jednou.

• Škáluje se. Když použijete automatické škálování, systém může dynamicky zvýšit nebo snížit počet instancí služby příjemce, protože objem zpráv kolísá.

• Pokud fronta zpráv poskytuje transakční operace čtení, může se zvýšit odolnost. Pokud instance služby příjemce přečte a zpracuje zprávu jako součást transakční operace a selže, může tento model zajistit, aby se zpráva vrátila do fronty, aby ji mohl zpracovat jiná instance služby příjemce. Pokud chcete zmírnit riziko průběžných selhání zpráv, doporučujeme používat fronty nedoručených zpráv.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

• Řazení zpráv: Pořadí, ve kterém instance služby příjemce přijímají zprávy, není zaručeno a nemusí nutně zobrazovat pořadí, ve kterém byly zprávy vytvořeny. Navrhněte systém tak, aby zpracovával zprávy idempotentně. Tento návrh pomáhá eliminovat závislosti pořadí zpracování.

  Azure Service Bus může implementovat garantované pořadí zpráv při prvním odeslání a dalších vzorů pomocí relací zpráv.

• Požadavky na odolnost služeb: Pokud systém zjistí a restartuje neúspěšné instance služby, může být potřeba implementovat operace, které tyto instance služby provádějí jako idempotentní, aby se minimalizovaly účinky při načítání a zpracování jedné zprávy více než jednou.

• Detekce otrávené zprávy: Chybná zpráva nebo úloha, která vyžaduje přístup k nedostupným prostředkům, může způsobit selhání instance služby. Systém by měl těmto zprávám zabránit v návratu do fronty na neomezenou dobu a místo toho zachytávat a ukládat podrobnosti na jiném místě pro účely analýzy v případě potřeby. Service Bus může automaticky odesílat zprávy do fronty nedoručených zpráv po překročení nakonfigurované MaxDeliveryCount prahové hodnoty.

• Zpracování výsledků: Instance služby, která zpracovává zprávu, je plně oddělená od logiky aplikace, která zprávu generuje, takže nemusí být schopná komunikovat přímo. Pokud instance služby generuje výsledky, které se musí vrátit do logiky aplikace, uložte tyto informace do umístění, ke kterému mají obě komponenty přístup. Aby logika aplikace nemohla načítat neúplná data, musí systém indikovat, kdy se zpracování dokončí. Pracovní proces může předávat výsledky zpět do logiky aplikace prostřednictvím vyhrazené fronty odpovědí na zprávu. Je nutné, aby aplikační logika mohla zjišťovat korelaci těchto výsledků s původní zprávou.

• Škálování systému zasílání zpráv: V rozsáhlém řešení může velký objem zpráv zahltit jednu frontu zpráv a způsobit úzké hrdlo systému. V takovém případě zvažte rozdělení systému zasílání zpráv tak, aby odesílala zprávy od konkrétních výrobců do konkrétní fronty, nebo vyrovnávání zatížení pro distribuci zpráv mezi více front zpráv.

• Spolehlivost systému zasílání zpráv: Použijte spolehlivý systém zasílání zpráv, abyste zajistili, že se zprávy po jejich zařazení do fronty aplikace neztratí. Tato funkce je nezbytná k zajištění, aby se všechny zprávy doručily alespoň jednou.

Kdy použít tento vzor

Tento model použijte v těchto případech:

• Úloha aplikace je rozdělená na úlohy, které se dají spustit asynchronně.

• Úlohy jsou nezávislé a můžou běžet paralelně.

• Pracovní svazek je vysoce proměnlivý a vyžaduje škálovatelné řešení.

• Řešení musí poskytovat vysokou dostupnost a zůstat odolná při selhání zpracování úloh.

Tento vzor nemusí být vhodný v těchto případech:

• Úlohy aplikace nemůžete snadno oddělit do samostatných úloh nebo existuje vysoký stupeň závislosti mezi úlohami.

• Úlohy musí běžet synchronně a logika aplikace musí před pokračováním čekat na dokončení každého úkolu.

• Úlohy se musí spouštět v určité sekvenci.

Poznámka:

Některé systémy zasílání zpráv podporují relace, které umožňují seskupení zpráv producenta a zajišťují, aby stejný příjemce zpracovával všechny zprávy ve skupině. Tento mechanismus můžete použít s prioritními zprávami v případě, že se podporuje vynucení řazení zpráv a doručování zpráv v pořadí od producenta do jednoho příjemce.

Návrh úloh

Vyhodnoťte, jak použít model Konkurenční spotřebitelé v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Tento model vytváří redundanci zpracování front tím, že zpracovává spotřebitele jako repliky, takže selhání instance nezabrání jiným spotřebitelům ve zpracování zpráv ve frontě. - RE:05 Redundance - Úlohy na pozadí
Optimalizace nákladů se zaměřuje na udržení a zlepšenínávratnosti vašich úloh.	Tento vzorec může pomoci optimalizovat náklady, protože se škáluje podle hloubky fronty a může se zmenšit na nulu, když fronta zůstane prázdná. Může také optimalizovat náklady, protože můžete omezit maximální počet souběžných instancí příjemců. - CO:05 Optimalizace rychlosti - CO:07 Náklady na komponenty
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Tento model distribuuje zátěž mezi uzly příjemců, aby se zvýšilo využití, a dynamické škálování podle hloubky fronty minimalizuje nadměrné zřizování. - PE:05 Škálování a dělení - PE:07 Kód a infrastruktura

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Příklad

Azure poskytuje fronty Service Bus a frontové triggery Azure Functions, které společně implementují tento vzor návrhu cloudu přímo. Funkce se integrují se službou Service Bus prostřednictvím triggerů a vazeb. Tato integrace umožňuje vytvářet funkce, které přijímají zprávy z fronty od vydavatelů. Publikační aplikace posílají zprávy do fronty a příjemci implementovaní jako "Functions" mohou tyto zprávy načítat a zpracovávat.

Pro zajištění odolnosti umožňuje fronta služby Service Bus uživateli použít režim PeekLock, když stahuje zprávu z fronty. Tento režim uchovává zprávu, ale skryje ji před ostatními uživateli. Modul runtime Služby Functions obdrží zprávu v režimu PeekLock. Pokud se funkce úspěšně provede, volá modul runtime Complete na zprávu. Pokud funkce selže, modul runtime může zavolat Abandon a znovu zobrazit zprávu, aby ji mohl načíst jiný příjemce. Pokud funkce běží déle, než je časový limit PeekLock, modul runtime automaticky obnovuje zámek po dobu, kdy funkce běží.

Na levé straně ukazuje šipka z aplikace do oddílu zprávy, který obsahuje Service Bus. Šipka označená jako "selhání" vede z této sekce do fronty nevyřízených zpráv. Další řádek z oddílu zprávy se rozdělí na dvě šipky, které jsou očíslované 1 a 2, které odkazují na příjemce 1 a příjemce 2.

Funkce automaticky škáluje počet instancí příjemců na základě hloubky fronty a provozu. Toto škálování umožňuje řešení zpracovávat nárůsty práce a současně minimalizovat náklady během období s nízkým objemem. Pokud Functions vytváří více instancí, budou se navzájem soutěžit tím, že nezávisle stahují a zpracovávají zprávy. Další informace najdete v tématu Fronty, témata a předplatná služby Service Bus, a spouštěč služby Service Bus pro funkce.

Další informace o tom, jak používat klientskou knihovnu Service Bus pro .NET k odesílání zpráv do fronty služby Service Bus, najdete v publikovaných příkladech.

Další kroky

• Volba služby zasílání zpráv v Azure: Zjistěte, jak různé služby zasílání zpráv Azure, jako jsou Service Bus, fronty Azure Storage, Azure Event Hubs a Azure Event Grid, podporují asynchronní komunikační vzory a jak zvolit správný model služby a zasílání zpráv pro váš scénář.

• Osvědčené postupy automatického škálování: Naučte se navrhovat řešení, která škálují instance příjemců na základě úloh, jako je délka fronty nebo propustnost zpráv, abyste mohli zpracovávat náklady na zatížení ve špičce a řídit náklady během období nízké aktivity.

Související prostředky

• Model konsolidace výpočetních prostředků: Můžete být schopni konsolidovat více instancí služby příjemce do jednoho procesu, aby se snížily náklady a režijní náklady na správu. Model konsolidace výpočetních prostředků popisuje výhody a kompromisy tohoto přístupu.

• Model vyrovnávání zatížení na základě fronty: Fronta zpráv může do systému přidat odolnost. Odolnost umožňuje instancím služby zpracovávat široce proměnlivé objemy požadavků z instancí aplikací. Fronta zpráv funguje jako vyrovnávací paměť, která vyrovná zatížení. Model vyrovnávání zatížení frontou popisuje tento scénář podrobněji.