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 migrering av 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 som 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 arbetsrollsinstanser 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 att distribuera 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 virtuella datorinstanser. 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 då kan programpaket distribueras till klustret mycket snabbt.
• Högdensitetsvärd. I Cloud Services är en virtuell arbetsrollsdator värd för en arbetsbelastning. I Service Fabric är program åtskilda 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.
• Distribuerad programhantering. 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 många externa tjänstberoenden, till exempel Service Bus, Azure Table och Blob Storage, SQL, Redis och andra för att hantera tillståndet och data för ett program och kommunikation mellan webb- och arbetsroller i en Cloud Services-distribution. Ett exempel på ett komplett 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 komplett program. Med hjälp av det här exemplet är Cloud Services-arkitekturen den enklaste migreringsvägen från Cloud Services till Service Fabric att endast ersätta Cloud Services-distributionen med ett Service Fabric-program, vilket håller den övergripande arkitekturen densamma. Webb- och arbetsroller 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. Om du drar nytta 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 involverat ä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 ger motsvarande funktioner till ditt program som de externa tjänsterna gjorde tidigare. Exempel på fördelar med det:

• Ta bort externa beroenden
• Ena 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 en extern beständig lagring.

Direkt kommunikation

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.

Direktkommunikation är en gemensam 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 i själva verket flytta runt av olika skäl: Resursutjämning, redundans, program- och infrastrukturuppgraderingar 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 tjänstidentifieringsmekanism, kallad namngivningstjänsten, 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, till exempel Cloud Services, är att använda en extern lagringskö för att lagra arbetsuppgifter på ett lämpligt sätt 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:

Nästa steg

Den enklaste migreringsvägen från Cloud Services till Service Fabric är att endast ersätta Cloud Services-distributionen med ett Service Fabric-program, vilket håller programmets övergripande arkitektur 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