Konfigurera och använda tjänsttillhörighet i Service Fabric

Tillhörighet är en kontroll som främst tillhandahålls för att underlätta övergången av större monolitiska program till molnet och mikrotjänstvärlden. Det används också som en optimering för att förbättra prestanda för tjänster, även om det kan ha biverkningar.

Anta att du tar med en större app, eller en som helt enkelt inte har utformats med mikrotjänster i åtanke, till Service Fabric (eller någon distribuerad miljö). Den här typen av övergång är vanlig. Du börjar med att lyfta hela appen i miljön, paketera den och se till att den fungerar smidigt. Sedan börjar du dela upp det i olika mindre tjänster som alla pratar med varandra.

Så småningom kanske du upptäcker att programmet har vissa problem. Problemen hör vanligtvis till någon av följande kategorier:

1. En del komponent X i den monolitiska appen hade ett odokumenterad beroende av komponent Y, och du har precis omvandlat dessa komponenter till separata tjänster. Eftersom dessa tjänster nu körs på olika noder i klustret är de brutna.
2. Dessa komponenter kommunicerar via (lokalt namngivna pipes | delat minne | filer på disk) och de måste verkligen kunna skriva till en delad lokal resurs av prestandaskäl just nu. Det hårda beroendet tas bort senare, kanske.
3. Allt är bra, men det visar sig att dessa två komponenter faktiskt är chattiga/ prestandakänsliga. När de flyttade dem till separata tjänster ökade den övergripande programprestandan eller svarstiden. Det innebär att det övergripande programmet inte uppfyller förväntningarna.

I dessa fall vill vi inte förlora vårt refaktoriseringsarbete och vill inte gå tillbaka till monoliten. Det sista villkoret kan till och med vara önskvärt som en vanlig optimering. Men tills vi kan göra om komponenterna så att de fungerar naturligt som tjänster (eller tills vi kan lösa prestandaförväntningarna på något annat sätt) behöver vi en viss känsla av ort.

Vad bör jag göra? Du kan försöka aktivera tillhörighet.

Konfigurera tillhörighet

Om du vill konfigurera tillhörighet definierar du en tillhörighetsrelation mellan två olika tjänster. Du kan tänka på tillhörighet som att "peka" en tjänst mot en annan och säga "Den här tjänsten kan bara köras där tjänsten körs.". Ibland refererar vi till tillhörighet som en överordnad/underordnad relation (där du pekar barnet mot den överordnade). Tillhörighet säkerställer att replikerna eller instanserna av en tjänst placeras på samma noder som för en annan tjänst.

ServiceCorrelationDescription affinityDescription = new ServiceCorrelationDescription();
affinityDescription.Scheme = ServiceCorrelationScheme.Affinity;
affinityDescription.ServiceName = new Uri("fabric:/otherApplication/parentService");
serviceDescription.Correlations.Add(affinityDescription);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Kommentar

En underordnad tjänst kan bara delta i en enda tillhörighetsrelation. Om du vill att barnet ska mappas till två överordnade tjänster samtidigt har du ett par alternativ:

• Ångra relationerna (ha parentService1- och parentService2-punkten vid den aktuella underordnade tjänsten) eller
• Utse en av föräldrarna som en hubb enligt konvention och ha alla tjänster punkt vid den tjänsten.

Det resulterande placeringsbeteendet i klustret bör vara detsamma.

Olika tillhörighetsalternativ

Tillhörighet representeras via ett av flera korrelationsscheman och har två olika lägen. Det vanligaste tillhörighetsläget är vad vi kallar NonAlignedAffinity. I NonAlignedAffinity placeras repliker eller instanser av de olika tjänsterna på samma noder. Det andra läget är AlignedAffinity. Justerad tillhörighet är endast användbar med tillståndskänsliga tjänster. Om du konfigurerar två tillståndskänsliga tjänster för att ha justerad tillhörighet ser du till att primärvärdena för dessa tjänster placeras på samma noder som varandra. Det gör också att varje par av sekundärfiler för dessa tjänster placeras på samma noder. Det är också möjligt (men mindre vanligt) att konfigurera NonAlignedAffinity för tillståndskänsliga tjänster. För NonAlignedAffinity skulle de olika replikerna av de två tillståndskänsliga tjänsterna köras på samma noder, men deras primärval kan hamna på olika noder.

