Asynchronní schémata zasílání zpráv a vysoká dostupnost

Asynchronní zasílání zpráv je možné implementovat různými způsoby. Díky frontám, tématům a předplatným podporuje Azure Service Bus asynchronní asynchronismus prostřednictvím mechanismu úložiště a předávání. V normální (synchronní) operaci odesíláte zprávy do front a témat a přijímáte zprávy z front a odběrů. Aplikace, které píšete, závisí na tom, že tyto entity jsou vždy dostupné. Když se stav entity změní z důvodu různých okolností, potřebujete způsob, jak poskytnout entitu s omezenou schopností, která může vyhovovat většině potřeb.

Aplikace obvykle používají asynchronní vzory zasílání zpráv, které umožňují řadu komunikačních scénářů. Můžete vytvářet aplikace, ve kterých můžou klienti odesílat zprávy do služeb, i když služba není spuštěná. Pro aplikace, které se setká s nárůsty komunikace, může fronta pomoct vyrovnat zatížení poskytnutím místa pro ukládání komunikace do vyrovnávací paměti. Nakonec můžete získat jednoduchý, ale efektivní nástroj pro vyrovnávání zatížení pro distribuci zpráv mezi více počítačů.

Pokud chcete zachovat dostupnost některé z těchto entit, zvažte řadu různých způsobů, jak se tyto entity můžou zobrazovat jako nedostupné pro odolný systém zasílání zpráv. Obecně řečeno, vidíme, že entita je pro aplikace, které píšeme, nedostupná následujícími způsoby:

• Zprávy nelze odeslat.
• Zprávy nelze přijímat.
• Nelze spravovat entity (vytváření, načítání, aktualizace nebo odstraňování entit).
• Službu nelze kontaktovat.

Pro každou z těchto selhání existují různé režimy selhání, které aplikaci umožňují pokračovat v provádění práce na určité úrovni omezené schopnosti. Například systém, který může odesílat zprávy, ale neobdrží je, může stále přijímat objednávky od zákazníků, ale nemůže tyto objednávky zpracovat. Toto téma popisuje potenciální problémy, ke kterým může dojít, a způsob zmírnění těchto problémů. Služba Service Bus zavedla řadu omezení rizik, ke kterým se musíte přihlásit, a toto téma také popisuje pravidla týkající se používání těchto omezení rizik.

Spolehlivost ve službě Service Bus

Existuje několik způsobů, jak řešit problémy se zprávami a entitami a existují pokyny, kterými se řídí vhodné použití těchto omezení rizik. Abyste porozuměli pokynům, musíte nejprve pochopit, co může ve službě Service Bus selhat. Vzhledem k návrhu systémů Azure jsou všechny tyto problémy krátkodobé. Na vysoké úrovni se různé příčiny nedostupnosti zobrazují takto:

• Omezování z externího systému, na kterém služba Service Bus závisí. Omezování probíhá z interakcí s úložištěm a výpočetními prostředky.
• Problém se systémem, na kterém závisí Service Bus. Například na danou část úložiště může dorazit na problémy.
• Selhání služby Service Bus v jednom subsystému V takovém případě se výpočetní uzel může dostat do nekonzistentního stavu a musí se restartovat, což způsobí, že všechny entity, které slouží k vyrovnávání zatížení do jiných uzlů. To zase může způsobit krátkou dobu pomalého zpracování zpráv.
• Selhání služby Service Bus v rámci datacentra Azure Jedná se o "katastrofické selhání", během kterého je systém nedostupný po mnoho minut nebo několik hodin.

Poznámka:

Termín úložiště může znamenat Azure Storage i SQL Azure.

Service Bus obsahuje řadu zmírnění těchto problémů. V následujících částech najdete informace o jednotlivých potížích a jejich příslušných zmírněních rizik.

Omezování

Díky službě Service Bus umožňuje omezování spolupracovat na správě rychlosti zpráv. Každý uzel Service Bus obsahuje mnoho entit. Každá z těchto entit vyžaduje systém z hlediska procesoru, paměti, úložiště a dalších omezujících vlastností. Když některá z těchto omezujících vlastností zjistí využití, které překračuje definované prahové hodnoty, může Service Bus danou žádost zamítnout. Volající obdrží výjimku zaneprázdněného serveru a opakuje se po 10 sekundách.

Jako zmírnění rizik musí kód přečíst chybu a zastavit všechny opakování zprávy po dobu nejméně 10 sekund. Vzhledem k tomu, že k chybě může dojít napříč částmi aplikace zákazníka, očekává se, že každá část nezávisle spustí logiku opakování. Kód může snížit pravděpodobnost omezování tím, že povolí dělení na obor názvů, frontu nebo téma.

Další informace o tom, jak by kód aplikace měl zpracovávat problémy s omezováním, najdete v dokumentaci k modelu omezování.

Problém se závislostí Azure

Jiné komponenty v Azure můžou občas mít problémy se službami. Například když se upgraduje systém, který používá Service Bus, může tento systém dočasně zaznamenat omezené možnosti. Pokud chcete tyto typy problémů obejít, Service Bus pravidelně zkoumá a implementuje zmírnění rizik. Zobrazí se vedlejší účinky těchto zmírnění. Například kvůli zpracování přechodných problémů s úložištěm služba Service Bus implementuje systém, který umožňuje konzistentně fungovat operace odesílání zpráv. Obecně řečeno, většina entit nebude mít k tomuto problému zkušenosti. Vzhledem k počtu entit ve službě Service Bus v Rámci Azure je však toto zmírnění někdy potřeba pro malou podmnožinu zákazníků služby Service Bus.

Selhání služby Service Bus v jednom subsystému

U jakékoli aplikace můžou okolnosti způsobit nekonzistentní interní komponentu služby Service Bus. Když služba Service Bus tuto chybu zjistí, shromažďuje data z aplikace, aby pomohla diagnostikovat, co se stalo. Po shromáždění dat se aplikace restartuje při pokusu o vrácení do konzistentního stavu. K tomuto procesu dochází poměrně rychle a výsledkem je nedostupnost entity po dobu až několika minut, ale typická doba výpadku je mnohem kratší.

V těchto případech klientská aplikace vygeneruje výjimku časového limitu nebo výjimku zasílání zpráv. Service Bus obsahuje zmírnění tohoto problému ve formě logiky opakování automatizovaného klienta. Jakmile se období opakování vyčerpá a zpráva se nedoručí, můžete prozkoumat použití jiných uvedených v článku o zpracování výpadků a havárií.

Další kroky

Teď, když jste se seznámili se základy asynchronního zasílání zpráv ve službě Service Bus, si přečtěte další podrobnosti o zpracování výpadků a havárií.