Dela via

Vill du lära dig mer om Service Fabric?

  • Artikel

Azure Service Fabric är en distribuerad systemplattform som gör det enkelt att paketera, distribuera och hantera skalbara och tillförlitliga mikrotjänster. Service Fabric har dock en stor yta och det finns mycket att lära. Den här artikeln innehåller en sammanfattning av Service Fabric och beskriver grundläggande begrepp, programmeringsmodeller, programlivscykel, testning, kluster och hälsoövervakning. Läs Översikt och Vad är mikrotjänster? för en introduktion och hur Service Fabric kan användas för att skapa mikrotjänster. Den här artikeln innehåller ingen omfattande innehållslista, men den länkar till översikts- och komma igång-artiklar för alla områden i Service Fabric.

Huvudkoncept

Service Fabric-terminologi, programmodell och programmeringsmodeller som stöds innehåller fler begrepp och beskrivningar, men här är grunderna.

Designtid: tjänsttyp, tjänstpaket och manifest, programtyp, programpaket och manifest

En tjänsttyp är det namn/den version som tilldelats till en tjänsts kodpaket, datapaket och konfigurationspaket. Detta definieras i en ServiceManifest.xml fil. Tjänsttypen består av inställningar för körbar kod och tjänstkonfiguration, som läses in vid körning och statiska data som används av tjänsten.

Ett tjänstpaket är en diskkatalog som innehåller tjänsttypens ServiceManifest.xml-fil, som refererar till kod, statiska data och konfigurationspaket för tjänsttypen. Ett tjänstpaket kan till exempel referera till kod, statiska data och konfigurationspaket som utgör en databastjänst.

En programtyp är det namn/den version som tilldelats till en samling tjänsttyper. Detta definieras i en ApplicationManifest.xml fil.

Service Fabric-programtyper och tjänsttyper

Programpaketet är en diskkatalog som innehåller programtypens ApplicationManifest.xml fil, som refererar till tjänstpaketen för varje tjänsttyp som utgör programtypen. Ett programpaket för en e-postprogramtyp kan till exempel innehålla referenser till ett kötjänstpaket, ett klientdelstjänstpaket och ett databastjänstpaket.

Filerna i programpaketkatalogen kopieras till Service Fabric-klustrets avbildningsarkiv. Du kan sedan skapa ett namngivet program från den här programtypen, som sedan körs i klustret. När du har skapat ett namngivet program kan du skapa en namngiven tjänst från någon av programtypens tjänsttyper.

Körtid: kluster och noder, namngivna program, namngivna tjänster, partitioner och repliker

Ett Service Fabric-kluster är en nätverksansluten uppsättning virtuella eller fysiska datorer där dina mikrotjänster distribueras och hanteras. Kluster kan skalas upp till tusentals datorer.

En dator eller virtuell dator som ingår i ett kluster kallas för en nod. Varje nod har tilldelats ett nodnamn (en sträng). Noder har egenskaper, till exempel placeringsegenskaper. Varje dator eller virtuell dator har en Windows-tjänst för automatisk start, FabricHost.exe, som börjar köras vid start och sedan startar två körbara filer: Fabric.exe och FabricGateway.exe. Dessa två körbara filer utgör noden. För utvecklings- eller testscenarier kan du vara värd för flera noder på en enda dator eller virtuell dator genom att köra flera instanser av Fabric.exe och FabricGateway.exe.

Ett namngivet program är en samling namngivna tjänster som utför en viss funktion eller funktioner. En tjänst utför en fullständig och fristående funktion (den kan starta och köras oberoende av andra tjänster) och består av kod, konfiguration och data. När ett programpaket har kopierats till avbildningsarkivet skapar du en instans av programmet i klustret genom att ange programpaketets programtyp (med dess namn/version). Varje programtypinstans tilldelas ett URI-namn som ser ut som fabric:/MyNamedApp. I ett kluster kan du skapa flera namngivna program från en enda programtyp. Du kan också skapa namngivna program från olika programtyper. Varje namngivet program hanteras och versionshanteras oberoende av varandra.

