Guide för att konvertera webb- och arbetsroller till tillståndslösa Service Fabric-tjänster

  • Artikel

Den här artikeln beskriver hur du migrerar dina Cloud Services webb- och arbetsroller till tillståndslösa Service Fabric-tjänster. Det här är den enklaste migreringsvägen från Cloud Services till Service Fabric för program vars övergripande arkitektur kommer att förbli ungefär densamma.

Molntjänstprojekt till Service Fabric-programprojekt

Ett molntjänstprojekt och ett Service Fabric-programprojekt har en liknande struktur och båda representerar distributionsenheten för ditt program– det vill sa att de definierar det fullständiga paket som distribueras för att köra ditt program. Ett molntjänstprojekt innehåller en eller flera webb- eller arbetsroller. På samma sätt innehåller ett Service Fabric-programprojekt en eller flera tjänster.

Skillnaden är att cloud service-projektet kopplar ihop programdistributionen med en VM-distribution och därmed innehåller konfigurationsinställningar för virtuella datorer i det, medan Service Fabric-programprojektet bara definierar ett program som ska distribueras till en uppsättning befintliga virtuella datorer i ett Service Fabric-kluster. Själva Service Fabric-klustret distribueras bara en gång, antingen via en Resource Manager-mall eller via Azure Portal, och flera Service Fabric-program kan distribueras till det.

Service Fabric och Cloud Services projektjämförelse

Arbetsroll till tillståndslös tjänst

Konceptuellt representerar en arbetsroll en tillståndslös arbetsbelastning, vilket innebär att varje instans av arbetsbelastningen är identisk och begäranden kan dirigeras till valfri instans när som helst. Varje instans förväntas inte komma ihåg den tidigare begäran. Tillstånd som arbetsbelastningen körs på hanteras av ett externt tillståndslager, till exempel Azure Table Storage eller Azure Cosmos DB. I Service Fabric representeras den här typen av arbetsbelastning av en tillståndslös tjänst. Det enklaste sättet att migrera en arbetsroll till Service Fabric kan göras genom att konvertera arbetsrollskod till en tillståndslös tjänst.

Arbetsroll till tillståndslös tjänst

Webbroll till tillståndslös tjänst

Precis som i arbetsrollen representerar en webbroll också en tillståndslös arbetsbelastning, och därför kan även den mappas till en tillståndslös Service Fabric-tjänst. Men till skillnad från webbroller stöder Service Fabric inte IIS. För att migrera ett webbprogram från en webbroll till en tillståndslös tjänst måste du först flytta till ett webbramverk som kan vara lokalt och som inte är beroende av IIS eller System.Web, till exempel ASP.NET Core 1.

Program Stöds Migreringssökväg
ASP.NET Web Forms Inga Konvertera till ASP.NET Core 1 MVC
ASP.NET MVC Med migrering Uppgradera till ASP.NET Core 1 MVC
ASP.NET Web API Med migrering Använda lokalt installerad server eller ASP.NET Core 1
ASP.NET Core 1 Ja Ej tillämpligt

Startpunkts-API och livscykel

Arbetsroll- och Service Fabric-tjänst-API:er erbjuder liknande startpunkter:

Startpunkt Arbetsroll Service Fabric-tjänst
Bearbetar Run() RunAsync()
Start av virtuell dator OnStart() Ej tillämpligt
Vm-stopp OnStop() Ej tillämpligt
Öppna lyssnaren för klientbegäranden Ej tillämpligt
  • CreateServiceInstanceListener() för tillståndslös
  • CreateServiceReplicaListener() för tillståndskänslig

Arbetsroll


using Microsoft.WindowsAzure.ServiceRuntime;

namespace WorkerRole1
{
    public class WorkerRole : RoleEntryPoint
    {
        public override void Run()
        {
        }

        public override bool OnStart()
        {
        }

        public override void OnStop()
        {
        }
    }
}

Tillståndslös Service Fabric-tjänst


using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.ServiceFabric.Services.Communication.Runtime;
using Microsoft.ServiceFabric.Services.Runtime;

namespace Stateless1
{
    public class Stateless1 : StatelessService
    {
        protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
        {
        }

        protected override Task RunAsync(CancellationToken cancelServiceInstance)
        {
        }
    }
}

Båda har en primär "Kör"-åsidosättning där bearbetningen ska påbörjas. Service Fabric-tjänster kombinerar Run, Startoch Stop till en enda startpunkt, RunAsync. Tjänsten bör börja fungera när RunAsync den startas och bör sluta fungera när RunAsync metodens CancellationToken signaleras.

