Handleiding voor het converteren van web- en werkrollen naar stateless Service Fabric-services
In dit artikel wordt beschreven hoe u uw Cloud Services web- 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.
Cloudserviceproject 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. Dit houdt in dat ze elk het volledige pakket definiëren dat wordt 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 toepassingsimplementatie 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, hetzij via een Resource Manager-sjabloon of via de Azure Portal, en er kunnen meerdere Service Fabric-toepassingen op worden geïmplementeerd.
Werkrol voor stateless service
Conceptueel vertegenwoordigt 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 doorgestuurd. Van elk exemplaar wordt niet verwacht dat deze de vorige aanvraag onthoudt. De status waarop de workload wordt uitgevoerd, 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 benadering voor het migreren van een werkrol naar Service Fabric kan worden gedaan door de code van de werkrol te converteren naar een stateless service.
Webrol naar stateless service
Net als bij de werkrol vertegenwoordigt een webrol ook een staatloze workload en kan deze dus ook conceptueel 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 | No | 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 |
|---|---|---|
| Wordt verwerkt | 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 'Uitvoeren'-overschrijving om te beginnen met de verwerking. Service Fabric-services combineren Run, Starten Stop tot één toegangspunt, RunAsync. Uw service moet beginnen te werken wanneer RunAsync wordt gestart en moet stoppen met werken wanneer het Annuleringstoken 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 VM is en dus de levenscyclus is gekoppeld aan de VM, waaronder gebeurtenissen voor wanneer de VM wordt gestart en gestopt. Een Service Fabric-service heeft een levenscyclus die gescheiden is van de levenscyclus van de VM, dus deze bevat geen gebeurtenissen voor wanneer de host-VM of machine wordt gestart en gestopt, omdat deze niet gerelateerd zijn.
- Levensduur: Een exemplaar van de werkrol wordt gerecycled als de
Runmethode wordt afgesloten. DeRunAsyncmethode in een Service Fabric-service kan echter tot voltooiing worden uitgevoerd en het service-exemplaar blijft actief.
Service Fabric biedt een optioneel invoerpunt voor het instellen van communicatie voor services die luisteren naar clientaanvragen. Zowel het RunAsync- als het communicatie-ingangspunt zijn optionele overschrijvingen 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 methode RunAsync worden afgesloten zonder het service-exemplaar opnieuw te starten, omdat deze kan blijven 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 informatie over het knooppunt waarop een service momenteel wordt uitgevoerd.
| Omgevingstaak | Cloudservices | Service Fabric |
|---|---|---|
| Configuratie-instellingen en wijzigingsmeldingen | RoleEnvironment |
CodePackageActivationContext |
| Lokale opslag | RoleEnvironment |
CodePackageActivationContext |
| Eindpuntgegevens | RoleInstance
|
|
| Omgevingsemulatie | RoleEnvironment.IsEmulated |
N.v.t. |
| Gelijktijdige wijzigingsevenement | 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 elke toepassing, in plaats van op een VM, omdat een VM meerdere services en toepassingen kan hosten. Een service bestaat uit drie pakketten:
- Code: bevat de uitvoerbare bestanden van de service, 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 zijn er gebeurtenissen beschikbaar om de service op de hoogte te stellen van een wijziging in het configuratiepakket. Een Settings.xml-bestand kan worden gebruikt voor sleutel-waardeconfiguratie en programmatische toegang, vergelijkbaar 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 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 optreedt 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, Config en Data - heeft 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, die elk afzonderlijk zijn geversied en kunnen worden bijgewerkt.
Deze gebeurtenissen zijn beschikbaar om wijzigingen in servicepakketten te gebruiken zonder het service-exemplaar opnieuw 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 doorgaans gebruikt om installatiescripts uit te voeren met verhoogde bevoegdheden. Zowel Cloud Services als 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 |
| Bevoegdheden | "beperkt" of "verhoogd" |
| 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 een opstartinvoerpunt geconfigureerd per service 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
Zowel Cloud Services als Service Fabric zijn geïntegreerd met Visual Studio met projectsjablonen en ondersteuning voor foutopsporing, configureren en implementeren, zowel lokaal als in Azure. Zowel Cloud Services als Service Fabric bieden ook een lokale ontwikkelruntime-omgeving. Het verschil is dat, hoewel de cloudserviceontwikkelingsruntime de Azure-omgeving emuleren waarop deze wordt uitgevoerd, Service Fabric geen emulator gebruikt, maar 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.