När du har skapat ett namngivet program kan du skapa en instans av en av dess tjänsttyper (en namngiven tjänst) i klustret genom att ange tjänsttypen (med dess namn/version). Varje instans av tjänsttyp tilldelas ett URI-namn under dess namngivna programs URI. Om du till exempel skapar en "MyDatabase" med namnet service i ett "MyNamedApp"-program ser URI:n ut så här: fabric:/MyNamedApp/MyDatabase. I ett namngivet program kan du skapa en eller flera namngivna tjänster. Varje namngiven tjänst kan ha ett eget partitionsschema och antal instanser/repliker.

Det finns två typer av tjänster: tillståndslösa och tillståndskänsliga. Tillståndslösa tjänster lagrar inte tillstånd i tjänsten. Tillståndslösa tjänster har ingen beständig lagring alls eller lagrar beständiga tillstånd i en extern lagringstjänst som Azure Storage, Azure SQL Database eller Azure Cosmos DB. En tillståndskänslig tjänst lagrar tillståndet i tjänsten och använder Reliable Collections eller Reliable Actors programmeringsmodeller för att hantera tillstånd.

När du skapar en namngiven tjänst anger du ett partitionsschema. Tjänster med stora mängder tillstånd delar upp data mellan partitioner. Varje partition ansvarar för en del av tjänstens fullständiga tillstånd, som är fördelat på klustrets noder.

Följande diagram visar relationen mellan program och tjänstinstanser, partitioner och repliker.

Partitioner och repliker i en tjänst

Partitionering, skalning och tillgänglighet

Partitionering är inte unikt för Service Fabric. En välkänd form av partitionering är datapartitionering eller horisontell partitionering. Tillståndskänsliga tjänster med stora mängder tillstånd delar upp data mellan partitioner. Varje partition ansvarar för en del av tjänstens fullständiga tillstånd.

Replikerna för varje partition sprids över klustrets noder, vilket gör att den namngivna tjänstens tillstånd kan skalas. När databehoven växer växer partitionerna och Service Fabric balanserar om partitioner mellan noder för att effektivt använda maskinvaruresurser. Om du lägger till nya noder i klustret balanserar Service Fabric om partitionsreplikerna över det ökade antalet noder. Övergripande programprestanda förbättras och konkurrensen om åtkomst till minne minskar. Om noderna i klustret inte används effektivt kan du minska antalet noder i klustret. Service Fabric balanserar återigen om partitionsreplikerna över det minskade antalet noder för att bättre använda maskinvaran på varje nod.

I en partition har tillståndslösa namngivna tjänster instanser medan tillståndskänsliga namngivna tjänster har repliker. Vanligtvis har tillståndslösa namngivna tjänster bara en partition eftersom de inte har något internt tillstånd, även om det finns undantag. Partitionsinstanserna tillhandahåller tillgänglighet. Om en instans misslyckas fortsätter andra instanser att fungera normalt och sedan skapar Service Fabric en ny instans. Tillståndskänsliga namngivna tjänster behåller sitt tillstånd inom repliker och varje partition har en egen replikuppsättning. Läs- och skrivåtgärder utförs på en replik (kallas primär). Ändringar av tillstånd från skrivåtgärder replikeras till flera andra repliker (kallas aktiva sekundärfiler). Om en replik skulle misslyckas skapar Service Fabric en ny replik från de befintliga replikerna.

Tillståndslösa och tillståndskänsliga mikrotjänster för Service Fabric

Med Service Fabric kan du skapa program som består av mikrotjänster eller containrar. Tillståndslösa mikrotjänster (till exempel protokollgatewayar och webbproxyservrar) har inte ett föränderligt tillstånd utanför en begäran och svaret från tjänsten. Arbetsroller i Azure Cloud Services är ett exempel på en tillståndslös tjänst. Tillståndskänsliga mikrotjänster (till exempel användarkonton, databaser, enheter, kundvagnar och köer) har ett föränderligt och auktoritärt tillstånd bortom begäran och svaret. Dagens program med Internetskala består av en kombination av tillståndslösa och tillståndskänsliga mikrotjänster.

En viktig skillnad med Service Fabric är dess starka fokus på att skapa tillståndskänsliga tjänster, antingen med de inbyggda programmeringsmodellerna eller med tillståndskänsliga tjänster i containrar. Programscenarier beskriver scenarier där tillståndskänsliga tjänster används.

