Asynchrone berichtpatronen en hoge beschikbaarheid

Asynchrone berichten kunnen op verschillende manieren worden geïmplementeerd. Met wachtrijen, onderwerpen en abonnementen ondersteunt Azure Service Bus asynchroonheid via een opslag- en doorstuurmechanisme. In normale (synchrone) bewerking verzendt u berichten naar wachtrijen en onderwerpen en ontvangt u berichten van wachtrijen en abonnementen. Toepassingen die u schrijft, zijn afhankelijk van de beschikbaarheid van deze entiteiten. Wanneer de status van de entiteit vanwege verschillende omstandigheden verandert, hebt u een manier nodig om een beperkte capaciteitsentiteit te bieden die aan de meeste behoeften kan voldoen.

Toepassingen gebruiken doorgaans asynchrone berichtpatronen om een aantal communicatiescenario's mogelijk te maken. U kunt toepassingen bouwen waarin clients berichten naar services kunnen verzenden, zelfs wanneer de service niet wordt uitgevoerd. Voor toepassingen die bursts van communicatie ervaren, kan een wachtrij helpen de belasting te verdelen door een plaats te bieden voor buffercommunicatie. Ten slotte kunt u een eenvoudige maar effectieve load balancer krijgen om berichten over meerdere computers te distribueren.

Als u de beschikbaarheid van een van deze entiteiten wilt behouden, moet u een aantal verschillende manieren overwegen waarop deze entiteiten niet beschikbaar kunnen lijken voor een duurzaam berichtensysteem. Over het algemeen zien we dat de entiteit op de volgende verschillende manieren niet meer beschikbaar is voor toepassingen die we schrijven:

• Kan geen berichten verzenden.
• Kan geen berichten ontvangen.
• Kan entiteiten niet beheren (entiteiten maken, ophalen, bijwerken of verwijderen).
• Kan geen contact maken met de service.

Voor elk van deze fouten bestaan verschillende foutmodi waarmee een toepassing werk kan blijven uitvoeren op een bepaald niveau van beperkte capaciteit. Een systeem dat bijvoorbeeld berichten kan verzenden maar niet ontvangen, kan nog steeds orders van klanten ontvangen, maar kan deze orders niet verwerken. In dit onderwerp worden mogelijke problemen besproken die kunnen optreden en hoe deze problemen worden verzacht. Service Bus heeft een aantal oplossingen geïntroduceerd waarvoor u zich moet aanmelden. In dit onderwerp worden ook de regels besproken voor het gebruik van deze opt-in-oplossingen.

Betrouwbaarheid in Service Bus

Er zijn verschillende manieren om problemen met berichten en entiteiten af te handelen, en er zijn richtlijnen voor het juiste gebruik van deze oplossingen. Als u de richtlijnen wilt begrijpen, moet u eerst begrijpen wat er kan mislukken in Service Bus. Vanwege het ontwerp van Azure-systemen zijn al deze problemen vaak van korte duur. Op hoog niveau worden de verschillende oorzaken van onbeschikbaarheid als volgt weergegeven:

• Beperking van een extern systeem waarvan Service Bus afhankelijk is. Beperking treedt op als gevolg van interacties met opslag- en rekenresources.
• Probleem voor een systeem waarvan Service Bus afhankelijk is. Een bepaald deel van de opslag kan bijvoorbeeld problemen ondervinden.
• Fout van Service Bus op één subsysteem. In dit geval kan een rekenknooppunt een inconsistente status krijgen en moet het zichzelf opnieuw opstarten, waardoor alle entiteiten die het bedient, taken verdelen over andere knooppunten. Dit kan op zijn beurt leiden tot een korte periode van trage berichtverwerking.
• Fout van Service Bus in een Azure-datacenter. Dit is een 'catastrofale fout' waarbij het systeem vele minuten of een paar uur onbereikbaar is.

Notitie

De term opslag kan zowel Azure Storage als SQL Azure betekenen.

Service Bus bevat een aantal oplossingen voor deze problemen. In de volgende secties worden elk probleem en de bijbehorende oplossingen besproken.

Beperking

Met Service Bus maakt beperking het beheer van berichtfrequenties mogelijk. Elk afzonderlijk Service Bus-knooppunt bevat veel entiteiten. Elk van deze entiteiten stelt eisen aan het systeem op het gebied van CPU, geheugen, opslag en andere facetten. Wanneer een van deze facetten het gebruik detecteert dat de gedefinieerde drempelwaarden overschrijdt, kan Service Bus een bepaalde aanvraag weigeren. De aanroeper ontvangt een uitzondering voor server bezet en probeert na 10 seconden opnieuw.

Als oplossing moet de code de fout lezen en eventuele nieuwe pogingen van het bericht gedurende ten minste 10 seconden stoppen. Omdat de fout kan optreden in verschillende onderdelen van de klanttoepassing, wordt verwacht dat elk onderdeel de logica voor opnieuw proberen onafhankelijk uitvoert. De code kan de kans op beperking verminderen door partitionering in te schakelen voor een naamruimte, wachtrij of onderwerp.

Zie de documentatie over het beperkingspatroon voor meer informatie over hoe toepassingscode moet omgaan met beperkingsproblemen.

Probleem voor een Azure-afhankelijkheid

Andere onderdelen in Azure kunnen af en toe serviceproblemen hebben. Wanneer bijvoorbeeld een systeem dat door Service Bus wordt gebruikt, wordt bijgewerkt, kan dat systeem tijdelijk te maken krijgen met verminderde mogelijkheden. Om dit soort problemen te omzeilen, onderzoekt En implementeert Service Bus regelmatig oplossingen. Bijwerkingen van deze oplossingen verschijnen wel. Voor het afhandelen van tijdelijke problemen met opslag implementeert Service Bus bijvoorbeeld een systeem waarmee bewerkingen voor het verzenden van berichten consistent kunnen worden uitgevoerd. Vanwege de aard van de beperking kan het tot 15 minuten duren voordat een verzonden bericht wordt weergegeven in de betreffende wachtrij of het betreffende abonnement en klaar is voor een ontvangstbewerking. Over het algemeen zullen de meeste entiteiten dit probleem niet ervaren. Gezien het aantal entiteiten in Service Bus binnen Azure is deze beperking soms echter nodig voor een kleine subset van Service Bus-klanten.

Service Bus-fout op één subsysteem

Bij elke toepassing kunnen omstandigheden ertoe leiden dat een intern onderdeel van Service Bus inconsistent wordt. Wanneer Service Bus dit detecteert, verzamelt het gegevens uit de toepassing om te helpen bij het diagnosticeren van wat er is gebeurd. Zodra de gegevens zijn verzameld, wordt de toepassing opnieuw gestart in een poging om deze te herstellen naar een consistente status. Dit proces vindt vrij snel plaats en resulteert erin dat een entiteit tot een paar minuten niet beschikbaar lijkt te zijn, hoewel de normale tijden voor uitvallen veel korter zijn.

In deze gevallen genereert de clienttoepassing een time-outuitzondering of een berichtuitzondering. Service Bus bevat een oplossing voor dit probleem in de vorm van automatische logica voor opnieuw proberen van clients. Zodra de periode voor opnieuw proberen is uitgeput en het bericht niet wordt afgeleverd, kunt u verkennen met behulp van andere in het artikel vermelde informatie over het afhandelen van storingen en noodgevallen.

Volgende stappen

Nu u de basisbeginselen van asynchrone berichten in Service Bus hebt geleerd, kunt u meer informatie lezen over het afhandelen van storingen en noodgevallen.