Dela via

Skalning i Service Fabric

  • Artikel

Azure Service Fabric gör det enkelt att skapa skalbara program genom att hantera tjänster, partitioner och repliker på noderna i ett kluster. Att köra många arbetsbelastningar på samma maskinvara möjliggör maximal resursanvändning, men ger också flexibilitet när det gäller hur du väljer att skala dina arbetsbelastningar. Den här Channel 9-videon beskriver hur du kan skapa skalbara mikrotjänstprogram:

Skalning i Service Fabric utförs på flera olika sätt:

  1. Skala genom att skapa eller ta bort tillståndslösa tjänstinstanser
  2. Skala genom att skapa eller ta bort nya namngivna tjänster
  3. Skala genom att skapa eller ta bort nya namngivna programinstanser
  4. Skalning med partitionerade tjänster
  5. Skala genom att lägga till och ta bort noder från klustret
  6. Skalning med hjälp av mått för kluster Resource Manager

Skala genom att skapa eller ta bort tillståndslösa tjänstinstanser

Ett av de enklaste sätten att skala i Service Fabric fungerar med tillståndslösa tjänster. När du skapar en tillståndslös tjänst får du en chans att definiera en InstanceCount. InstanceCount definierar hur många kopior som körs av tjänstens kod som skapas när tjänsten startas. Anta till exempel att det finns 100 noder i klustret. Anta också att en tjänst skapas med InstanceCount 10. Under körningen kan de 10 kopior av koden som körs bli för upptagna (eller vara tillräckligt upptagna). Ett sätt att skala den arbetsbelastningen är att ändra antalet instanser. En del övervaknings- eller hanteringskod kan till exempel ändra det befintliga antalet instanser till 50 eller till 5, beroende på om arbetsbelastningen behöver skalas in eller ut baserat på belastningen.

C#:

StatelessServiceUpdateDescription updateDescription = new StatelessServiceUpdateDescription(); 
updateDescription.InstanceCount = 50;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

PowerShell:

Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50

Använda dynamiskt instansantal

Specifikt för tillståndslösa tjänster erbjuder Service Fabric ett automatiskt sätt att ändra antalet instanser. På så sätt kan tjänsten skalas dynamiskt med det antal noder som är tillgängliga. Sättet att välja det här beteendet är att ange antalet instanser = -1. InstanceCount = -1 är en instruktion för Service Fabric som säger "Kör den här tillståndslösa tjänsten på varje nod". Om antalet noder ändras ändrar Service Fabric automatiskt antalet instanser så att det matchar, vilket säkerställer att tjänsten körs på alla giltiga noder.

C#:

StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//Set other service properties necessary for creation....
serviceDescription.InstanceCount = -1;
await fc.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

Skala genom att skapa eller ta bort nya namngivna tjänster

En namngiven tjänstinstans är en specifik instans av en tjänsttyp (se Livscykel för Service Fabric-program) i någon namngiven programinstans i klustret.

Nya namngivna tjänstinstanser kan skapas (eller tas bort) när tjänsterna blir mer eller mindre upptagna. Detta gör att begäranden kan spridas över fler tjänstinstanser, vilket vanligtvis gör att belastningen på befintliga tjänster minskar. När du skapar tjänster placerar Service Fabric-klustret Resource Manager tjänsterna i klustret på ett distribuerat sätt. De exakta besluten styrs av måtten i klustret och andra placeringsregler. Tjänster kan skapas på flera olika sätt, men de vanligaste är antingen genom administrativa åtgärder som någon som anropar New-ServiceFabricServiceeller genom kodanrop CreateServiceAsync. CreateServiceAsync kan även anropas inifrån andra tjänster som körs i klustret.

Att skapa tjänster dynamiskt kan användas i alla typer av scenarier och är ett vanligt mönster. Tänk dig till exempel en tillståndskänslig tjänst som representerar ett visst arbetsflöde. Anrop som representerar arbete kommer att visas för den här tjänsten, och den här tjänsten kommer att köra stegen i arbetsflödet och registrera förloppet.

Hur skulle du göra den här specifika tjänstskalan? Tjänsten kan vara flera klientorganisationer i någon form och acceptera anrop och starta steg för många olika instanser av samma arbetsflöde samtidigt. Det kan dock göra koden mer komplex, eftersom den nu måste oroa sig för många olika instanser av samma arbetsflöde, alla i olika skeden och från olika kunder. Att hantera flera arbetsflöden samtidigt löser inte heller skalningsproblemet. Det beror på att den här tjänsten någon gång förbrukar för många resurser för att få plats på en viss dator. Många tjänster som inte har skapats för det här mönstret i första hand upplever också svårigheter på grund av en del inneboende flaskhalsar eller långsammare kod. De här typerna av problem gör att tjänsten inte fungerar lika bra när antalet samtidiga arbetsflöden som den spårar blir större.