Varför har tillståndskänsliga mikrotjänster tillsammans med tillståndslösa? De två huvudsakliga orsakerna är:

  • Du kan skapa OLTP-tjänster (high-throughput, low-latency, failure-tolerant online transaction processing) genom att hålla kod och data nära på samma dator. Några exempel är interaktiva skyltfönster, sökning, IoT-system (Internet of Things), handelssystem, kreditkortsbearbetning och system för identifiering av bedrägerier och hantering av personliga arkivhandlingar.
  • Du kan förenkla programdesignen. Tillståndskänsliga mikrotjänster tar bort behovet av ytterligare köer och cacheminnen, som traditionellt krävs för att hantera tillgänglighets- och svarstidskraven för ett rent tillståndslöst program. Tillståndskänsliga tjänster är naturligt hög tillgänglighet och låg latens, vilket minskar antalet rörliga delar som ska hanteras i ditt program som helhet.

Programmeringsmodeller som stöds

Service Fabric erbjuder flera sätt att skriva och hantera dina tjänster. Tjänster kan använda Service Fabric-API:er för att dra full nytta av plattformens funktioner och programramverk. Tjänster kan också vara alla kompilerade körbara program som skrivs på valfritt språk och finns i ett Service Fabric-kluster. Mer information finns i Programmeringsmodeller som stöds.

Containers

Som standard distribuerar och aktiverar Service Fabric tjänster som processer. Service Fabric kan också distribuera tjänster i containrar. Viktigt är att du kan blanda tjänster i processer och tjänster i containrar i samma program. Service Fabric stöder distribution av Linux-containrar och Windows-containrar på Windows Server 2016. Du kan distribuera befintliga program, tillståndslösa tjänster eller tillståndskänsliga tjänster i containrar.

Reliable Services

Reliable Services är ett enkelt ramverk för att skriva tjänster som integreras med Service Fabric-plattformen och drar nytta av alla plattformsfunktioner. Reliable Services kan vara tillståndslösa (liknar de flesta tjänstplattformar, till exempel webbservrar eller arbetsroller i Azure Cloud Services), där tillståndet sparas i en extern lösning, till exempel Azure DB eller Azure Table Storage. Reliable Services kan också vara tillståndskänsliga, där tillståndet sparas direkt i själva tjänsten med hjälp av Reliable Collections. Tillståndet görs mycket tillgängligt via replikering och distribueras via partitionering, som hanteras automatiskt av Service Fabric.

Reliable Actors

Reliable Actor-ramverket bygger på Reliable Services och är ett programramverk som implementerar mönstret Virtuell aktör baserat på aktörens designmönster. Ramverket Reliable Actor använder oberoende beräkningsenheter och tillstånd med enkeltrådad körning som kallas aktörer. Ramverket Reliable Actor tillhandahåller inbyggd kommunikation för aktörer och förinställda tillståndsbeständighet och utskalningskonfigurationer.

ASP.NET Core

Service Fabric integreras med ASP.NET Core som en förstklassig programmeringsmodell för att skapa webb- och API-program. ASP.NET Core kan användas på två olika sätt i Service Fabric:

  • Värdhanterad som körbar gäst. Detta används främst för att köra befintliga ASP.NET Core program i Service Fabric utan kodändringar.
  • Kör i en Reliable Service. Detta möjliggör bättre integrering med Service Fabric-körningen och tillåter tillståndskänsliga ASP.NET Core tjänster.

Körbara gästfiler

En körbar gäst är en befintlig, godtycklig körbar fil (skriven på alla språk) som finns i ett Service Fabric-kluster tillsammans med andra tjänster. Körbara gästdatorer integreras inte direkt med Service Fabric-API:er. Men de drar fortfarande nytta av funktioner som plattformen erbjuder, till exempel anpassad hälso- och belastningsrapportering och tjänstidentifiering genom att anropa REST-API:er. De har också fullständig support för programmets livscykel.

Programlivscykel

Precis som med andra plattformar går ett program i Service Fabric vanligtvis igenom följande faser: design, utveckling, testning, distribution, uppgradering, underhåll och borttagning. Service Fabric ger förstklassigt stöd för hela programlivscykeln för molnprogram, från utveckling till distribution, daglig hantering och underhåll till eventuell avveckling. Tjänstmodellen gör det möjligt för flera olika roller att delta oberoende av varandra i programmets livscykel. Service Fabric-programmets livscykel ger en översikt över API:erna och hur de används av de olika rollerna under faserna i Service Fabric-programlivscykeln.