Det finns flera viktiga skillnader mellan livscykeln och livslängden för arbetsroller och Service Fabric-tjänster:

  • Livscykel: Den största skillnaden är att en arbetsroll är en virtuell dator och därför är dess livscykel kopplad till den virtuella datorn, vilket inkluderar händelser för när den virtuella datorn startar och stoppas. En Service Fabric-tjänst har en livscykel som är separat från den virtuella datorns livscykel, så den inkluderar inte händelser för när den virtuella värddatorn eller datorn startar och stoppas eftersom de inte är relaterade.
  • Livstid: En arbetsrollinstans återanvänds om Run metoden avslutas. Metoden RunAsync i en Service Fabric-tjänst kan dock köras till slutförande och tjänstinstansen stannar kvar.

Service Fabric tillhandahåller en valfri startpunkt för kommunikationskonfiguration för tjänster som lyssnar efter klientbegäranden. Både Startpunkten för RunAsync och kommunikation är valfria åsidosättningar i Service Fabric-tjänster – tjänsten kan välja att bara lyssna på klientbegäranden eller bara köra en bearbetningsloop, eller båda , vilket är anledningen till att RunAsync-metoden tillåts avslutas utan att starta om tjänstinstansen, eftersom den kan fortsätta att lyssna efter klientbegäranden.

Api och miljö för program

CLOUD SERVICES miljö-API:et innehåller information och funktioner för den aktuella VM-instansen samt information om andra VM-rollinstanser. Service Fabric innehåller information om dess körning och viss information om noden som en tjänst för närvarande körs på.

Miljöuppgift Molntjänster Service Fabric
Konfigurationsinställningar och ändringsmeddelande RoleEnvironment CodePackageActivationContext
Lokal lagring RoleEnvironment CodePackageActivationContext
Slutpunktsinformation RoleInstance
  • Aktuell instans: RoleEnvironment.CurrentRoleInstance
  • Andra roller och instanser: RoleEnvironment.Roles
  • NodeContext för aktuell nodadress
  • FabricClient och ServicePartitionResolver för identifiering av tjänstslutpunkt
Miljöemulering RoleEnvironment.IsEmulated Ej tillämpligt
Samtidig ändringshändelse RoleEnvironment Ej tillämpligt

Konfigurationsinställningar

Konfigurationsinställningar i Cloud Services anges för en VM-roll och gäller för alla instanser av den virtuella datorrollen. De här inställningarna är nyckel/värde-par som anges i ServiceConfiguration.*.cscfg-filer och kan nås direkt via RoleEnvironment. I Service Fabric gäller inställningarna individuellt för varje tjänst och för varje program, snarare än för en virtuell dator, eftersom en virtuell dator kan vara värd för flera tjänster och program. En tjänst består av tre paket:

  • Kod: innehåller tjänstens körbara filer, binärfiler, DLL:er och andra filer som en tjänst måste köra.
  • Konfiguration: alla konfigurationsfiler och inställningar för en tjänst.
  • Data: statiska datafiler som är associerade med tjänsten.

Vart och ett av dessa paket kan versionshanteras och uppgraderas separat. På samma sätt som Cloud Services kan ett konfigurationspaket nås programmatiskt via ett API och händelser är tillgängliga för att meddela tjänsten om en ändring av konfigurationspaketet. En Settings.xml fil kan användas för nyckelvärdeskonfiguration och programmatisk åtkomst som liknar appinställningar i en App.config fil. Men till skillnad från Cloud Services kan ett Service Fabric-konfigurationspaket innehålla alla konfigurationsfiler i valfritt format, oavsett om det är XML, JSON, YAML eller ett anpassat binärt format.

Åtkomst till konfiguration

Cloud Services

Konfigurationsinställningar från ServiceConfiguration.*.cscfg kan nås via RoleEnvironment. De här inställningarna är globalt tillgängliga för alla rollinstanser i samma molntjänstdistribution.


string value = RoleEnvironment.GetConfigurationSettingValue("Key");

Service Fabric

Varje tjänst har ett eget konfigurationspaket. Det finns ingen inbyggd mekanism för globala konfigurationsinställningar som är tillgängliga för alla program i ett kluster. När du använder Service Fabrics särskilda Settings.xml konfigurationsfil i ett konfigurationspaket kan värden i Settings.xml skrivas över på programnivå, vilket möjliggör konfigurationsinställningar på programnivå.

Konfigurationsinställningar är åtkomster inom varje tjänstinstans via tjänstens CodePackageActivationContext.