En lösning är att skapa en instans av den här tjänsten för varje annan instans av arbetsflödet som du vill spåra. Det här är ett bra mönster och fungerar oavsett om tjänsten är tillståndslös eller tillståndskänslig. För att det här mönstret ska fungera finns det vanligtvis en annan tjänst som fungerar som en "Workload Manager-tjänst". Tjänstens jobb är att ta emot begäranden och dirigera dessa begäranden till andra tjänster. Chefen kan dynamiskt skapa en instans av arbetsbelastningstjänsten när den tar emot meddelandet och sedan skicka begäranden till dessa tjänster. Chefstjänsten kan också få återanrop när en viss arbetsflödestjänst slutför sitt jobb. När chefen tar emot dessa återanrop kan den ta bort den instansen av arbetsflödestjänsten eller lämna den om fler anrop förväntas.

Avancerade versioner av den här typen av chef kan till och med skapa pooler av de tjänster som hanteras. Poolen hjälper till att se till att när en ny begäran kommer in behöver den inte vänta tills tjänsten har startats. I stället kan chefen bara välja en arbetsflödestjänst som för närvarande inte är upptagen från poolen eller dirigera slumpmässigt. Om du håller en pool med tjänster tillgänglig går det snabbare att hantera nya begäranden, eftersom det är mindre troligt att begäran måste vänta på att en ny tjänst spunnits upp. Det går snabbt att skapa nya tjänster, men inte kostnadsfritt eller omedelbart. Poolen hjälper till att minimera den tid som begäran måste vänta innan den hanteras. Du ser ofta det här hanteraren och poolmönstret när svarstiderna är som mest viktiga. Att köa begäran och skapa tjänsten i bakgrunden och sedan skicka den vidare är också ett populärt hanteringsmönster, liksom att skapa och ta bort tjänster baserat på viss spårning av mängden arbete som tjänsten för närvarande har väntande.

Skala genom att skapa eller ta bort nya namngivna programinstanser

Att skapa och ta bort hela programinstanser liknar mönstret för att skapa och ta bort tjänster. För det här mönstret finns det någon chefstjänst som fattar beslutet baserat på de begäranden som visas och den information som den tar emot från de andra tjänsterna i klustret.

När ska du skapa en ny namngiven programinstans i stället för att skapa en ny namngiven tjänstinstans i ett befintligt program? Det finns några fall:

  • Den nya programinstansen är avsedd för en kund vars kod måste köras under vissa specifika identitets- eller säkerhetsinställningar.
    • Med Service Fabric kan du definiera olika kodpaket som ska köras under vissa identiteter. För att kunna starta samma kodpaket under olika identiteter måste aktiveringarna ske i olika programinstanser. Tänk dig ett fall där du har distribuerat en befintlig kunds arbetsbelastningar. Dessa kan köras under en viss identitet så att du kan övervaka och kontrollera deras åtkomst till andra resurser, till exempel fjärrdatabaser eller andra system. I det här fallet, när en ny kund registrerar sig, vill du förmodligen inte aktivera koden i samma kontext (processutrymme). Även om du kan, gör detta det svårare för din tjänstkod att agera inom ramen för en viss identitet. Vanligtvis måste du ha mer kod för säkerhet, isolering och identitetshantering. I stället för att använda olika namngivna tjänstinstanser i samma programinstans och därmed samma processutrymme kan du använda olika namngivna Service Fabric-programinstanser. Det gör det enklare att definiera olika identitetskontexter.
  • Den nya programinstansen fungerar också som ett sätt att konfigurera
    • Som standard körs alla namngivna tjänstinstanser av en viss tjänsttyp i en programinstans i samma process på en viss nod. Det innebär att även om du kan konfigurera varje tjänstinstans på olika sätt är det komplicerat att göra det. Tjänsterna måste ha en token som de använder för att leta upp konfigurationen i ett konfigurationspaket. Vanligtvis är detta bara tjänstens namn. Detta fungerar bra, men det kopplar konfigurationen till namnen på de enskilda namngivna tjänstinstanserna i den programinstansen. Detta kan vara förvirrande och svårt att hantera eftersom konfigurationen normalt är en designtidsartefakt med specifika värden för programinstanser. Att skapa fler tjänster innebär alltid fler programuppgraderingar för att ändra informationen i konfigurationspaketen eller för att distribuera nya så att de nya tjänsterna kan söka efter deras specifika information. Det är ofta enklare att skapa en helt ny namngiven programinstans. Sedan kan du använda programparametrarna för att ange vilken konfiguration som krävs för tjänsterna. På så sätt kan alla tjänster som skapas i den namngivna programinstansen ärva vissa konfigurationsinställningar. I stället för att till exempel ha en enda konfigurationsfil med inställningarna och anpassningarna för varje kund, till exempel hemligheter eller resursgränser per kund, skulle du i stället ha en annan programinstans för varje kund med de här inställningarna åsidosatta.
  • Det nya programmet fungerar som en uppgraderingsgräns
    • I Service Fabric fungerar olika namngivna programinstanser som gränser för uppgradering. En uppgradering av en namngiven programinstans påverkar inte koden som en annan namngiven programinstans kör. De olika programmen kommer att köra olika versioner av samma kod på samma noder. Detta kan vara en faktor när du behöver fatta ett skalningsbeslut eftersom du kan välja om den nya koden ska följa samma uppgraderingar som en annan tjänst eller inte. Anta till exempel att ett samtal kommer till chefstjänsten som ansvarar för att skala en viss kunds arbetsbelastningar genom att skapa och ta bort tjänster dynamiskt. I det här fallet gäller dock anropet för en arbetsbelastning som är associerad med en ny kund. De flesta kunder gillar att vara isolerade från varandra, inte bara av säkerhets- och konfigurationsskäl som angavs tidigare, utan för att det ger mer flexibilitet när det gäller att köra specifika versioner av programvaran och välja när de uppgraderas. Du kan också skapa en ny programinstans och skapa tjänsten där helt enkelt för att ytterligare partitionera mängden av dina tjänster som en uppgradering kommer att beröra. Separata programinstanser ger större kornighet vid programuppgraderingar och aktiverar även A/B-testning och blå/gröna distributioner.
  • Den befintliga programinstansen är full
    • I Service Fabric är programkapacitet ett begrepp som du kan använda för att styra mängden resurser som är tillgängliga för vissa programinstanser. Du kan till exempel bestämma att en viss tjänst måste ha en annan instans skapad för att kunna skalas. Den här programinstansen har dock inte kapacitet för ett visst mått. Om just den här kunden eller arbetsbelastningen fortfarande ska beviljas fler resurser kan du antingen öka den befintliga kapaciteten för programmet eller skapa ett nytt program.

