Asynchrone berichtpatronen en hoge beschikbaarheid

Asynchrone berichten kunnen op verschillende manieren worden geïmplementeerd. Met wachtrijen, onderwerpen en abonnementen ondersteunt Azure Service Bus asynchroonisme 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 deze entiteiten die altijd beschikbaar zijn. Wanneer de status van de entiteit verandert vanwege verschillende omstandigheden, hebt u een manier nodig om een entiteit met beperkte mogelijkheden 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 effenen door een plaats te bieden om communicatie te bufferen. 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, kunt u een aantal verschillende manieren overwegen waarop deze entiteiten niet beschikbaar kunnen worden weergegeven voor een duurzaam berichtensysteem. Over het algemeen zien we dat de entiteit niet meer beschikbaar is voor toepassingen die we op de volgende verschillende manieren schrijven:

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

Voor elk van deze fouten bestaan er verschillende foutmodi waarmee een toepassing op een bepaald niveau van verminderde mogelijkheden kan blijven werken. Een systeem dat bijvoorbeeld berichten kan verzenden maar niet ontvangt, kan nog steeds orders ontvangen van klanten, maar die 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 waarmee 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 meestal kort. Op hoog niveau worden de verschillende oorzaken van onbeschikbaarheid als volgt weergegeven:

• Beperking van een extern systeem waarop Service Bus afhankelijk is. Beperking vindt plaats vanuit interacties met opslag- en rekenresources.
• Probleem voor een systeem waarop 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 zichzelf opnieuw opstarten, waardoor alle entiteiten die het dient om de taakverdeling naar andere knooppunten te verdelen. Dit kan op zijn beurt leiden tot een korte periode van trage verwerking van berichten.
• Fout in Service Bus in een Azure-datacenter. Dit is een 'onherstelbare fout' waarbij het systeem gedurende 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 zorgt beperking voor het beheer van coöperatief berichtenpercentage. Elk afzonderlijk Service Bus-knooppunt bevat veel entiteiten. Elk van deze entiteiten stelt eisen aan het systeem in termen van CPU, geheugen, opslag en andere facetten. Wanneer een van deze facetten het gebruik detecteert dat de gedefinieerde drempelwaarden worden overschreden, kan Service Bus een bepaalde aanvraag weigeren. De beller ontvangt een serverbezette uitzondering en probeert na 10 seconden opnieuw.

Als beperking 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 onafhankelijk de logica voor opnieuw proberen uitvoert. De code kan de kans verminderen dat deze wordt beperkt door partitionering in te schakelen voor een naamruimte, wachtrij of onderwerp.

Zie de documentatie over het beperkingspatroon voor meer informatie over hoe toepassingscode problemen moet afhandelen.

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 verminderde mogelijkheden ervaren. Om dit soort problemen te omzeilen, onderzoekt En implementeert Service Bus regelmatig oplossingen. Bijwerkingen van deze oplossingen worden wel weergegeven. Als u bijvoorbeeld tijdelijke problemen met opslag wilt afhandelen, implementeert Service Bus een systeem waarmee verzendbewerkingen voor berichten consistent kunnen werken. Over het algemeen ondervinden de meeste entiteiten dit probleem niet. Gezien het aantal entiteiten in Service Bus in Azure is deze beperking soms 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, worden er gegevens verzameld uit de toepassing om te helpen bij het diagnosticeren van wat er is gebeurd. Zodra de gegevens zijn verzameld, wordt de toepassing opnieuw opgestart in een poging om deze terug te keren naar een consistente status. Dit proces vindt vrij snel plaats en resulteert in een entiteit die maximaal een paar minuten niet beschikbaar lijkt te zijn, hoewel typische uitvallende tijden 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 geautomatiseerde logica voor opnieuw proberen van clients. Zodra de periode voor opnieuw proberen is uitgeput en het bericht niet wordt bezorgd, kunt u verkennen met behulp van andere informatie die wordt vermeld in het artikel over het afhandelen van storingen en rampen.

Volgende stappen

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