Önskat tillstånd för bästa insats

En tillhörighetsrelation är det bästa sättet. Den ger inte samma garantier för samverkan eller tillförlitlighet som körs i samma körbara process. Tjänsterna i en tillhörighetsrelation är i grunden olika entiteter som kan misslyckas och flyttas oberoende av varandra. En tillhörighetsrelation kan också brytas, även om dessa pauser är tillfälliga. Kapacitetsbegränsningar kan till exempel innebära att endast vissa tjänstobjekt i tillhörighetsrelationen får plats på en viss nod. I dessa fall, även om det finns en tillhörighetsrelation på plats, kan den inte tillämpas på grund av de andra begränsningarna. Om det är möjligt att göra det korrigeras överträdelsen automatiskt senare.

Kedjor kontra stjärnor

I dag kan inte Klusterresurshanteraren modellera kedjor av tillhörighetsrelationer. Det innebär att en tjänst som är underordnad i en tillhörighetsrelation inte kan vara överordnad i en annan tillhörighetsrelation. Om du vill modellera den här typen av relation måste du effektivt modellera den som en stjärna i stället för en kedja. Om du vill flytta från en kedja till en stjärna skulle det nedersta barnet i stället vara överordnat till det första underordnade barnets överordnade. Beroende på hur dina tjänster fungerar kan du behöva göra detta flera gånger. Om det inte finns någon naturlig överordnad tjänst kan du behöva skapa en som fungerar som platshållare. Beroende på dina krav kanske du också vill titta på programgrupper.

En annan sak att notera om tillhörighetsrelationer i dag är att de är riktningsmässiga som standard. Det innebär att tillhörighetsregeln endast framtvingar att det underordnade objektet placeras hos den överordnade. Det säkerställer inte att den överordnade finns med det underordnade objektet. Därför, om det finns en tillhörighetsöverträdelse och för att korrigera överträdelsen av någon anledning är det inte möjligt att flytta det underordnade till den överordnade noden, kommer den överordnade enheten inte att flyttas till den underordnade noden, även om det skulle ha korrigerat överträdelsen om den överordnade enheten flyttades till den underordnade noden. Om du anger config MoveParentToFixAffinityViolation till true skulle riktningsinställningen ta bort. Det är också viktigt att observera att tillhörighetsrelationen inte kan vara perfekt eller tillämpas omedelbart eftersom olika tjänster har med olika livscykeler och kan misslyckas och flyttas oberoende av varandra. Anta till exempel att den överordnade plötsligt redundansväxlar över till en annan nod eftersom den kraschade. Klusterresurshanteraren och Redundanshanteraren hanterar redundansen först, eftersom det är prioriteten att hålla tjänsterna uppdaterade, konsekventa och tillgängliga. När redundansväxlingen är klar bryts tillhörighetsrelationen, men Klusterresurshanteraren anser att allt är bra tills det märker att det underordnade inte finns med den överordnade. Den här typen av kontroller utförs regelbundet. Mer information om hur Klusterresurshanteraren utvärderar begränsningar finns i den här artikeln, och den här innehåller mer information om hur du konfigurerar den takt som dessa begränsningar utvärderas för.

Stöd för partitionering

Det sista att märka om tillhörighet är att tillhörighetsrelationer inte stöds där den överordnade är partitionerad. Partitionerade överordnade tjänster kan stödjas så småningom, men i dag är det inte tillåtet.

Nästa steg

• Mer information om hur du konfigurerar tjänster finns i Mer information om hur du konfigurerar tjänster
• Om du vill begränsa tjänster till en liten uppsättning datorer eller aggregera belastningen på tjänster använder du programgrupper