Skalning på partitionsnivå

Service Fabric stöder partitionering. Partitionering delar upp en tjänst i flera logiska och fysiska avsnitt, som var och en fungerar oberoende av varandra. Detta är användbart med tillståndskänsliga tjänster, eftersom ingen uppsättning repliker behöver hantera alla anrop och manipulera hela tillståndet samtidigt. Partitioneringsöversikten innehåller information om vilka typer av partitioneringsscheman som stöds. Replikerna för varje partition sprids över noderna i ett kluster, vilket distribuerar tjänstens belastning och säkerställer att varken tjänsten som helhet eller någon partition har en felkritisk systemdel.

Överväg en tjänst som använder ett intervallpartitioneringsschema med en låg nyckel på 0, en hög nyckel på 99 och ett partitionsantal på 4. I ett kluster med tre noder kan tjänsten ha fyra repliker som delar resurserna på varje nod enligt följande:

Partitionslayout med tre noder

Om du ökar antalet noder flyttar Service Fabric några av de befintliga replikerna dit. Anta till exempel att antalet noder ökar till fyra och att replikerna omfördelas. Nu har tjänsten tre repliker som körs på varje nod, som var och en tillhör olika partitioner. Detta ger bättre resursanvändning eftersom den nya noden inte är kall. Vanligtvis förbättrar det också prestanda eftersom varje tjänst har fler tillgängliga resurser.

Partitionslayout med fyra noder

Skalning med service fabric-kluster Resource Manager och mått

Mått är hur tjänster uttrycker sin resursförbrukning till Service Fabric. Med hjälp av mått får klustret Resource Manager en möjlighet att organisera om och optimera klustrets layout. Det kan till exempel finnas gott om resurser i klustret, men de kanske inte allokeras till de tjänster som för närvarande fungerar. Med hjälp av mått kan klustrets Resource Manager omorganisera klustret för att säkerställa att tjänsterna har åtkomst till de tillgängliga resurserna.

Skala genom att lägga till och ta bort noder från klustret

Ett annat alternativ för skalning med Service Fabric är att ändra storleken på klustret. Om du ändrar storleken på klustret innebär det att lägga till eller ta bort noder för en eller flera av nodtyperna i klustret. Tänk dig till exempel ett fall där alla noder i klustret är frekventa. Det innebär att klustrets resurser nästan alla förbrukas. I det här fallet är det bästa sättet att skala att lägga till fler noder i klustret. När de nya noderna ansluter till klustret flyttar Service Fabric-klustret Resource Manager tjänster till dem, vilket resulterar i mindre total belastning på de befintliga noderna. För tillståndslösa tjänster med instansantal = -1 skapas fler tjänstinstanser automatiskt. Detta gör att vissa anrop kan flyttas från de befintliga noderna till de nya noderna.

