Meer informatie over de verschillen tussen Cloud Services en Service Fabric voordat u toepassingen migreert.
Microsoft Azure Service Fabric is het cloudtoepassingsplatform van de volgende generatie voor zeer schaalbare, zeer betrouwbare gedistribueerde toepassingen. Het introduceert veel nieuwe functies voor het verpakken, implementeren, upgraden en beheren van gedistribueerde cloudtoepassingen.
Dit is een inleidende handleiding voor het migreren van toepassingen van Cloud Services naar Service Fabric. Het richt zich voornamelijk op architectuur- en ontwerpverschillen tussen Cloud Services en Service Fabric.
Toepassingen en infrastructuur
Een fundamenteel verschil tussen Cloud Services en Service Fabric is de relatie tussen VM's, workloads en toepassingen. Een workload wordt hier gedefinieerd als de code die u schrijft om een specifieke taak uit te voeren of een service te leveren.
- Cloud Services gaat over het implementeren van toepassingen als VM's. De code die u schrijft, is nauw gekoppeld aan een VM-exemplaar, zoals een web- of werkrol. Als u een workload in Cloud Services wilt implementeren, moet u een of meer VM-exemplaren implementeren die de workload uitvoeren. Er is geen scheiding van toepassingen en VM's en er is dus geen formele definitie van een toepassing. Een toepassing kan worden beschouwd als een set web- of werkrolexemplaren binnen een Cloud Services-implementatie of als een hele Cloud Services-implementatie. In dit voorbeeld wordt een toepassing weergegeven als een set rolinstanties.
- Service Fabric gaat over het implementeren van toepassingen op bestaande VM's of machines waarop Service Fabric in Windows of Linux wordt uitgevoerd. De services die u schrijft, zijn volledig losgekoppeld van de onderliggende infrastructuur, die wordt geabstraheerd door het Service Fabric-toepassingsplatform, zodat een toepassing kan worden geïmplementeerd in meerdere omgevingen. Een workload in Service Fabric wordt een 'service' genoemd en een of meer services zijn gegroepeerd in een formeel gedefinieerde toepassing die wordt uitgevoerd op het Service Fabric-toepassingsplatform. Er kunnen meerdere toepassingen worden geïmplementeerd in één Service Fabric-cluster.
Service Fabric zelf is een toepassingsplatformlaag die wordt uitgevoerd op Windows of Linux, terwijl Cloud Services een systeem is voor het implementeren van door Azure beheerde VM's met gekoppelde workloads. Het Service Fabric-toepassingsmodel heeft een aantal voordelen:
- Snelle implementatietijden. Het maken van VM-exemplaren kan tijdrovend zijn. In Service Fabric worden VM's slechts eenmaal geïmplementeerd om een cluster te vormen dat als host fungeert voor het Service Fabric-toepassingsplatform. Vanaf dat moment kunnen toepassingspakketten zeer snel in het cluster worden geïmplementeerd.
- Hosting met hoge dichtheid. In Cloud Services fungeert een VM met een werkrol als host voor één workload. In Service Fabric zijn toepassingen gescheiden van de VM's waarop ze worden uitgevoerd, wat betekent dat u een groot aantal toepassingen kunt implementeren op een klein aantal VM's, wat de totale kosten voor grotere implementaties kan verlagen.
- Het Service Fabric-platform kan overal worden uitgevoerd met Windows Server- of Linux-machines, of het nu Azure of on-premises is. Het platform biedt een abstractielaag over de onderliggende infrastructuur, zodat uw toepassing in verschillende omgevingen kan worden uitgevoerd.
- Gedistribueerd toepassingsbeheer. Service Fabric is een platform dat niet alleen als host fungeert voor gedistribueerde toepassingen, maar ook helpt bij het beheren van hun levenscyclus onafhankelijk van de levenscyclus van de host-VM of machine.
Toepassingsarchitectuur
De architectuur van een Cloud Services toepassing bevat meestal talloze externe serviceafhankelijkheden, zoals Service Bus, Azure Table en Blob Storage, SQL, Redis en andere voor het beheren van de status en gegevens van een toepassing en communicatie tussen web- en werkrollen in een Cloud Services-implementatie. Een voorbeeld van een volledige Cloud Services toepassing kan er als volgt uitzien:
Service Fabric-toepassingen kunnen er ook voor kiezen om dezelfde externe services te gebruiken in een volledige toepassing. In dit voorbeeld Cloud Services architectuur is het eenvoudigste migratiepad van Cloud Services naar Service Fabric om alleen de Cloud Services-implementatie te vervangen door een Service Fabric-toepassing, waarbij de algehele architectuur hetzelfde blijft. De web- en werkrollen kunnen worden overgezet naar stateless Service Fabric-services met minimale codewijzigingen.
In dit stadium moet het systeem hetzelfde blijven werken als voorheen. Door gebruik te maken van de stateful functies van Service Fabric kunnen externe statusarchieven, indien van toepassing, worden geïnternaliseerd als stateful services. Dit is meer betrokken dan een eenvoudige migratie van web- en werkrollen naar stateless Service Fabric-services, omdat hiervoor aangepaste services moeten worden geschreven die dezelfde functionaliteit bieden als uw toepassing als de externe services voorheen. De voordelen hiervan zijn onder andere:
- Externe afhankelijkheden verwijderen
- De implementatie-, beheer- en upgrademodellen samenvoegen.
Een voorbeeld van een resulterende architectuur voor het internaliseren van deze services kan er als volgt uitzien:
Communicatie en werkstroom
De meeste cloudservicetoepassingen bestaan uit meer dan één laag. Op dezelfde manier bestaat een Service Fabric-toepassing uit meer dan één service (meestal veel services). Twee algemene communicatiemodellen zijn directe communicatie en via een externe duurzame opslag.
Directe communicatie
Met directe communicatie kunnen lagen rechtstreeks communiceren via eindpunten die door elke laag worden weergegeven. In stateless omgevingen, zoals Cloud Services, betekent dit dat u een exemplaar van een VM-rol selecteert, willekeurig of round robin om de belasting te verdelen, en rechtstreeks verbinding maakt met het eindpunt.
Directe communicatie is een algemeen communicatiemodel in Service Fabric. Het belangrijkste verschil tussen Service Fabric en Cloud Services is dat u in Cloud Services verbinding maakt met een VM, terwijl u in Service Fabric verbinding maakt met een service. Dit is een belangrijk onderscheid om een aantal redenen:
- Services in Service Fabric zijn niet gebonden aan de VM's die als host fungeren; services kunnen zich verplaatsen in het cluster en worden in feite om verschillende redenen verplaatst: resourceverdeling, failover, toepassings- en infrastructuurupgrades en plaatsings- of belastingbeperkingen. Dit betekent dat het adres van een service-exemplaar op elk gewenst moment kan worden gewijzigd.
- Een VM in Service Fabric kan meerdere services hosten, elk met unieke eindpunten.
Service Fabric biedt een mechanisme voor servicedetectie, de naamgevingsservice genoemd, dat kan worden gebruikt om eindpuntadressen van services om te lossen.
Wachtrijen
Een algemeen communicatiemechanisme tussen lagen in staatloze omgevingen, zoals Cloud Services, is het gebruik van een externe opslagwachtrij om werktaken van de ene naar de andere laag duurzaam op te slaan. Een veelvoorkomend scenario is een weblaag die taken verzendt naar een Azure-wachtrij of Service Bus, waar werkrolinstanties de taken uit de wachtrij kunnen verwijderen en verwerken.
Hetzelfde communicatiemodel kan worden gebruikt in Service Fabric. Dit kan handig zijn bij het migreren van een bestaande Cloud Services-toepassing naar Service Fabric.
Parity
Cloud Services is vergelijkbaar met Service Fabric in mate van controle versus gebruiksgemak, maar het is nu een verouderde service en Service Fabric wordt aanbevolen voor nieuwe ontwikkeling. Hier volgt een API-vergelijking:
| CloudService-API | Service Fabric-API | Opmerkingen |
|---|---|---|
| RoleInstance.GetID | FabricRuntime.GetNodeContext.NodeId of . Knooppuntnaam | Id is een eigenschap van de knooppuntnaam |
| RoleInstance.GetFaultDomain | FabricClient.QueryManager.GetNodeList | Filteren op Knooppuntnaam en FD-eigenschap gebruiken |
| RoleInstance.GetUpgradeDomain | FabricClient.QueryManager.GetNodeList | Filter op NodeName en gebruik de eigenschap Upgrade |
| RoleInstance.GetInstanceEndpoints | FabricRuntime.GetActivationContext of Naming (ResolveService) | CodePackageActivationContext die zowel wordt geleverd door FabricRuntime.GetActivationContext als binnen de replica's via ServiceInitializationParameters.CodePackageActivationContext die wordt geleverd tijdens . Initialiseren |
| RoleEnvironment.GetRoles | FabricClient.QueryManager.GetNodeList | Als u hetzelfde soort filters op type wilt uitvoeren, kunt u de lijst met knooppunttypen ophalen uit het clustermanifest via FabricClient.ClusterManager.GetClusterManifest en daar de rol-/knooppunttypen ophalen. |
| RoleEnvironment.GetIsAvailable | Connect-WindowsFabricCluster of maak een FabricRuntime die wees naar een bepaald knooppunt | * |
| RoleEnvironment.GetLocalResource | CodePackageActivationContext.Log/Temp/Work | * |
| RoleEnvironment.GetCurrentRoleInstance | CodePackageActivationContext.Log/Temp/Work | * |
| LocalResource.GetRootPath | CodePackageActivationContext.Log/Temp/Work | * |
| Role.GetInstances | FabricClient.QueryManager.GetNodeList of ResolveService | * |
| RoleInstanceEndpoint.GetIPEndpoint | FabricRuntime.GetActivationContext of Naming (ResolveService) | * |
Volgende stappen
Het eenvoudigste migratiepad van Cloud Services naar Service Fabric is om alleen de Cloud Services-implementatie te vervangen door een Service Fabric-toepassing, waarbij de algehele architectuur van uw toepassing ongeveer hetzelfde blijft. Het volgende artikel bevat een handleiding voor het converteren van een web- of werkrol naar een stateless Service Fabric-service.