Lär dig mer om skillnaderna mellan Cloud Services och Service Fabric innan du migrerar program.

Microsoft Azure Service Fabric är nästa generations molnprogramplattform för mycket skalbara, mycket tillförlitliga distribuerade program. Den introducerar många nya funktioner för paketering, distribution, uppgradering och hantering av distribuerade molnprogram.

Det här är en introduktionsguide för att migrera program från Cloud Services till Service Fabric. Den fokuserar främst på arkitektur- och designskillnader mellan Cloud Services och Service Fabric.

Program och infrastruktur

En grundläggande skillnad mellan Cloud Services och Service Fabric är relationen mellan virtuella datorer, arbetsbelastningar och program. En arbetsbelastning här definieras som den kod du skriver för att utföra en viss uppgift eller tillhandahålla en tjänst.

• Cloud Services handlar om att distribuera program som virtuella datorer. Koden du skriver är nära kopplad till en VM-instans, till exempel en webb- eller arbetsroll. Att distribuera en arbetsbelastning i Cloud Services är att distribuera en eller flera VM-instanser som kör arbetsbelastningen. Det finns ingen uppdelning av program och virtuella datorer, så det finns ingen formell definition av ett program. Ett program kan betraktas som en uppsättning webb- eller arbetsrollinstanser i en Cloud Services distribution eller som en hel Cloud Services distribution. I det här exemplet visas ett program som en uppsättning rollinstanser.

• Service Fabric handlar om att distribuera program till befintliga virtuella datorer eller datorer som kör Service Fabric i Windows eller Linux. De tjänster som du skriver är helt frikopplade från den underliggande infrastrukturen, som abstraheras bort av Service Fabric-programplattformen, så att ett program kan distribueras till flera miljöer. En arbetsbelastning i Service Fabric kallas för en "tjänst" och en eller flera tjänster grupperas i ett formellt definierat program som körs på Service Fabric-programplattformen. Flera program kan distribueras till ett enda Service Fabric-kluster.

Själva Service Fabric är ett programplattformslager som körs i Windows eller Linux, medan Cloud Services är ett system för distribution av Azure-hanterade virtuella datorer med anslutna arbetsbelastningar. Service Fabric-programmodellen har ett antal fördelar:

• Snabba distributionstider. Det kan ta lång tid att skapa VM-instanser. I Service Fabric distribueras virtuella datorer bara en gång för att bilda ett kluster som är värd för Service Fabric-programplattformen. Från och med nu kan programpaket distribueras till klustret mycket snabbt.
• Värdtjänster med hög densitet. I Cloud Services är en virtuell arbetsroll värd för en arbetsbelastning. I Service Fabric är programmen separata från de virtuella datorer som kör dem, vilket innebär att du kan distribuera ett stort antal program till ett litet antal virtuella datorer, vilket kan sänka den totala kostnaden för större distributioner.
• Service Fabric-plattformen kan köras var som helst som har Windows Server- eller Linux-datorer, oavsett om det är Azure eller lokalt. Plattformen tillhandahåller ett abstraktionslager över den underliggande infrastrukturen så att ditt program kan köras i olika miljöer.
• Hantering av distribuerade program. Service Fabric är en plattform som inte bara är värd för distribuerade program, utan även hjälper till att hantera livscykeln oberoende av värddatorns eller datorns livscykel.

Programmets arkitektur

Arkitekturen för ett Cloud Services program innehåller vanligtvis flera externa tjänstberoenden, till exempel Service Bus, Azure Table och Blob Storage, SQL, Redis och andra för att hantera tillstånd och data för ett program och kommunikation mellan webb- och arbetsroller i en Cloud Services distribution. Ett exempel på ett fullständigt Cloud Services program kan se ut så här:

Service Fabric-program kan också välja att använda samma externa tjänster i ett fullständigt program. Med det här exemplet Cloud Services arkitektur är den enklaste migreringsvägen från Cloud Services till Service Fabric att endast ersätta Cloud Services distribution med ett Service Fabric-program, vilket gör att den övergripande arkitekturen hålls densamma. Webb- och arbetsrollerna kan portas till tillståndslösa Service Fabric-tjänster med minimala kodändringar.

I det här skedet bör systemet fortsätta att fungera på samma sätt som tidigare. Med hjälp av Service Fabrics tillståndskänsliga funktioner kan externa tillståndslager internaliseras som tillståndskänsliga tjänster där så är tillämpligt. Detta är mer inblandat än en enkel migrering av webb- och arbetsroller till tillståndslösa Service Fabric-tjänster, eftersom det kräver att du skriver anpassade tjänster som tillhandahåller motsvarande funktioner för ditt program som de externa tjänsterna gjorde tidigare. Här är några av fördelarna med att göra detta:

