Översikt över Reliable Services

  • Artikel

Azure Service Fabric förenklar skrivning och hantering av tillståndslösa och tillståndskänsliga tjänster. I detta avsnitt:

  • Programmeringsmodellen Reliable Services för tillståndslösa och tillståndskänsliga tjänster.
  • De val du måste göra när du skriver en tillförlitlig tjänst.
  • Vissa scenarier och exempel på när du ska använda Reliable Services och hur de skrivs.

Reliable Services är en av de programmeringsmodeller som är tillgängliga i Service Fabric. En annan är programmeringsmodellen Reliable Actor , som tillhandahåller ett virtual actor-programramverk ovanpå Reliable Services-modellen. Mer information om Reliable Actors finns i Introduktion till Service Fabric Reliable Actors.

Service Fabric hanterar livslängden för tjänster, från etablering och distribution via uppgradering och borttagning via Service Fabric-programhantering.

Vad är Reliable Services?

Reliable Services ger dig en enkel, kraftfull programmeringsmodell på toppnivå som hjälper dig att uttrycka vad som är viktigt för ditt program. Med programmeringsmodellen Reliable Services får du:

  • Åtkomst till Service Fabric-API:er. Till skillnad från Service Fabric-tjänster som modelleras som gästkörbara filer kan Reliable Services använda Service Fabric-API:er direkt. På så sätt kan tjänster:
    • Fråga systemet
    • Rapportera hälsa om entiteter i klustret
    • Ta emot meddelanden om konfigurations- och kodändringar
    • Hitta och kommunicera med andra tjänster,
    • Använda Reliable Collections
    • Få tillgång till många andra funktioner, allt från en förstklassig programmeringsmodell på flera programmeringsspråk.
  • En enkel modell för att köra din egen kod som känns som andra välbekanta programmeringsmodeller. Koden har en väldefinierad startpunkt och en lätthanterad livscykel.
  • En anslutningsbar kommunikationsmodell. Använd valfri transport, till exempel HTTP med webb-API, WebSockets, anpassade TCP-protokoll eller något annat. Reliable Services erbjuder några bra färdiga alternativ som du kan använda, eller så kan du tillhandahålla dina egna.
  • För tillståndskänsliga tjänster kan du med programmeringsmodellen Reliable Services konsekvent och tillförlitligt lagra ditt tillstånd direkt i tjänsten med hjälp av Reliable Collections. Reliable Collections är en enkel uppsättning högtillgängliga och tillförlitliga samlingsklasser som är bekanta för alla som har använt C#-samlingar. Traditionellt behövde tjänster externa system för tillförlitlig tillståndshantering. Med Reliable Collections kan du lagra ditt tillstånd bredvid din beräkning med samma höga tillgänglighet och tillförlitlighet som du har kommit att förvänta dig från externa butiker med hög tillgänglighet. Den här modellen förbättrar också svarstiden eftersom du samlokaliserar den beräkning och det tillstånd den behöver för att fungera.

Vad gör Reliable Services annorlunda

Reliable Services skiljer sig från tjänster som du kanske har skrivit tidigare, eftersom Service Fabric tillhandahåller:

  • Tillförlitlighet – Tjänsten fortsätter att fungera även i otillförlitliga miljöer där dina datorer misslyckas eller drabbas av nätverksproblem, eller i fall där själva tjänsterna stöter på fel och kraschar eller misslyckas. För tillståndskänsliga tjänster bevaras ditt tillstånd även i närvaro av nätverk eller andra fel.
  • Tillgänglighet – Tjänsten kan nås och svarar. Service Fabric behåller önskat antal kopior som körs.
  • Skalbarhet – Tjänsterna är frikopplade från specifik maskinvara och de kan växa eller krympa efter behov genom tillägg eller borttagning av maskinvara eller andra resurser. Tjänsterna partitioneras enkelt (särskilt i tillståndskänsligt fall) för att säkerställa att tjänsten kan skala och hantera partiella fel. Tjänster kan skapas och tas bort dynamiskt via kod, vilket gör att fler instanser kan snurras upp efter behov, till exempel som svar på kundförfrågningar. Slutligen uppmuntrar Service Fabric tjänster att vara enkla. Med Service Fabric kan tusentals tjänster etableras i en enda process, i stället för att kräva eller dedikera hela OS-instanser eller processer till en enda instans av en tjänst.
  • Konsekvens – All information som lagras i en tillförlitlig tjänst kan garanteras vara konsekvent. Detta gäller även för flera Reliable Collections i en tjänst. Ändringar i samlingar i en tjänst kan göras på ett transaktionsmässigt atomiskt sätt.

