Asynkrona meddelandemönster och hög tillgänglighet

Asynkrona meddelanden kan implementeras på olika sätt. Med köer, ämnen och prenumerationer stöder Azure Service Bus asynkronitet via en mekanism för lagring och vidarebefordran. I normal (synkron) åtgärd skickar du meddelanden till köer och ämnen och tar emot meddelanden från köer och prenumerationer. Program som du skriver beror på att dessa entiteter alltid är tillgängliga. När entitetens hälsotillstånd ändras på grund av en mängd olika omständigheter behöver du ett sätt att tillhandahålla en entitet med nedsatt kapacitet som kan uppfylla de flesta behov.

Program använder vanligtvis asynkrona meddelandemönster för att aktivera ett antal kommunikationsscenarier. Du kan skapa program där klienter kan skicka meddelanden till tjänster, även om tjänsten inte körs. För program som upplever kommunikationstoppar kan en kö hjälpa till att jämna ut belastningen genom att tillhandahålla en plats för buffertkommunikation. Slutligen kan du få en enkel men effektiv lastbalanserare för att distribuera meddelanden över flera datorer.

För att upprätthålla tillgängligheten för någon av dessa entiteter bör du överväga ett antal olika sätt på vilka dessa entiteter kan verka otillgängliga för ett varaktigt meddelandesystem. Generellt sett ser vi att entiteten blir otillgänglig för program som vi skriver på följande olika sätt:

• Det går inte att skicka meddelanden.
• Det går inte att ta emot meddelanden.
• Det går inte att hantera entiteter (skapa, hämta, uppdatera eller ta bort entiteter).
• Det går inte att kontakta tjänsten.

För vart och ett av dessa fel finns olika fellägen som gör att ett program kan fortsätta att utföra arbete på någon nivå med nedsatt kapacitet. Till exempel kan ett system som kan skicka meddelanden men inte ta emot dem fortfarande ta emot beställningar från kunder, men som inte kan bearbeta dessa beställningar. Det här avsnittet beskriver potentiella problem som kan uppstå och hur dessa problem åtgärdas. Service Bus har introducerat ett antal åtgärder som du måste välja, och i det här avsnittet beskrivs även reglerna som styr användningen av dessa åtgärder.

Tillförlitlighet i Service Bus

Det finns flera sätt att hantera problem med meddelanden och entiteter, och det finns riktlinjer som styr lämplig användning av dessa åtgärder. För att förstå riktlinjerna måste du först förstå vad som kan misslyckas i Service Bus. På grund av utformningen av Azure-system tenderar alla dessa problem att vara kortvariga. På hög nivå visas de olika orsakerna till otillgänglighet på följande sätt:

• Begränsning från ett externt system som Service Bus är beroende av. Begränsning sker från interaktioner med lagrings- och beräkningsresurser.
• Problem för ett system som Service Bus är beroende av. En viss del av lagringen kan till exempel stöta på problem.
• Fel på Service Bus i ett enda undersystem. I det här fallet kan en beräkningsnod hamna i ett inkonsekvent tillstånd och måste starta om sig själv, vilket gör att alla entiteter som den hanterar belastningsutjämning till andra noder. Detta kan i sin tur orsaka en kort period av långsam meddelandebearbetning.
• Fel vid Service Bus i ett Azure-datacenter. Det här är ett "oåterkalleligt fel" där systemet inte kan nås under många minuter eller några timmar.

Anteckning

Termen lagring kan innebära både Azure Storage och SQL Azure.

Service Bus innehåller ett antal åtgärder för dessa problem. I följande avsnitt beskrivs varje problem och deras respektive åtgärder.

Begränsning

Med Service Bus möjliggör begränsning av kooperativ meddelandefrekvenshantering. Varje enskild Service Bus-nod innehåller många entiteter. Var och en av dessa entiteter ställer krav på systemet när det gäller processor, minne, lagring och andra aspekter. När någon av dessa aspekter identifierar användning som överskrider definierade tröskelvärden kan Service Bus neka en viss begäran. Anroparen tar emot ett undantag som är upptaget på servern och försöker igen efter 10 sekunder.

Som en åtgärd måste koden läsa felet och stoppa eventuella återförsök i meddelandet i minst 10 sekunder. Eftersom felet kan inträffa mellan delar av kundprogrammet förväntas varje del köra logiken för återförsök oberoende av varandra. Koden kan minska sannolikheten för att begränsas genom att aktivera partitionering i ett namnområde, en kö eller ett ämne.

Mer information om hur programkod ska hantera begränsningar finns i dokumentationen om begränsningsmönstret.

Problem med ett Azure-beroende

Andra komponenter i Azure kan ibland ha tjänstproblem. När till exempel ett system som Service Bus använder uppgraderas kan systemet tillfälligt få sämre funktioner. För att kringgå den här typen av problem undersöker och implementerar Service Bus regelbundet åtgärder. Biverkningar av dessa åtgärder visas. För att till exempel hantera tillfälliga problem med lagring implementerar Service Bus ett system som gör att meddelandesändningsåtgärder kan fungera konsekvent. På grund av åtgärdens art kan det ta upp till 15 minuter innan ett skickat meddelande visas i den berörda kön eller prenumerationen och vara redo för en mottagningsåtgärd. Generellt sett upplever de flesta entiteter inte det här problemet. Men med tanke på antalet entiteter i Service Bus i Azure behövs den här åtgärden ibland för en liten delmängd av Service Bus-kunder.

Service Bus-fel i ett enda undersystem

Med alla program kan omständigheterna göra att en intern komponent i Service Bus blir inkonsekvent. När Service Bus identifierar detta samlar det in data från programmet för att diagnostisera vad som hände. När data har samlats in startas programmet om i ett försök att återställa dem till ett konsekvent tillstånd. Den här processen sker ganska snabbt och resulterar i att en entitet verkar vara otillgänglig i upp till några minuter, även om typiska stilleståndstider är mycket kortare.

I dessa fall genererar klientprogrammet ett timeout-undantag eller ett meddelandefel. Service Bus innehåller en åtgärd för det här problemet i form av logik för automatiserade återförsök av klienter. När återförsöksperioden är slut och meddelandet inte levereras kan du utforska med hjälp av andra som nämns i artikeln om hantering av avbrott och katastrofer.

Nästa steg

Nu när du har lärt dig grunderna för asynkrona meddelanden i Service Bus kan du läsa mer om hur du hanterar avbrott och katastrofer.