Dela via

Metodtips för Azure Service Fabric-program

  • Artikel

Den här artikeln innehåller vägledning om bästa praxis för att skapa program och tjänster i Azure Service Fabric.

Bekanta dig med Service Fabric

Vägledning för programdesign

Bekanta dig med den allmänna arkitekturen för Service Fabric-program och deras designöverväganden.

Välj en API-gateway

Använd en API-gatewaytjänst som kommunicerar med serverdelstjänster som sedan kan skalas ut. De vanligaste API Gateway-tjänsterna som används är:

Tillståndslösa tjänster

Vi rekommenderar att du alltid börjar med att skapa tillståndslösa tjänster med hjälp av Reliable Services och lagringstillstånd i en Azure-databas, Azure Cosmos DB eller Azure Storage. Externaliserat tillstånd är den mer välbekanta metoden för de flesta utvecklare. Med den här metoden kan du också dra nytta av frågefunktionerna i arkivet.

När du ska använda tillståndskänsliga tjänster

Överväg tillståndskänsliga tjänster när du har ett scenario för låg svarstid och behöver hålla data nära beräkningen. Några exempelscenarier är IoT Digital Twin-enheter, speltillstånd, sessionstillstånd, cachelagring av data från en databas och långvariga arbetsflöden för att spåra anrop till andra tjänster.

Besluta om tidsramen för datakvarhållning:

  • Cachelagrade data. Använd cachelagring när svarstid till externa butiker är ett problem. Använd en tillståndskänslig tjänst som din egen datacache eller överväg att använda SoCreate Service Fabric Distributed Cache med öppen källkod. I det här scenariot behöver du inte oroa dig om du förlorar alla data i cacheminnet.
  • Tidsbundna data. I det här scenariot måste du hålla data nära beräkning under en tidsperiod för svarstid, men du har råd att förlora data i en katastrof. I många IoT-lösningar måste data till exempel vara nära beräkning, till exempel när medeltemperaturen under de senaste dagarna beräknas, men om dessa data går förlorade är de specifika datapunkter som registrerats inte så viktiga. I det här scenariot bryr du dig vanligtvis inte om att säkerhetskopiera enskilda datapunkter. Du säkerhetskopierar endast beräknade genomsnittsvärden som skrivs regelbundet till extern lagring.
  • Långsiktiga data. Tillförlitliga samlingar kan lagra dina data permanent. Men i det här fallet måste du förbereda dig för haveriberedskap, inklusive att konfigurera regelbundna säkerhetskopieringsprinciper för dina kluster. I själva verket konfigurerar du vad som händer om klustret förstörs i en katastrof, där du skulle behöva skapa ett nytt kluster och hur du distribuerar nya programinstanser och återställer från den senaste säkerhetskopian.

Spara kostnader och förbättra tillgängligheten:

  • Du kan minska kostnaderna genom att använda tillståndskänsliga tjänster eftersom du inte ådrar dig kostnader för dataåtkomst och transaktioner från fjärrarkivet, och eftersom du inte behöver använda någon annan tjänst, till exempel Azure Cache for Redis.
  • Det är dyrt att använda tillståndskänsliga tjänster främst för lagring och inte för beräkning, och vi rekommenderar det inte. Tänk på tillståndskänsliga tjänster som beräkning med billig lokal lagring.
  • Genom att ta bort beroenden för andra tjänster kan du förbättra tjänstens tillgänglighet. Att hantera tillstånd med HA i klustret isolerar dig från andra problem med tjänstavbrott eller svarstider.

Så här arbetar du med Reliable Services

Med Service Fabric Reliable Services kan du enkelt skapa tillståndslösa och tillståndskänsliga tjänster. Mer information finns i introduktionen till Reliable Services.

  • Respektera alltid annulleringstoken i RunAsync() metoden för tillståndslösa och tillståndskänsliga tjänster och ChangeRole() metoden för tillståndskänsliga tjänster. Om du inte gör det vet Inte Service Fabric om tjänsten kan stängas. Om du till exempel inte respekterar annulleringstoken kan det inträffa mycket längre programuppgraderingstider.
  • Öppna och stäng kommunikationslyssnare i tid och respektera annulleringstoken.
  • Blanda aldrig synkroniseringskod med asynkron kod. Använd till exempel inte .GetAwaiter().GetResult() i dina asynkrona anrop. Använd asynkronisering hela vägen genom anropsstacken.

Så här arbetar du med Reliable Actors

Med Service Fabric Reliable Actors kan du enkelt skapa tillståndskänsliga, virtuella aktörer. Mer information finns i introduktionen till Reliable Actors.

  • Överväg att använda pub-/undermeddelanden mellan dina aktörer för att skala ditt program. Verktyg som tillhandahåller den här tjänsten är SoCreate Service Fabric Pub/Sub med öppen källkod och Azure Service Bus.
  • Gör aktörstillståndet så detaljerat som möjligt.
  • Hantera skådespelarens livscykel. Ta bort aktörer om du inte ska använda dem igen. Det är särskilt viktigt att ta bort onödiga aktörer när du använder den flyktiga tillståndsprovidern, eftersom allt tillstånd lagras i minnet.
  • På grund av deras turbaserade samtidighet används aktörer bäst som oberoende objekt. Skapa inte grafer över anrop med flera aktörer, synkrona metoder (som sannolikt blir ett separat nätverksanrop) eller skapa förfrågningar om cirkulär aktör. Dessa påverkar prestanda och skalning avsevärt.
  • Blanda inte synkroniseringskod med asynkron kod. Använd asynkront för att förhindra prestandaproblem.
  • Ring inte långvariga samtal i skådespelare. Långvariga anrop blockerar andra anrop till samma aktör på grund av den turbaserade samtidigheten.
  • Om du kommunicerar med andra tjänster med hjälp av Service Fabric-fjärrkommunikation och du skapar en ServiceProxyFactoryskapar du fabriken på aktörstjänstnivå och inte på aktörsnivå.

Programdiagnostik

Var noggrann med att lägga till programloggning i tjänstanrop. Det hjälper dig att diagnostisera scenarier där tjänster anropar varandra. När A till exempel anropar B anropar C anropar D kan samtalet misslyckas var som helst. Om du inte har tillräckligt med loggning är fel svåra att diagnostisera. Om tjänsterna loggar för mycket på grund av samtalsvolymer bör du åtminstone logga fel och varningar.

Designvägledning för Azure