Mer information finns i Klusterskalning.

Välja en plattform

På grund av implementeringsskillnader mellan operativsystem kan valet av Att använda Service Fabric med Windows eller Linux vara en viktig del av skalningen av ditt program. En möjlig barriär är hur mellanlagrad loggning utförs. Service Fabric i Windows använder en kerneldrivrutin för en logg per dator som delas mellan tillståndskänsliga tjänstrepliker. Den här loggen väger cirka 8 GB. Linux använder å andra sidan en mellanlagringslogg på 256 MB för varje replik, vilket gör den mindre idealisk för program som vill maximera antalet förenklade tjänstrepliker som körs på en viss nod. Dessa skillnader i tillfälliga lagringskrav kan potentiellt informera önskad plattform för distribution av Service Fabric-kluster.

Färdigställa allt

Låt oss ta alla idéer som vi har diskuterat här och gå igenom ett exempel. Tänk på följande tjänst: du försöker skapa en tjänst som fungerar som en adressbok och håller fast vid namn och kontaktinformation.

Direkt har du en massa frågor som rör skalning: Hur många användare kommer du att ha? Hur många kontakter kommer varje användare att lagra? Att försöka lista ut allt detta när du står upp för din tjänst för första gången är svårt. Anta att du skulle använda en enda statisk tjänst med ett specifikt partitionsantal. Konsekvenserna av att välja fel partitionsantal kan göra att du får skalningsproblem senare. Även om du väljer rätt antal kanske du inte har all information du behöver. Du måste till exempel också bestämma storleken på klustret i förväg, både vad gäller antalet noder och deras storlekar. Det är vanligtvis svårt att förutsäga hur många resurser en tjänst kommer att förbruka under sin livslängd. Det kan också vara svårt att veta i förväg vilket trafikmönster som tjänsten faktiskt ser. Till exempel kanske personer lägger till och tar bort sina kontakter först på morgonen, eller så är det kanske jämnt fördelat under dagen. Baserat på detta kan du behöva skala ut och in dynamiskt. Du kanske kan lära dig att förutsäga när du behöver skala ut och in, men oavsett vilket måste du förmodligen reagera på att din tjänst ändrar resursförbrukning. Detta kan innebära att ändra storleken på klustret för att tillhandahålla fler resurser när det inte räcker att omorganisera användningen av befintliga resurser.

Men varför ens försöka välja ut ett enda partitionsschema för alla användare? Varför begränsa dig till en tjänst och ett statiskt kluster? Den verkliga situationen är vanligtvis mer dynamisk.

Tänk på följande dynamiska mönster när du skapar för skalning. Du kan behöva anpassa den efter din situation:

  1. Skapa en "manager-tjänst" i stället för att försöka välja ett partitioneringsschema för alla i förväg.
  2. Chefstjänstens uppgift är att titta på kundinformation när de registrerar sig för din tjänst. Beroende på den informationen skapar hanteringstjänsten sedan en instans av din faktiska kontaktlagringstjänst bara för den kunden. Om de kräver viss konfiguration, isolering eller uppgraderingar kan du också bestämma dig för att starta en programinstans för den här kunden.

Det här mönstret för dynamiskt skapande har många fördelar:

  • Du försöker inte gissa rätt partitionsantal för alla användare i förväg eller skapa en enda tjänst som är oändligt skalbar på egen hand.
  • Olika användare behöver inte ha samma antal partitioner, antal repliker, placeringsbegränsningar, mått, standardinläsningar, tjänstnamn, DNS-inställningar eller någon av de andra egenskaper som anges på tjänst- eller programnivå.
  • Du får ytterligare datasegmentering. Varje kund har en egen kopia av tjänsten
    • Varje kundtjänst kan konfigureras på olika sätt och beviljas fler eller färre resurser, med fler eller färre partitioner eller repliker efter behov baserat på deras förväntade skala.
      • Anta till exempel att kunden betalade för "Guld"-nivån – de kan få fler repliker eller större antal partitioner och potentiellt resurser som är dedikerade till deras tjänster via mått och programkapaciteter.
      • Eller säga att de tillhandahöll information som indikerar att antalet kontakter de behövde var "Liten" – de skulle bara få några partitioner eller till och med placeras i en delad tjänstpool med andra kunder.
  • Du kör inte en massa tjänstinstanser eller repliker medan du väntar på att kunderna ska dyka upp
  • Om en kund lämnar tjänsten är det lika enkelt att låta chefen ta bort tjänsten eller programmet som den skapade.

Nästa steg

Mer information om Service Fabric-begrepp finns i följande artiklar: