Vzory asynchronního zasílání zpráv a vysoká dostupnost

Asynchronní zasílání zpráv je možné implementovat různými způsoby. U front, témat a předplatných Azure Service Bus podporuje asynchronismus prostřednictvím mechanismu úložiště a předávání. V normálním (synchronním) provozu odesíláte zprávy do front a témat a přijímáte zprávy z front a odběrů. Aplikace, které napíšete, závisí na tom, že tyto entity budou vždy k dispozici. Když se stav entity kvůli různým okolnostem změní, potřebujete způsob, jak poskytnout entitu s omezenými schopnostmi, která dokáže uspokojit většinu potřeb.

Aplikace obvykle používají vzory asynchronního zasílání zpráv k povolení řady komunikačních scénářů. Můžete vytvářet aplikace, ve kterých můžou klienti odesílat zprávy službám, i když služba není spuštěná. U aplikací, u které dochází k nárazům komunikace, může fronta pomoct vyrovnat zatížení tím, že poskytuje místo 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 mohou zdát nedostupné pro odolný systém zasílání zpráv. Obecně vidíme, že entita přestane být dostupná pro aplikace, které píšeme, následujícími různými způsoby:

• Nelze odesílat zprávy.
• Nelze přijímat zprávy.
• Nelze spravovat entity (vytváření, načítání, aktualizace nebo odstraňování entit).
• Nelze kontaktovat službu.

Pro každou z těchto selhání existují různé režimy selhání, které aplikaci umožňují pokračovat v práci na určité úrovni omezené schopnosti. Například systém, který může odesílat zprávy, ale nemůže je přijímat, může dál 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 jejich zmírnění. Služba Service Bus zavedla řadu zmírnění rizik, ke kterým se musíte přihlásit, a toto téma také popisuje pravidla, kterými se řídí použití 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 zmírnění rizik. Abyste porozuměli pokynům, musíte nejprve porozumět tomu, co může selhat ve službě Service Bus. Vzhledem k návrhu systémů Azure bývají všechny tyto problémy krátkodobé. Na vysoké úrovni se různé příčiny nedostupnosti objevují takto:

• Omezování z externího systému, na kterém je služba Service Bus závislá. K omezování dochází při interakcích s úložištěm a výpočetními prostředky.
• Problém pro systém, na kterém je služba Service Bus závislá K problémům může dojít například u dané části úložiště.
• Selhání služby Service Bus v jednom subsystému V této situaci 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ží, vyrovnává zatížení do jiných uzlů. To zase může způsobit krátké období pomalého zpracování zpráv.
• Selhání služby Service Bus v datacentru 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ů. Následující části popisují jednotlivé problémy a jejich zmírnění.

Throttling

Ve 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 klade na systém požadavky 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 daný požadavek zamítnout. Volající obdrží výjimku zaneprázdněného serveru a po 10 sekundách se znovu pokusí.

Jako zmírnění rizik musí kód přečíst chybu a zastavit jakékoli opakování zprávy po dobu alespoň 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 omezení povolením dělení v oboru názvů, frontě nebo tématu.

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

Problém se závislostí Azure

Jiné komponenty v Rámci Azure můžou občas mít problémy se službami. Když se například upgraduje systém, který používá služba Service Bus, může tento systém dočasně zaznamenat omezené možnosti. Aby bylo možné tyto typy problémů obejít, služba Service Bus pravidelně zkoumá a implementuje zmírnění rizik. Nežádoucí účinky těchto zmírnění se objevují. Například pro zpracování přechodných problémů s úložištěm implementuje Service Bus systém, který umožňuje, aby operace odesílání zpráv fungovaly konzistentně. Vzhledem k povaze zmírnění rizik může trvat až 15 minut, než se odeslaná zpráva zobrazí v ovlivněné frontě nebo předplatném a bude připravená na operaci příjmu. Obecně řečeno, u většiny entit se tento problém nezobrazí. Vzhledem k počtu entit ve službě Service Bus v Rámci Azure je však toto zmírnění rizik 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í součást služby Service Bus. Když to služba Service Bus zjistí, shromažďuje data z aplikace, aby pomohla diagnostikovat, co se stalo. Jakmile se data shromáždí, aplikace se restartuje, aby se vrátila do konzistentního stavu. Tento proces probíhá poměrně rychle a výsledkem je, že se entita zdá být nedostupná až několik minut, i když typické doby výpadku jsou 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 automatizovaného opakování klienta. Jakmile se doba opakování vyčerpá a zpráva se nedoručí, můžete prozkoumat další informace uvedené v článku o řešení 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 řešení výpadků a havárií.