På den här sidan finns en träningsvideo för att lära dig mer om programmeringsmodellen för tillförlitliga Service Fabric-tjänster och hur ditt program med den här .NET-programmeringsmodellen kan integreras närmare med Service Fabric-körningen:

Tjänstlivscykel

Oavsett om din tjänst är tillståndskänslig eller tillståndslös tillhandahåller Reliable Services en enkel livscykel som gör att du snabbt kan ansluta koden och komma igång. För att få igång en ny tjänst måste du implementera två metoder:

  • CreateServiceReplicaListeners/CreateServiceInstanceListeners – Den här metoden är den metod där tjänsten definierar de kommunikationsstackar som den vill använda. Kommunikationsstacken, till exempel webb-API, är det som definierar den lyssnande slutpunkten eller slutpunkterna för tjänsten (hur klienter når tjänsten). Den definierar också hur meddelanden som visas interagerar med resten av tjänstkoden.
  • RunAsync – Den här metoden är den metod där tjänsten kör sin affärslogik och där den startar alla bakgrundsuppgifter som ska köras under tjänstens livslängd. Den annulleringstoken som tillhandahålls är en signal för när arbetet ska stoppas. Om tjänsten till exempel behöver hämta meddelanden från en tillförlitlig kö och bearbeta dem är det här som arbetet sker.

Om du lär dig mer om tillförlitliga tjänster för första gången kan du läsa vidare! Om du letar efter en detaljerad genomgång av livscykeln för tillförlitliga tjänster kan du läsa livscykelöversikten för Reliable Services.

Exempeltjänster

Nu ska vi titta närmare på hur Reliable Services-modellen fungerar med både tillståndslösa och tillståndskänsliga tjänster.

Tillståndslösa Reliable Services

En tillståndslös tjänst är en tjänst där det inte finns något tillstånd som underhålls inom tjänsten över anrop. Alla tillstånd som finns är helt disponibla och kräver inte synkronisering, replikering, beständighet eller hög tillgänglighet.

Tänk dig till exempel en kalkylator som inte har något minne och som tar emot alla villkor och åtgärder som ska utföras samtidigt.