Hela appens livscykel kan hanteras med PowerShell-cmdletar, CLI-kommandon, C#-API:er, Java-API:er och REST-API:er. Du kan också konfigurera pipelines för kontinuerlig integrering/kontinuerlig distribution med hjälp av verktyg som Azure Pipelines eller Jenkins.

I den här länken finns en träningsvideo som beskriver hur du hanterar programmets livscykel:

Testa program och tjänster

För att skapa verkligt molnbaserade tjänster är det viktigt att kontrollera att dina program och tjänster klarar verkliga fel. Tjänsten Fault Analysis är utformad för testning av tjänster som bygger på Service Fabric. Med tjänsten Felanalys kan du orsaka meningsfulla fel och köra fullständiga testscenarier mot dina program. Dessa fel och scenarier övar och validerar de många tillstånd och övergångar som en tjänst kommer att uppleva under hela sin livstid, allt på ett kontrollerat, säkert och konsekvent sätt.

Åtgärder riktar in sig på en tjänst för testning med hjälp av enskilda fel. En tjänstutvecklare kan använda dessa som byggstenar för att skriva komplicerade scenarier. Exempel på simulerade fel är:

  • Starta om en nod för att simulera valfritt antal situationer där en dator eller virtuell dator startas om.
  • Flytta en replik av din tillståndskänsliga tjänst för att simulera belastningsutjämning, redundans eller programuppgradering.
  • Anropa kvorumförlust för en tillståndskänslig tjänst för att skapa en situation där skrivåtgärder inte kan fortsätta eftersom det inte finns tillräckligt med "säkerhetskopiering" eller "sekundära" repliker för att acceptera nya data.
  • Anropa dataförlust på en tillståndskänslig tjänst för att skapa en situation där allt minnesinternt tillstånd är helt utplånat.

Scenarier är komplexa åtgärder som består av en eller flera åtgärder. Felanalystjänsten innehåller två inbyggda kompletta scenarier:

  • Kaosscenario – simulerar kontinuerliga, interfolierade fel (både graciösa och ospårbara) i hela klustret under längre tidsperioder.
  • Redundansscenario – en version av scenariot för kaostest som riktar sig mot en specifik tjänstpartition samtidigt som andra tjänster inte påverkas.

Kluster

Ett Service Fabric-kluster är en nätverksansluten uppsättning virtuella eller fysiska datorer där dina mikrotjänster distribueras och hanteras. Kluster kan skalas upp till tusentals datorer. En dator eller virtuell dator som ingår i ett kluster kallas för en klusternod. Varje nod har tilldelats ett nodnamn (en sträng). Noder har egenskaper, till exempel placeringsegenskaper. Varje dator eller virtuell dator har en automatisk starttjänst, FabricHost.exe, som börjar köras vid start och sedan startar två körbara filer: Fabric.exe och FabricGateway.exe. Dessa två körbara filer utgör noden. För testscenarier kan du vara värd för flera noder på en enda dator eller virtuell dator genom att köra flera instanser av Fabric.exe och FabricGateway.exe.

Service Fabric-kluster kan skapas på virtuella eller fysiska datorer som kör Windows Server eller Linux. Du kan distribuera och köra Service Fabric-program i alla miljöer där du har en uppsättning Windows Server- eller Linux-datorer som är sammankopplade: lokalt, i Microsoft Azure eller på valfri molnleverantör.

Se den här länken för en träningsvideo som beskriver Service Fabric-arkitekturen, dess grundläggande begrepp och många andra funktioner i Service Fabric

Kluster i Azure

Genom att köra Service Fabric-kluster i Azure får du integrering med andra Azure-funktioner och -tjänster, vilket gör driften och hanteringen av klustret enklare och mer tillförlitlig. Ett kluster är en Azure-Resource Manager resurs, så du kan modellera kluster som andra resurser i Azure. Resource Manager ger också enkel hantering av alla resurser som används av klustret som en enda enhet. Kluster i Azure är integrerade med Azure-diagnostik och Azure Monitor-loggar. Klusternodtyper är vm-skalningsuppsättningar, så funktionen för automatisk skalning är inbyggd.

Du kan skapa ett kluster i Azure via Azure Portal, från en mall eller från Visual Studio.