ConfigurationPackage configPackage = this.Context.CodePackageActivationContext.GetConfigurationPackageObject("Config");

// Access Settings.xml
KeyedCollection<string, ConfigurationProperty> parameters = configPackage.Settings.Sections["MyConfigSection"].Parameters;

string value = parameters["Key"]?.Value;

// Access custom configuration file:
using (StreamReader reader = new StreamReader(Path.Combine(configPackage.Path, "CustomConfig.json")))
{
    MySettings settings = JsonConvert.DeserializeObject<MySettings>(reader.ReadToEnd());
}

Uppdateringshändelser för konfiguration

Cloud Services

Händelsen RoleEnvironment.Changed används för att meddela alla rollinstanser när en ändring sker i miljön, till exempel en konfigurationsändring. Detta används för att använda konfigurationsuppdateringar utan att återanvända rollinstanser eller starta om en arbetsprocess.


RoleEnvironment.Changed += RoleEnvironmentChanged;

private void RoleEnvironmentChanged(object sender, RoleEnvironmentChangedEventArgs e)
{
   // Get the list of configuration changes
   var settingChanges = e.Changes.OfType<RoleEnvironmentConfigurationSettingChange>();
foreach (var settingChange in settingChanges) 
   {
      Trace.WriteLine("Setting: " + settingChange.ConfigurationSettingName, "Information");
   }
}

Service Fabric

Var och en av de tre pakettyperna i en tjänst – kod, konfiguration och data – har händelser som meddelar en tjänstinstans när ett paket uppdateras, läggs till eller tas bort. En tjänst kan innehålla flera paket av varje typ. En tjänst kan till exempel ha flera konfigurationspaket, var och en individuellt version och uppgraderingsbar.

Dessa händelser är tillgängliga för att använda ändringar i tjänstpaket utan att starta om tjänstinstansen.


this.Context.CodePackageActivationContext.ConfigurationPackageModifiedEvent +=
                    this.CodePackageActivationContext_ConfigurationPackageModifiedEvent;

private void CodePackageActivationContext_ConfigurationPackageModifiedEvent(object sender, PackageModifiedEventArgs<ConfigurationPackage> e)
{
    this.UpdateCustomConfig(e.NewPackage.Path);
    this.UpdateSettings(e.NewPackage.Settings);
}

Startaktiviteter

Startåtgärder är åtgärder som vidtas innan ett program startar. En startuppgift används vanligtvis för att köra installationsskript med utökade privilegier. Både Cloud Services och Service Fabric stöder startaktiviteter. Den största skillnaden är att i Cloud Services är en startaktivitet kopplad till en virtuell dator eftersom den är en del av en rollinstans, medan en startaktivitet i Service Fabric är kopplad till en tjänst som inte är kopplad till någon viss virtuell dator.

Service Fabric Cloud Services
Konfigurationsplats ServiceDefinition.csdef
Behörigheter "begränsad" eller "upphöjd"
Sekvensering "simple", "background", "foreground"

Cloud Services

I Cloud Services konfigureras en startpunkt per roll i ServiceDefinition.csdef.


<ServiceDefinition>
    <Startup>
        <Task commandLine="Startup.cmd" executionContext="limited" taskType="simple" >
            <Environment>
                <Variable name="MyVersionNumber" value="1.0.0.0" />
            </Environment>
        </Task>
    </Startup>
    ...
</ServiceDefinition>

Service Fabric

I Service Fabric konfigureras en startpunkt per tjänst i ServiceManifest.xml:


<ServiceManifest>
  <CodePackage Name="Code" Version="1.0.0">
    <SetupEntryPoint>
      <ExeHost>
        <Program>Startup.bat</Program>
      </ExeHost>
    </SetupEntryPoint>
    ...
</ServiceManifest>

En anteckning om utvecklingsmiljön

Både Cloud Services och Service Fabric är integrerade med Visual Studio med projektmallar och stöd för felsökning, konfiguration och distribution både lokalt och till Azure. Både Cloud Services och Service Fabric tillhandahåller även en lokal utvecklingsmiljö. Skillnaden är att även om cloud service-utvecklingskörningen emulerar Azure-miljön som den körs på, använder Service Fabric inte en emulator – den använder hela Service Fabric-körningen. Service Fabric-miljön som du kör på din lokala utvecklingsdator är samma miljö som körs i produktion.

Nästa steg

Läs mer om Service Fabric Reliable Services och de grundläggande skillnaderna mellan Cloud Services- och Service Fabric-programarkitektur för att förstå hur du kan dra nytta av alla Service Fabric-funktioner.