I det här fallet RunAsync() kan tjänstens (C#) eller runAsync() (Java) vara tom, eftersom det inte finns någon uppgiftsbearbetning i bakgrunden som tjänsten behöver utföra. När kalkylatortjänsten skapas returneras en ICommunicationListener (C#) eller CommunicationListener (Java) (till exempel webb-API) som öppnar en lyssningsslutpunkt på någon port. Den här lyssningsslutpunkten ansluter till de olika beräkningsmetoderna (exempel: "Add(n1, n2)") som definierar kalkylatorns offentliga API.

När ett anrop görs från en klient anropas lämplig metod och kalkylatortjänsten utför åtgärderna på de data som tillhandahålls och returnerar resultatet. Den lagrar inget tillstånd.

Om du inte lagrar något internt tillstånd blir den här exempelkalkylatorn enkel. Men de flesta tjänster är inte riktigt tillståndslösa. I stället externaliserar de sitt tillstånd till något annat arkiv. (Till exempel är alla webbappar som förlitar sig på att behålla sessionstillståndet i en lagringsplats eller cache inte tillståndslösa.)

Ett vanligt exempel på hur tillståndslösa tjänster används i Service Fabric är som en klientdel som exponerar det offentliga API:et för ett webbprogram. Klientdelstjänsten pratar sedan med tillståndskänsliga tjänster för att slutföra en användarbegäran. I det här fallet dirigeras anrop från klienter till en känd port, till exempel 80, där den tillståndslösa tjänsten lyssnar. Den här tillståndslösa tjänsten tar emot anropet och avgör om anropet kommer från en betrodd part och vilken tjänst det är avsett för. Sedan vidarebefordrar den tillståndslösa tjänsten anropet till rätt partition för den tillståndskänsliga tjänsten och väntar på ett svar. När den tillståndslösa tjänsten tar emot ett svar svarar den på den ursprungliga klienten. Ett exempel på en sådan tjänst är Service Fabric-Komma igång exempel (C# / Java), bland andra Service Fabric-exempel på lagringsplatsen.

Tillståndskänsliga reliable services

En tillståndskänslig tjänst är en tjänst som måste ha en viss del av tillståndet konsekvent och närvarande för att tjänsten ska fungera. Överväg en tjänst som ständigt beräknar ett löpande medelvärde av ett visst värde baserat på uppdateringar som den tar emot. För att göra detta måste den ha den aktuella uppsättningen inkommande begäranden som den behöver bearbeta och det aktuella genomsnittet. Alla tjänster som hämtar, bearbetar och lagrar information i ett externt arkiv (till exempel en Azure-blob eller tabelllagring i dag) är tillståndskänsliga. Den behåller bara sitt tillstånd i det externa tillståndsarkivet.

De flesta tjänster lagrar idag sitt tillstånd externt, eftersom det externa arkivet är det som ger tillförlitlighet, tillgänglighet, skalbarhet och konsekvens för det tillståndet. I Service Fabric krävs inte tjänster för att lagra deras tillstånd externt. Service Fabric tar hand om dessa krav för både tjänstkoden och tjänsttillståndet.

Anta att vi vill skriva en tjänst som bearbetar bilder. För att göra detta tar tjänsten in en avbildning och en serie konverteringar som ska utföras på avbildningen. Den här tjänsten returnerar en kommunikationslyssnare (anta att det är en WebAPI) som exponerar ett API som ConvertImage(Image i, IList<Conversion> conversions). När den tar emot en begäran lagrar tjänsten den i ett IReliableQueueoch returnerar ett ID till klienten så att den kan spåra begäran.

I den här tjänsten RunAsync() kan det vara mer komplext. Tjänsten har en loop inuti den RunAsync() som hämtar begäranden från IReliableQueue och utför de begärda konverteringarna. Resultaten lagras i en IReliableDictionary så att när klienten kommer tillbaka kan de få sina konverterade bilder. För att säkerställa att även om något misslyckas så försvinner inte avbildningen, drar den här Reliable Service ut ur kön, utför konverteringarna och lagrar resultatet i en enda transaktion. I det här fallet tas meddelandet bort från kön och resultatet lagras bara i resultatordlistan när konverteringarna är slutförda. Alternativt kan tjänsten hämta avbildningen från kön och omedelbart lagra den i ett fjärrarkiv. Detta minskar mängden tillstånd som tjänsten måste hantera, men ökar komplexiteten eftersom tjänsten måste behålla nödvändiga metadata för att hantera fjärrlagringen. Med endera metoden finns begäran kvar i kön och väntar på att bearbetas om något misslyckades i mitten.

Även om den här tjänsten låter som en typisk .NET-tjänst är skillnaden att de datastrukturer som används (IReliableQueue och IReliableDictionary) tillhandahålls av Service Fabric och är mycket tillförlitliga, tillgängliga och konsekventa.

När du ska använda Reliable Services-API:er

Överväg RELIABLE Services-API:er om:

  • Du vill att tjänstens kod (och eventuellt tillstånd) ska ha hög tillgänglighet och vara tillförlitlig.
  • Du behöver transaktionsgarantier över flera tillståndsenheter (till exempel order och orderradsartiklar).
  • Programmets tillstånd kan modelleras naturligt som Tillförlitliga ordlistor och köer.
  • Programkoden eller tillståndet måste ha hög tillgänglighet med läs- och skrivåtgärder med låg latens.
  • Ditt program måste kontrollera samtidigheten eller kornigheten för transacted-åtgärder i en eller flera Tillförlitliga samlingar.
  • Du vill hantera kommunikationen eller styra partitioneringsschemat för din tjänst.
  • Koden behöver en fritrådad körningsmiljö.
  • Ditt program måste dynamiskt skapa eller förstöra Tillförlitliga ordlistor eller köer eller hela tjänster vid körning.
  • Du måste programmatiskt kontrollera säkerhetskopierings- och återställningsfunktionerna i Service Fabric för tjänstens tillstånd.
  • Programmet måste behålla ändringshistoriken för sina tillståndsenheter.
  • Du vill utveckla eller använda tredjepartsutvecklade anpassade tillståndsproviders.

Nästa steg