Med Service Fabric i Linux kan du skapa, distribuera och hantera högtillgängliga, mycket skalbara program i Linux precis som i Windows. Service Fabric-ramverken (Reliable Services och Reliable Actors) är tillgängliga i Java i Linux, förutom C# (.NET Core). Du kan också skapa körbara gästtjänster med valfritt språk eller ramverk. Orkestrering av Docker-containrar stöds också. Docker-containrar kan köra gästkörbara filer eller interna Service Fabric-tjänster, som använder Service Fabric-ramverken. Mer information finns i Service Fabric på Linux.

Det finns vissa funktioner som stöds i Windows, men inte i Linux. Mer information finns i Skillnader mellan Service Fabric i Linux och Windows.

Fristående kluster

Service Fabric tillhandahåller ett installationspaket som du kan använda för att skapa fristående Service Fabric-kluster lokalt eller på valfri molnleverantör. Fristående kluster ger dig friheten att vara värd för ett kluster var du vill. Om dina data omfattas av efterlevnads- eller regelbegränsningar, eller om du vill hålla dina data lokala, kan du vara värd för ditt eget kluster och program. Service Fabric-program kan köras i flera värdmiljöer utan ändringar, så dina kunskaper om att skapa program överförs från en värdmiljö till en annan.

Skapa ditt första fristående Service Fabric-kluster

Fristående Linux-kluster stöds ännu inte.

Klustersäkerhet

Kluster måste skyddas för att förhindra obehöriga användare från att ansluta till klustret, särskilt när produktionsarbetsbelastningar körs på det. Även om det är möjligt att skapa ett osäkert kluster kan anonyma användare ansluta till det om hanteringsslutpunkter exponeras för det offentliga Internet. Det går inte att senare aktivera säkerhet i ett osäkert kluster: klustersäkerhet aktiveras när klustret skapas.

Klustersäkerhetsscenarierna är:

  • Säkerhet från nod till nod
  • Säkerhet från klient till nod
  • Rollbaserad åtkomstkontroll för Service Fabric

Mer information finns i Skydda ett kluster.

Skalning

Om du lägger till nya noder i klustret balanserar Service Fabric om partitionsreplikerna och instanserna över det ökade antalet noder. Övergripande programprestanda förbättras och konkurrensen om åtkomst till minne minskar. Om noderna i klustret inte används effektivt kan du minska antalet noder i klustret. Service Fabric balanserar återigen om partitionsreplikerna och instanserna över det minskade antalet noder för att bättre använda maskinvaran på varje nod. Du kan skala kluster i Azure manuellt eller programmatiskt. Fristående kluster kan skalas manuellt.

Klusteruppgraderingar

Med jämna mellanrum släpps nya versioner av Service Fabric-körningen. Utför körnings- eller infrastrukturuppgraderingar på klustret så att du alltid kör en version som stöds. Förutom infrastrukturuppgraderingar kan du även uppdatera klusterkonfigurationen, till exempel certifikat eller programportar.

Ett Service Fabric-kluster är en resurs som du äger, men som delvis hanteras av Microsoft. Microsoft ansvarar för att korrigera det underliggande operativsystemet och utföra infrastrukturuppgraderingar på klustret. Du kan ange att klustret ska ta emot automatiska infrastrukturuppgraderingar när Microsoft släpper en ny version eller välja en infrastrukturresursversion som stöds. Infrastrukturresurser och konfigurationsuppgraderingar kan ställas in via Azure Portal eller via Resource Manager. Mer information finns i Uppgradera ett Service Fabric-kluster.

Ett fristående kluster är en resurs som du äger helt och hållet. Du ansvarar för att korrigera det underliggande operativsystemet och initiera infrastrukturuppgraderingar. Om klustret kan ansluta till https://www.microsoft.com/downloadkan du ställa in klustret på att automatiskt ladda ned och etablera det nya Service Fabric-körningspaketet. Sedan initierar du uppgraderingen. Om klustret inte kan komma åt https://www.microsoft.com/downloadkan du manuellt ladda ned det nya körningspaketet från en Internetansluten dator och sedan starta uppgraderingen. Mer information finns i Uppgradera ett fristående Service Fabric-kluster.

Hälsoövervakning

