Översikt över Reliable Services-livscykel

  • Artikel

När du tänker på livscykeln för Azure Service Fabric Reliable Services är grunderna i livscykeln de viktigaste. I allmänhet innehåller livscykeln följande:

  • Under start:
    • Tjänster skapas.
    • Tjänsterna har möjlighet att skapa och returnera noll eller fler lyssnare.
    • Alla returnerade lyssnare öppnas, vilket tillåter kommunikation med tjänsten.
    • Tjänstens RunAsync-metod anropas, vilket gör att tjänsten kan utföra långvariga uppgifter eller bakgrundsarbete.
  • Under avstängning:
    • Annulleringstoken som skickas till RunAsync avbryts och lyssnarna stängs.
    • När lyssnarna har stängts förstörs själva tjänstobjektet.

Det finns information om den exakta ordningen för dessa händelser. Händelseordningen kan ändras något beroende på om Reliable Service är tillståndslös eller tillståndskänslig. För tillståndskänsliga tjänster måste vi dessutom hantera scenariot för primär växling. Under den här sekvensen överförs rollen Primär till en annan replik (eller kommer tillbaka) utan att tjänsten stängs av. Slutligen måste vi tänka på fel- eller feltillstånd.

Tillståndslös tjänststart

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

  1. Tjänsten är konstruerad.
  2. StatelessService.CreateServiceInstanceListeners() anropas och alla returnerade lyssnare öppnas. ICommunicationListener.OpenAsync() anropas på varje lyssnare.
  3. Parallellt händer två saker-
    • Tjänstens metod anropas StatelessService.RunAsync() .
    • Om det finns anropas tjänstens StatelessService.OnOpenAsync() -metod. Det här anropet är en ovanlig åsidosättning, men det är tillgängligt. Utökade initieringsuppgifter för tjänsten kan startas just nu.

Tillståndslös tjänstavstängning

För att stänga av en tillståndslös tjänst följs samma mönster, i omvänd ordning:

  1. Alla öppna lyssnare är stängda. ICommunicationListener.CloseAsync() anropas på varje lyssnare.
  2. Den annulleringstoken som skickas till RunAsync() avbryts. En kontroll av annulleringstokens IsCancellationRequested egenskap returnerar true, och om den anropas genererar tokenmetoden ThrowIfCancellationRequested en OperationCanceledException. Service Fabric väntar på att slutföras RunAsync() .
  3. När RunAsync() det är klart anropas tjänstens StatelessService.OnCloseAsync() -metod, om den finns. OnCloseAsync anropas när den tillståndslösa tjänstinstansen kommer att stängas av på ett smidigt sätt. Detta kan inträffa när tjänstens kod uppgraderas, tjänstinstansen flyttas på grund av belastningsutjämning eller ett tillfälligt fel identifieras. Det är ovanligt att åsidosätta StatelessService.OnCloseAsync(), men det kan användas för att på ett säkert sätt stänga resurser, stoppa bakgrundsbearbetningen, slutföra besparingen av externt tillstånd eller stänga 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 liknande mönster som tillståndslösa tjänster, med några ändringar. För att starta en tillståndskänslig tjänst är händelseordningen följande:

  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. ICommunicationListener.OpenAsync() anropas på varje lyssnare.
    • Om tjänsten är en sekundär tjänst är det bara de lyssnare som har markerats som ListenOnSecondary = true öppna. Det är mindre vanligt att ha lyssnare som är öppna på sekundärfiler.

  4. Sedan parallellt:

    • Om tjänsten för närvarande är en 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 det blir en inaktiv sekundär och igen under steg 4, när det 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 vid start, 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. ICommunicationListener.CloseAsync() anropas på varje lyssnare.

  2. StatefulServiceBase.OnCloseAsync() -metoden anropas. Det här anropet är en ovanlig åsidosättning, men är tillgänglig.

  3. Den annulleringstoken som skickas till RunAsync() avbryts. En kontroll av annulleringstokens IsCancellationRequested egenskap returnerar true, och om den anropas genererar tokenmetoden ThrowIfCancellationRequested en OperationCanceledException. Service Fabric väntar på att slutföras RunAsync() .

    Anteckning

    Det är bara nödvändigt att vänta tills RunAsync har slutförts om den här repliken är en primär replik.

  4. När StatefulServiceBase.RunAsync() det är klart destrueras tjänstobjektet.

