Handleiding voor het converteren van web- en werkrollen naar stateless Service Fabric-services
In dit artikel wordt beschreven hoe u uw cloudservicesweb- en werkrollen migreert naar stateless Service Fabric-services. Dit is het eenvoudigste migratiepad van Cloud Services naar Service Fabric voor toepassingen waarvan de algehele architectuur ongeveer hetzelfde blijft.
Cloud Service-project naar Service Fabric-toepassingsproject
Een Cloud Service-project en een Service Fabric-toepassingsproject hebben een vergelijkbare structuur en vertegenwoordigen beide de implementatie-eenheid voor uw toepassing. Dat wil gezegd, ze definiëren elk het volledige pakket dat is geïmplementeerd om uw toepassing uit te voeren. Een cloudserviceproject bevat een of meer web- of werkrollen. Op dezelfde manier bevat een Service Fabric-toepassingsproject een of meer services.
Het verschil is dat het Cloud Service-project de implementatie van de toepassing koppelt aan een VM-implementatie en dus VM-configuratie-instellingen bevat, terwijl het Service Fabric-toepassingsproject alleen een toepassing definieert die wordt geïmplementeerd op een set bestaande VM's in een Service Fabric-cluster. Het Service Fabric-cluster zelf wordt slechts eenmaal geïmplementeerd, via een Resource Manager-sjabloon of via Azure Portal en er kunnen meerdere Service Fabric-toepassingen op worden geïmplementeerd.
Werkrol voor stateless service
Conceptueel is een werkrol een staatloze workload, wat betekent dat elk exemplaar van de workload identiek is en aanvragen op elk gewenst moment naar elk exemplaar kunnen worden gerouteerd. Voor elk exemplaar wordt niet verwacht dat de vorige aanvraag wordt onthouden. De status waarop de workload werkt, wordt beheerd door een extern statusarchief, zoals Azure Table Storage of Azure Cosmos DB. In Service Fabric wordt dit type workload vertegenwoordigd door een stateless service. De eenvoudigste methode voor het migreren van een werkrol naar Service Fabric kan worden uitgevoerd door werkrolcode te converteren naar een stateless service.
Webrol naar stateless service
Net als bij werkrol vertegenwoordigt een webrol ook een staatloze werkbelasting. Conceptueel kan deze ook worden toegewezen aan een stateless Service Fabric-service. In tegenstelling tot webrollen biedt Service Fabric echter geen ondersteuning voor IIS. Als u een webtoepassing wilt migreren van een webrol naar een staatloze service, moet u eerst overstappen op een webframework dat zelf kan worden gehost en niet afhankelijk is van IIS of System.Web, zoals ASP.NET Core 1.
Toepassing | Ondersteund | Migratiepad |
---|---|---|
ASP.NET Web Forms | Nee | Converteren naar ASP.NET Core 1 MVC |
ASP.NET MVC | Met migratie | Upgraden naar ASP.NET Core 1 MVC |
ASP.NET Web-API | Met migratie | Zelf-hostende server of ASP.NET Core 1 gebruiken |
ASP.NET Core 1 | Ja | N.v.t. |
Toegangspunt-API en levenscyclus
Werkrol- en Service Fabric-service-API's bieden vergelijkbare toegangspunten:
Toegangspunt | Werkrol | Service Fabric-service |
---|---|---|
Verwerken | Run() |
RunAsync() |
VM starten | OnStart() |
N.v.t. |
VM-stop | OnStop() |
N.v.t. |
Listener openen voor clientaanvragen | N.v.t. |
|
Werkrol
using Microsoft.WindowsAzure.ServiceRuntime;
namespace WorkerRole1
{
public class WorkerRole : RoleEntryPoint
{
public override void Run()
{
}
public override bool OnStart()
{
}
public override void OnStop()
{
}
}
}
Service Fabric Stateless Service
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)
{
}
}
}
Beide hebben een primaire 'Run'-overschrijving waarin de verwerking moet worden gestart. Service Fabric-services combineren Run
, Start
en Stop
tot één toegangspunt, RunAsync
. Uw service moet beginnen wanneer RunAsync
deze wordt gestart en moet stoppen met werken wanneer het CancellationToken van de RunAsync
methode wordt gesignaleerd.
Er zijn verschillende belangrijke verschillen tussen de levenscyclus en levensduur van werkrollen en Service Fabric-services:
- Levenscyclus: Het grootste verschil is dat een werkrol een VIRTUELE machine is en dat de levenscyclus is gekoppeld aan de VIRTUELE machine, waaronder gebeurtenissen voor wanneer de VIRTUELE machine wordt gestart en gestopt. Een Service Fabric-service heeft een levenscyclus die losstaat van de levenscyclus van de VIRTUELE machine, zodat deze geen gebeurtenissen bevat voor wanneer de host-VM of -machine wordt gestart en gestopt, omdat deze niet zijn gerelateerd.
- Levensduur: Een exemplaar van een werkrol wordt gerecycled als de
Run
methode wordt afgesloten. DeRunAsync
methode in een Service Fabric-service kan echter worden uitgevoerd tot voltooiing en het service-exemplaar blijft actief.
Service Fabric biedt een optioneel invoerpunt voor communicatie-instellingen voor services die luisteren naar clientaanvragen. Zowel het RunAsync- als het communicatieinvoerpunt zijn optionele onderdrukkingen in Service Fabric-services. Uw service kan ervoor kiezen om alleen naar clientaanvragen te luisteren of alleen een verwerkingslus uit te voeren, of beide. Daarom mag de RunAsync-methode worden afgesloten zonder het service-exemplaar opnieuw op te starten, omdat deze mogelijk blijft luisteren naar clientaanvragen.
Toepassings-API en omgeving
De Cloud Services-omgevings-API biedt informatie en functionaliteit voor het huidige VM-exemplaar, evenals informatie over andere VM-rolinstanties. Service Fabric biedt informatie met betrekking tot de runtime en enkele informatie over het knooppunt waarop een service momenteel wordt uitgevoerd.
Omgevingstaak | Cloud Services | Service Fabric |
---|---|---|
Configuratie-instellingen en melding wijzigen | RoleEnvironment |
CodePackageActivationContext |
Lokale opslag | RoleEnvironment |
CodePackageActivationContext |
Eindpuntinformatie | RoleInstance
|
|
Omgeving emulatie | RoleEnvironment.IsEmulated |
N.v.t. |
Gelijktijdige wijzigings gebeurtenis | RoleEnvironment |
N.v.t. |
Configuratie-instellingen
Configuratie-instellingen in Cloud Services zijn ingesteld voor een VM-rol en zijn van toepassing op alle exemplaren van die VM-rol. Deze instellingen zijn sleutel-waardeparen die zijn ingesteld in ServiceConfiguration.*.cscfg-bestanden en kunnen rechtstreeks worden geopend via RoleEnvironment. In Service Fabric zijn instellingen afzonderlijk van toepassing op elke service en op elke toepassing, in plaats van op een VM, omdat een VIRTUELE machine meerdere services en toepassingen kan hosten. Een service bestaat uit drie pakketten:
- Code: bevat de uitvoerbare servicebestanden, binaire bestanden, DLL's en andere bestanden die een service moet uitvoeren.
- Configuratie: alle configuratiebestanden en -instellingen voor een service.
- Gegevens: statische gegevensbestanden die zijn gekoppeld aan de service.
Elk van deze pakketten kan onafhankelijk van elkaar worden geversied en bijgewerkt. Net als bij Cloud Services kan een configuratiepakket programmatisch worden geopend via een API en gebeurtenissen zijn beschikbaar om de service te informeren over een wijziging in het configuratiepakket. Een Settings.xml-bestand kan worden gebruikt voor sleutelwaardeconfiguratie en programmatische toegang die vergelijkbaar is met de sectie app-instellingen van een App.config-bestand. In tegenstelling tot Cloud Services kan een Service Fabric-configuratiepakket echter configuratiebestanden in elke indeling bevatten, ongeacht of het XML, JSON, YAML of een aangepaste binaire indeling is.
Toegang tot configuratie
Cloud Services
Configuratie-instellingen van ServiceConfiguration.*.cscfg zijn toegankelijk via RoleEnvironment
. Deze instellingen zijn wereldwijd beschikbaar voor alle rolinstanties in dezelfde cloudservice-implementatie.
string value = RoleEnvironment.GetConfigurationSettingValue("Key");
Service Fabric
Elke service heeft een eigen afzonderlijk configuratiepakket. Er is geen ingebouwd mechanisme voor globale configuratie-instellingen die toegankelijk zijn voor alle toepassingen in een cluster. Wanneer u het speciale Settings.xml configuratiebestand van Service Fabric in een configuratiepakket gebruikt, kunnen waarden in Settings.xml worden overschreven op toepassingsniveau, waardoor configuratie-instellingen op toepassingsniveau mogelijk zijn.
Configuratie-instellingen zijn toegankelijk binnen elk service-exemplaar via de service 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());
}
Gebeurtenissen voor configuratie-updates
Cloud Services
De RoleEnvironment.Changed
gebeurtenis wordt gebruikt om alle rolinstanties op de hoogte te stellen wanneer er een wijziging plaatsvindt in de omgeving, zoals een configuratiewijziging. Dit wordt gebruikt om configuratie-updates te gebruiken zonder rolinstanties te recyclen of een werkproces opnieuw te starten.
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
Elk van de drie pakkettypen in een service, code, configuratie en gegevens, bevatten gebeurtenissen die een service-exemplaar waarschuwen wanneer een pakket wordt bijgewerkt, toegevoegd of verwijderd. Een service kan meerdere pakketten van elk type bevatten. Een service kan bijvoorbeeld meerdere configuratiepakketten hebben, elk afzonderlijk versiebeheer en kan worden bijgewerkt.
Deze gebeurtenissen zijn beschikbaar om wijzigingen in servicepakketten te gebruiken zonder het service-exemplaar opnieuw op te starten.
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);
}
Opstarttaken
Opstarttaken zijn acties die worden uitgevoerd voordat een toepassing wordt gestart. Een opstarttaak wordt meestal gebruikt om installatiescripts uit te voeren met verhoogde bevoegdheden. Cloud Services en Service Fabric ondersteunen opstarttaken. Het belangrijkste verschil is dat in Cloud Services een opstarttaak is gekoppeld aan een VIRTUELE machine omdat deze deel uitmaakt van een rolinstantie, terwijl in Service Fabric een opstarttaak is gekoppeld aan een service, die niet is gekoppeld aan een bepaalde VM.
Service Fabric | Cloud Services |
---|---|
Configuratielocatie | ServiceDefinition.csdef |
Rechten | "beperkt" of "verhoogde" |
Sequentiëren | "simple", "background", "foreground" |
Cloud Services
In Cloud Services wordt een opstartinvoerpunt geconfigureerd per rol in 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
In Service Fabric wordt per service een opstartinvoerpunt geconfigureerd in ServiceManifest.xml:
<ServiceManifest>
<CodePackage Name="Code" Version="1.0.0">
<SetupEntryPoint>
<ExeHost>
<Program>Startup.bat</Program>
</ExeHost>
</SetupEntryPoint>
...
</ServiceManifest>
Een opmerking over de ontwikkelomgeving
Cloud Services en Service Fabric zijn geïntegreerd met Visual Studio met projectsjablonen en ondersteuning voor foutopsporing, configuratie en implementatie van zowel lokaal als in Azure. Cloud Services en Service Fabric bieden ook een lokale runtime-omgeving voor ontwikkeling. Het verschil is dat Service Fabric geen emulator gebruikt, terwijl de Cloud Service Development Runtime de Azure-omgeving emuleren waarop deze wordt uitgevoerd. Hierbij wordt gebruikgemaakt van de volledige Service Fabric-runtime. De Service Fabric-omgeving die u uitvoert op uw lokale ontwikkelcomputer is dezelfde omgeving die in productie wordt uitgevoerd.
Volgende stappen
Lees meer over Service Fabric Reliable Services en de fundamentele verschillen tussen Cloud Services en Service Fabric-toepassingsarchitectuur om te begrijpen hoe u kunt profiteren van de volledige set Service Fabric-functies.