Översikt över Reliable Services-livscykel
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:
- Tjänsten är konstruerad.
StatelessService.CreateServiceInstanceListeners()
anropas och alla returnerade lyssnare öppnas.ICommunicationListener.OpenAsync()
anropas på varje lyssnare.- 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.
- Tjänstens metod anropas
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:
- Alla öppna lyssnare är stängda.
ICommunicationListener.CloseAsync()
anropas på varje lyssnare. - Den annulleringstoken som skickas till
RunAsync()
avbryts. En kontroll av annulleringstokensIsCancellationRequested
egenskap returnerar true, och om den anropas genererar tokenmetodenThrowIfCancellationRequested
enOperationCanceledException
. Service Fabric väntar på att slutförasRunAsync()
. - När
RunAsync()
det är klart anropas tjänstensStatelessService.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ättaStatelessService.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. - 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:
Tjänsten är konstruerad.
StatefulServiceBase.OnOpenAsync()
anropas. Det här anropet åsidosättas vanligtvis inte i tjänsten.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.
- Om tjänsten är en primär tjänst öppnas alla returnerade lyssnare.
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.- Om tjänsten för närvarande är en primär anropas tjänstens
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:
Alla öppna lyssnare är stängda.
ICommunicationListener.CloseAsync()
anropas på varje lyssnare.StatefulServiceBase.OnCloseAsync()
-metoden anropas. Det här anropet är en ovanlig åsidosättning, men är tillgänglig.Den annulleringstoken som skickas till
RunAsync()
avbryts. En kontroll av annulleringstokensIsCancellationRequested
egenskap returnerar true, och om den anropas genererar tokenmetodenThrowIfCancellationRequested
enOperationCanceledException
. Service Fabric väntar på att slutförasRunAsync()
.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.
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:
- Alla öppna lyssnare är stängda.
ICommunicationListener.CloseAsync()
anropas på varje lyssnare. - Den annulleringstoken som skickas till
RunAsync()
avbryts. En kontroll av annulleringstokensIsCancellationRequested
egenskap returnerar true, och om den anropas genererar tokenmetodenThrowIfCancellationRequested
enOperationCanceledException
. Service Fabric väntar på att slutförasRunAsync()
. - Lyssnare som markerats som ListenOnSecondary = true öppnas.
- 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:
ICommunicationListener.CloseAsync()
anropas för alla öppnade lyssnare (markerade med ListenOnSecondary = true).- Alla kommunikationslyssnare öppnas.
ICommunicationListener.OpenAsync()
anropas på varje lyssnare. - Sedan parallellt:
- Tjänstens metod anropas
StatefulServiceBase.RunAsync()
. StatefulServiceBase.OnChangeRoleAsync()
anropas. Det här anropet åsidosättas vanligtvis inte i tjänsten.
- Tjänstens metod anropas
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 anropenCreateServiceReplicaListeners/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 implementeraRunAsync()
. 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 implementeraRunAsync()
.- 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örandeRunAsync()
anger att tjänstens bakgrundsarbete har slutförts. För tillståndskänsliga tillförlitliga tjänsterRunAsync()
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 tillOnAbort()
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
Feedback
https://aka.ms/ContentUserFeedback.
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i:Skicka och visa feedback för