• Ta bort externa beroenden
• Förena distributions-, hanterings- och uppgraderingsmodellerna.

Ett exempel på en resulterande arkitektur för att internalisera dessa tjänster kan se ut så här:

Kommunikation och arbetsflöde

De flesta molntjänstprogram består av mer än en nivå. På samma sätt består ett Service Fabric-program av mer än en tjänst (vanligtvis många tjänster). Två vanliga kommunikationsmodeller är direktkommunikation och via extern beständig lagring.

Direktkommunikation

Med direkt kommunikation kan nivåerna kommunicera direkt via slutpunkten som exponeras av varje nivå. I tillståndslösa miljöer som Cloud Services innebär det att du väljer en instans av en VM-roll, antingen slumpmässigt eller resursallokering för att balansera belastningen och ansluta till dess slutpunkt direkt.

Direkt kommunikation är en vanlig kommunikationsmodell i Service Fabric. Den största skillnaden mellan Service Fabric och Cloud Services är att du i Cloud Services ansluter till en virtuell dator, medan du i Service Fabric ansluter till en tjänst. Detta är en viktig skillnad av ett par skäl:

• Tjänster i Service Fabric är inte bundna till de virtuella datorer som är värdar för dem. tjänster kan flyttas runt i klustret och förväntas faktiskt flyttas runt av olika skäl: resursutjämning, redundans, uppgraderingar av program och infrastruktur samt placerings- eller belastningsbegränsningar. Det innebär att en tjänstinstans adress kan ändras när som helst.
• En virtuell dator i Service Fabric kan vara värd för flera tjänster, var och en med unika slutpunkter.

Service Fabric tillhandahåller en metod för tjänstidentifiering som kallas namngivningstjänst, som kan användas för att matcha slutpunktsadresser för tjänster.

Köer

En vanlig kommunikationsmekanism mellan nivåer i tillståndslösa miljöer som Cloud Services är att använda en extern lagringskö för att varaktigt lagra arbetsuppgifter från en nivå till en annan. Ett vanligt scenario är en webbnivå som skickar jobb till en Azure-kö eller Service Bus där arbetsrollinstanser kan dequeue och bearbeta jobben.

Samma kommunikationsmodell kan användas i Service Fabric. Detta kan vara användbart när du migrerar ett befintligt Cloud Services-program till Service Fabric.

Paritet

Cloud Services liknar Service Fabric i grad av kontroll jämfört med användarvänlighet, men det är nu en äldre tjänst och Service Fabric rekommenderas för ny utveckling. Följande är en API-jämförelse:

API för molntjänst	Service Fabric-API	Kommentarer
RoleInstance.GetID	FabricRuntime.GetNodeContext.NodeId eller . NodeName	ID är en egenskap för NodeName
RoleInstance.GetFaultDomain	FabricClient.QueryManager.GetNodeList	Filtrera på NodeName och använd FD-egenskapen
RoleInstance.GetUpgradeDomain	FabricClient.QueryManager.GetNodeList	Filtrera på NodeName och använd egenskapen Uppgradera
RoleInstance.GetInstanceEndpoints	FabricRuntime.GetActivationContext eller namngivning (ResolveService)	CodePackageActivationContext som tillhandahålls både av FabricRuntime.GetActivationContext och i replikerna via ServiceInitializationParameters.CodePackageActivationContext som angavs under . Initiera
RoleEnvironment.GetRoles	FabricClient.QueryManager.GetNodeList	Om du vill göra samma typ av filtrering efter typ kan du hämta listan över nodtyper från klustermanifestet via FabricClient.ClusterManager.GetClusterManifest och hämta roll-/nodtyperna därifrån.
RoleEnvironment.GetIsAvailable	Connect-WindowsFabricCluster eller skapa en FabricRuntime som pekar på en viss nod	*
RoleEnvironment.GetLocalResource	CodePackageActivationContext.Log/Temp/Work	*
RoleEnvironment.GetCurrentRoleInstance	CodePackageActivationContext.Log/Temp/Work	*
LocalResource.GetRootPath	CodePackageActivationContext.Log/Temp/Work	*
Role.GetInstances	FabricClient.QueryManager.GetNodeList eller ResolveService	*
RoleInstanceEndpoint.GetIPEndpoint	FabricRuntime.GetActivationContext eller namngivning (ResolveService)	*

Nästa steg

Den enklaste migreringsvägen från Cloud Services till Service Fabric är att endast ersätta Cloud Services distribution med ett Service Fabric-program, vilket gör att programmets övergripande arkitektur är ungefär densamma. Följande artikel innehåller en guide för att konvertera en webb- eller arbetsroll till en tillståndslös Service Fabric-tjänst.

• Enkel migrering: konvertera en webb- eller arbetsroll till en tillståndslös Service Fabric-tjänst