Dela via

Reliable Services-livscykel

  • Artikel

Reliable Services är en av de programmeringsmodeller som är tillgängliga i Azure Service Fabric. När du lär dig mer om livscykeln för Reliable Services är det viktigast att förstå de grundläggande livscykelhändelserna. Den exakta ordningen på händelser beror på konfigurationsinformationen.

I allmänhet innehåller Reliable Services-livscykeln följande händelser:

  • Under starten:
    • Tjänster konstrueras.
    • Tjänster har möjlighet att skapa och returnera noll eller flera lyssnare.
    • Alla returnerade lyssnare öppnas för kommunikation med tjänsten.
    • Tjänstens -metod anropas runAsync så att tjänsten kan utföra tidskrävande arbete eller bakgrundsarbete.
  • Under avstängning:
    • Den annulleringstoken som skickades till runAsync avbryts och lyssnarna stängs.
    • Själva tjänstobjektet har destruerats.

Händelseordningen i Reliable Services kan ändras något beroende på om den tillförlitliga tjänsten är tillståndslös eller tillståndskänslig.

För tillståndskänsliga tjänster måste du även hantera det primära växlingsscenariot. Under den här sekvensen överförs rollen som primär till en annan replik (eller kommer tillbaka) utan att tjänsten stängs av.

Slutligen måste du tänka på fel- eller feltillstånd.

Tillståndslös tjänststart

Livscykeln för en tillståndslös tjänst är ganska enkel. Här är händelseordningen:

  1. Tjänsten är konstruerad.
  2. StatelessService.createServiceInstanceListeners() anropas och alla returnerade lyssnare öppnas. CommunicationListener.openAsync() anropas på varje lyssnare.
  3. Sedan parallellt:
    • Tjänstens -metod (StatelessService.runAsync()) anropasrunAsync.
    • Om det finns anropas tjänstens egen onOpenAsync metod. StatelessService.onOpenAsync() Mer specifikt anropas. Detta är en ovanlig åsidosättning, men den är tillgänglig.

Tillståndslös tjänstavstängning

När du stänger av en tillståndslös tjänst följs samma mönster, men i omvänd ordning:

  1. Alla öppna lyssnare är stängda. CommunicationListener.closeAsync() anropas på varje lyssnare.
  2. Den annulleringstoken som skickades till runAsync() avbryts. Om du kontrollerar egenskapen för annulleringstoken returneras isCancelledtrue, och om den anropas genererar tokens throwIfCancellationRequested -metod en CancellationException.
  3. När runAsync() är klar anropas tjänstens StatelessService.onCloseAsync() -metod, om den finns. Återigen är detta inte en vanlig åsidosättning, men det kan användas för att stänga resurser på ett säkert sätt, stoppa bakgrundsbearbetningen, slutföra besparingen av externt tillstånd eller stänga av befintliga anslutningar.
  4. När StatelessService.onCloseAsync() det är klart destrueras tjänstobjektet.

Tillståndskänslig tjänststart

Tillståndskänsliga tjänster har ett mönster som liknar tillståndslösa tjänster, med några ändringar. Här är händelseordningen för att starta en tillståndskänslig tjänst:

  1. Tjänsten är konstruerad.
  2. StatefulServiceBase.onOpenAsync() anropas. Det här anropet åsidosättas vanligtvis inte i tjänsten.
  3. StatefulServiceBase.createServiceReplicaListeners() anropas.
    • Om tjänsten är en primär tjänst öppnas alla returnerade lyssnare. CommunicationListener.openAsync() anropas på varje lyssnare.
    • Om tjänsten är en sekundär tjänst öppnas endast lyssnare som har markerats som listenOnSecondary = true . Det är mindre vanligt att ha lyssnare som är öppna på sekundärfiler.
  4. Sedan parallellt:
    • Om tjänsten för närvarande är primär anropas tjänstens StatefulServiceBase.runAsync() -metod.
    • StatefulServiceBase.onChangeRoleAsync() anropas. Det här anropet åsidosättas vanligtvis inte i tjänsten.

Anteckning

För en ny sekundär replik StatefulServiceBase.onChangeRoleAsync() anropas två gånger. En gång efter steg 2, när den blir en inaktiv sekundär och igen under steg 4, när den blir en aktiv sekundär. Mer information om replik- och instanslivscykeln finns i Replik- och instanslivscykel.