Tillståndskänsliga primära växlingar för tjänsten

Medan en tillståndskänslig tjänst körs är det bara de primära replikerna av de tillståndskänsliga tjänsterna som har sina kommunikationslyssnare öppna och runasync-metoden anropad. Sekundära repliker konstrueras, 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 på grund av fel- eller klusterbalanseringsoptimering. Vad innebär detta när det gäller livscykelhändelser som en replik kan se? Beteendet som den tillståndskänsliga repliken ser beror på om det är repliken som degraderas eller höjs upp under växlingen.

För den primära som degraderats

För den primära repliken som degraderas behöver Service Fabric den här repliken för att sluta bearbeta meddelanden och avsluta allt bakgrundsarbete som den utför. Därför ser det här steget ut som när tjänsten stängs av. En skillnad är att tjänsten inte förstörs eller stängs eftersom den förblir sekundär. Följande API:er anropas:

  1. Alla öppna lyssnare är stängda. ICommunicationListener.CloseAsync() anropas på varje lyssnare.
  2. Den annulleringstoken som skickas till RunAsync() avbryts. En kontroll av annulleringstokens IsCancellationRequested egenskap returnerar true, och om den anropas genererar tokenmetoden ThrowIfCancellationRequested 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 sekundära som har befordrats

På samma sätt behöver Service Fabric den sekundära replik som befordras för att börja lyssna efter meddelanden i tråden och starta eventuella bakgrundsuppgifter som den behöver utföra. Därför ser den här processen ut som den gjorde när tjänsten skapades, förutom att själva repliken redan finns. Följande API:er anropas:

  1. ICommunicationListener.CloseAsync() anropas för alla öppnade lyssnare (markerade med ListenOnSecondary = true).
  2. Alla kommunikationslyssnare öppnas. ICommunicationListener.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 ICommunicationListener 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 den primära för en tillståndskänslig tjänst av flera olika skäl. De vanligaste är ombalansering av kluster och programuppgradering. Under dessa åtgärder (liksom under normal tjänstavstängning, som du skulle se om tjänsten togs bort), är det viktigt att tjänsten respekterar CancellationToken.

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älls. Om annulleringstoken inte respekteras kan det också orsaka obalanserade kluster. Kluster blir obalanserade eftersom noderna blir heta, men tjänsterna kan 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 de använder Reliable Collections. När en primär 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. Dessa undantag bör hanteras korrekt. Undantag som genereras av Service Fabric hamnar i permanenta (FabricException) och tillfälliga (FabricTransientException) kategorier. Permanenta undantag ska loggas och utlösas medan de tillfälliga undantagen kan göras om baserat på viss logik för återförsök.

Att hantera de undantag som kommer från användning av tillsammans med händelser i tjänstens livscykel är en viktig del av testning och validering av ReliableCollections en tillförlitlig tjänst. Vi rekommenderar att du alltid kör tjänsten under belastning när du utför uppgraderingar och kaostestning innan du distribuerar till produktion. De här grundläggande stegen hjälper till att säkerställa att tjänsten implementeras korrekt och hanterar livscykelhändelser korrekt.

Anteckningar om tjänstens livscykel

  • RunAsync() Både metoden och anropen CreateServiceReplicaListeners/CreateServiceInstanceListeners är valfria. En tjänst kan ha en av dem, 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, eftersom tjänsten bara kan ha bakgrundsarbete att göra och därför bara behöver implementera RunAsync().
  • Det är giltigt för en tjänst att slutföras RunAsync() och returneras från den. Slutförandet är inte ett feltillstånd. Slutförande RunAsync() anger att tjänstens bakgrundsarbete har slutförts. För tillståndskänsliga tillförlitliga tjänster RunAsync() anropas den igen om repliken degraderas från primär till sekundär och sedan befordras tillbaka till Primär.
  • Om en tjänst avslutas RunAsync() genom att utlösa ett oväntat undantag utgö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 returnera från dessa metoder förlorar du omedelbart möjligheten att skriva till Reliable Collections och kan därför inte slutföra något verkligt arbete. Vi rekommenderar att du återvänder så snabbt som möjligt när du tar emot annulleringsbegäran. Om din tjänst inte svarar på dessa API-anrop inom rimlig tid kan Service Fabric med två tvådrevs avsluta din tjänst. 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, vilket är en bästa 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