Service Fabric introducerar en hälsomodell som är utformad för att flagga kluster- och programvillkor som inte är felfria för specifika entiteter (till exempel klusternoder och tjänstrepliker). Hälsomodellen använder hälsoreportrar (systemkomponenter och vakthundar). Målet är enkel och snabb diagnos och reparation. Tjänstförfattare måste tänka i förväg om hälsa och hur man utformar hälsorapportering. Alla villkor som kan påverka hälsan ska rapporteras, särskilt om det kan hjälpa till att flagga problem nära roten. Hälsoinformationen kan spara tid och arbete med felsökning och undersökning när tjänsten är igång i stor skala i produktion.

Service Fabric-reportrar övervakar identifierade intressanta villkor. De rapporterar om dessa villkor baserat på deras lokala vy. Hälsolagret aggregerar hälsodata som skickas av alla reportrar för att avgöra om entiteter är globalt felfria. Modellen är avsedd att vara rik, flexibel och lätt att använda. Kvaliteten på hälsorapporterna avgör precisionen i klustrets hälsovy. Falska positiva identifieringar som felaktigt visar problem med feltillstånd kan påverka uppgraderingar eller andra tjänster som använder hälsodata negativt. Exempel på sådana tjänster är reparationstjänster och aviseringsmekanismer. Därför behövs en del tankar för att tillhandahålla rapporter som fångar in intressanta villkor på bästa möjliga sätt.

Rapportering kan göras från:

  • Den övervakade Service Fabric-tjänstrepliken eller -instansen.
  • Interna vakthundar distribuerade som en Service Fabric-tjänst (till exempel en tillståndslös Service Fabric-tjänst som övervakar villkor och utfärdar rapporter). Vakthundarna kan distribueras på alla noder eller kopplas till den övervakade tjänsten.
  • Interna vakthundar som körs på Service Fabric-noderna men som inte implementeras som Service Fabric-tjänster.
  • Externa vakthundar som avsöker resursen utanför Service Fabric-klustret (till exempel övervakningstjänsten Gomez).

Service Fabric-komponenter rapporterar hälsotillståndet för alla entiteter i klustret. Systemhälsorapporter ger insyn i kluster- och programfunktioner och flaggar problem via hälsa. För program och tjänster verifierar systemhälsorapporterna att entiteter implementeras och beter sig korrekt ur Service Fabric-körningens perspektiv. Rapporterna tillhandahåller ingen hälsoövervakning av tjänstens affärslogik eller identifieringsprocesser som har slutat svara. Om du vill lägga till hälsoinformation som är specifik för din tjänsts logik implementerar du anpassad hälsorapportering i dina tjänster.

Service Fabric tillhandahåller flera sätt att visa hälsorapporter aggregerade i hälsoarkivet:

På den här sidan finns en träningsvideo som beskriver Service Fabric-hälsomodellen och hur den används:

Övervakning och diagnostik

Övervakning och diagnostik är avgörande för att utveckla, testa och distribuera program och tjänster i alla miljöer. Service Fabric-lösningar fungerar bäst när du planerar och implementerar övervakning och diagnostik som hjälper till att säkerställa att program och tjänster fungerar som förväntat i en lokal utvecklingsmiljö eller i produktion.

Huvudmålen med övervakning och diagnostik är att:

  • Identifiera och diagnostisera problem med maskinvara och infrastruktur
  • Identifiera problem med programvara och appar, minska tjänstavbrott
  • Förstå resursförbrukning och hjälpa till att driva på driftsbeslut
  • Optimera prestanda för program, tjänster och infrastruktur
  • Generera affärsinsikter och identifiera förbättringsområden

Det övergripande arbetsflödet för övervakning och diagnostik består av tre steg:

  1. Händelsegenerering: Detta inkluderar händelser (loggar, spårningar, anpassade händelser) på infrastrukturnivå (kluster), plattform och program/tjänstnivå
  2. Händelseaggregering: Genererade händelser måste samlas in och aggregeras innan de kan visas
  3. Analys: händelser måste visualiseras och vara tillgängliga i något format för att möjliggöra analys och visning efter behov

Det finns flera tillgängliga produkter som täcker dessa tre områden, och du kan välja olika tekniker för var och en. Mer information finns i Övervakning och diagnostik för Azure Service Fabric.

Nästa steg