Tillståndskänslig tjänstavstängning

Precis som tillståndslösa tjänster är livscykelhändelserna under avstängningen desamma som under starten, men omvända. När en tillståndskänslig tjänst stängs av inträffar följande händelser:

  1. Alla öppna lyssnare är stängda. CommunicationListener.closeAsync() anropas på varje lyssnare.
  2. Den annulleringstoken som skickades till runAsync() avbryts. Ett anrop till annulleringstokens isCancelled() -metod returnerar true, och om den anropas genererar tokens throwIfCancellationRequested() -metod en OperationCanceledException. Service Fabric väntar på att slutföras runAsync() .

Anteckning

runAsync Väntar på att slutföras är endast nödvändigt om den här repliken är en primär replik.

  1. När runAsync() det är klart anropas tjänstens StatefulServiceBase.onCloseAsync() -metod. Det här anropet är en ovanlig åsidosättning, men det är tillgängligt.
  2. När StatefulServiceBase.onCloseAsync() det är klart destrueras tjänstobjektet.

Tillståndskänsliga primära tjänstswappar

När en tillståndskänslig tjänst körs öppnas kommunikationslyssnare runAsync och metoden anropas endast för de primära replikerna av de tillståndskänsliga tjänsterna. Sekundära repliker skapas, men inga ytterligare anrop visas. När en tillståndskänslig tjänst körs kan repliken som för närvarande är den primära ändras. Livscykelhändelserna som en tillståndskänslig replik kan se beror på om det är repliken som degraderas eller befordras under växlingen.

För degraderad primär

Service Fabric behöver den primära repliken som degraderats för att sluta bearbeta meddelanden och stoppa bakgrundsarbete. Det här steget liknar när tjänsten stängs av. En skillnad är att tjänsten inte har destruerats eller stängts eftersom den förblir sekundär. Följande sker:

  1. Alla öppna lyssnare är stängda. CommunicationListener.closeAsync() anropas på varje lyssnare.
  2. Den annulleringstoken som skickades till runAsync() avbryts. En kontroll av annulleringstokens isCancelled() -metod returnerar true. Om den anropas genererar tokens throwIfCancellationRequested() -metod en OperationCanceledException. Service Fabric väntar på att slutföras runAsync() .
  3. Lyssnare som markerats som listenOnSecondary = true öppnas.
  4. Tjänstens anropas StatefulServiceBase.onChangeRoleAsync() . Det här anropet åsidosättas vanligtvis inte i tjänsten.

För den upphöjda sekundära

På samma sätt behöver Service Fabric den sekundära repliken som befordras för att börja lyssna efter meddelanden på kabeln och starta eventuella bakgrundsaktiviteter som den behöver slutföra. Den här processen liknar när tjänsten skapas. Skillnaden är att själva repliken redan finns. Följande sker:

  1. CommunicationListener.closeAsync() anropas för alla öppnade lyssnare (markerade med listenOnSecondary = true)
  2. Alla kommunikationslyssnare öppnas. CommunicationListener.openAsync() anropas på varje lyssnare.
  3. Sedan parallellt:
    • Tjänstens metod anropas StatefulServiceBase.runAsync() .
    • StatefulServiceBase.onChangeRoleAsync() anropas. Det här anropet åsidosättas vanligtvis inte i tjänsten.

Anteckning

createServiceReplicaListeners anropas bara en gång och anropas inte igen under replikhöjningen eller degraderingsprocessen. samma ServiceReplicaListener instanser används men nya CommunicationListener instanser skapas (genom att anropa ServiceReplicaListener.createCommunicationListener metoden) när de tidigare instanserna har stängts.

Vanliga problem vid tillståndskänslig tjänstavstängning och primär degradering

Service Fabric ändrar primärt för en tillståndskänslig tjänst av flera skäl. De vanligaste orsakerna är ombalansering av kluster och programuppgradering. Under dessa åtgärder är det viktigt att tjänsten respekterar cancellationToken. Detta gäller även vid normal tjänstavstängning, till exempel om tjänsten togs bort.

Det kan uppstå flera problem med tjänster som inte hanterar avbokningen på ett rent sätt. De här åtgärderna är långsamma eftersom Service Fabric väntar på att tjänsterna ska stoppas på ett smidigt sätt. Detta kan i slutändan leda till misslyckade uppgraderingar som överskrider tidsgränsen och återställningen. Om annulleringstoken inte respekteras kan det också orsaka obalanserade kluster. Kluster blir obalanserade eftersom noderna blir heta. Tjänsterna kan dock inte balanseras om eftersom det tar för lång tid att flytta dem någon annanstans.

Eftersom tjänsterna är tillståndskänsliga är det också troligt att tjänsterna använder Reliable Collections. När en primär användare degraderas i Service Fabric är en av de första sakerna som händer att skrivåtkomsten till det underliggande tillståndet återkallas. Detta leder till en andra uppsättning problem som kan påverka tjänstens livscykel. Samlingarna returnerar undantag baserat på tidpunkten och om repliken flyttas eller stängs av. Det är viktigt att hantera dessa undantag korrekt.

Undantag som genereras av Service Fabric är antingen permanenta (FabricException) eller tillfälliga (FabricTransientException). Permanenta undantag ska loggas och genereras. Tillfälliga undantag kan göras om baserat på logik för återförsök.

En viktig del av testning och validering av Reliable Services är att hantera de undantag som kommer från att använda ReliableCollections tillsammans med händelser i tjänstens livscykel. Vi rekommenderar att du alltid kör tjänsten under belastning. Du bör också utföra uppgraderingar och kaostestning innan du distribuerar till produktion. De här grundläggande stegen hjälper dig att säkerställa att tjänsten implementeras korrekt och att den hanterar livscykelhändelser korrekt.

Anteckningar om tjänstens livscykel

  • runAsync() Både metoden och anropen createServiceInstanceListeners/createServiceReplicaListeners är valfria. En tjänst kan ha en, båda eller ingen av dem. Om tjänsten till exempel utför allt sitt arbete som svar på användaranrop behöver den inte implementera runAsync(). Endast kommunikationslyssnare och tillhörande kod är nödvändiga. På samma sätt är det valfritt att skapa och returnera kommunikationslyssnare. Tjänsten kanske bara har bakgrundsarbete att göra, så den behöver bara implementera runAsync().
  • Det är giltigt för en tjänst att slutföras runAsync() och returneras från den. Detta anses inte vara ett feltillstånd. Den representerar bakgrundsarbetet för tjänstens slutförande. För tillståndskänsliga Reliable Services runAsync() anropas du igen om tjänsten degraderas från primär och sedan befordras tillbaka till primär.
  • Om en tjänst avslutas runAsync() genom att utlösa ett oväntat undantag är detta ett fel. Tjänstobjektet stängs av och ett hälsofel rapporteras.
  • Även om det inte finns någon tidsgräns för att komma tillbaka från dessa metoder förlorar du omedelbart möjligheten att skriva. Därför kan du inte slutföra något verkligt arbete. Vi rekommenderar att du återvänder så snabbt som möjligt när du tar emot avbokningsbegäran. Om din tjänst inte svarar på dessa API-anrop inom rimlig tid kan Service Fabric med två skäl avsluta tjänsten. Detta sker vanligtvis bara under programuppgraderingar eller när en tjänst tas bort. Den här tidsgränsen är som standard 15 minuter.
  • Fel i onCloseAsync() sökvägen leder till onAbort() att anropas. Det här anropet är en sista chans, bästa möjliga möjlighet för tjänsten att rensa och frigöra alla resurser som de har begärt. Detta kallas vanligtvis när ett permanent fel identifieras på noden, eller när Service Fabric inte på ett tillförlitligt sätt kan hantera tjänstinstansens livscykel på grund av interna fel.
  • OnChangeRoleAsync() anropas när den tillståndskänsliga tjänstrepliken ändrar roll, till exempel till primär eller sekundär. Primära repliker får skrivstatus (tillåts skapa och skriva till Reliable Collections). Sekundära repliker får lässtatus (kan bara läsa från befintliga Reliable Collections). De flesta arbeten i en tillståndskänslig tjänst utförs på den primära repliken. Sekundära repliker kan utföra skrivskyddad validering, rapportgenerering, datautvinning eller andra skrivskyddade jobb.

Nästa steg