Een Azure Cloud Services migreren naar Azure Service Fabric

Voorbeeldcode van

In dit artikel wordt beschreven hoe u een toepassing migreert van Azure Cloud Services naar Azure Service Fabric. Het richt zich op beslissingen over de architectuur en aanbevolen procedures.

Voor dit project zijn we begonnen met een Cloud Services met de naam Surveys en deze overgeplaatst naar Service Fabric. Het doel was om de toepassing te migreren met zo weinig mogelijk wijzigingen. Verder in het artikel laten we zien hoe u de toepassing kunt optimaliseren voor Service Fabric.

Voordat u dit artikel leest, is het handig om de basisbeginselen van Service Fabric. Zie Overzicht van Azure Service Fabric

Over de toepassing Surveys

Een fictief bedrijf met de naam Tailspin heeft een toepassing gemaakt met de naam enquêtes-app waarmee klanten enquêtes kunnen maken. Nadat een klant zich heeft voor de toepassing, kunnen gebruikers enquêtes maken en publiceren en de resultaten verzamelen voor analyse. De toepassing bevat een openbare website waar mensen een enquête kunnen doen. Lees hier meer over het oorspronkelijke Tailspin-scenario.

Nu wil Tailspin de toepassing Surveys verplaatsen naar een microservicesarchitectuur, met behulp van Service Fabric uitgevoerd in Azure. Omdat de toepassing al is geïmplementeerd als een Cloud Services toepassing, gaat Tailspin uit van een benadering met meerdere fasen:

1. De cloudservices over te brengen naar Service Fabric, terwijl wijzigingen in de toepassing worden geminim hetzelfde.
2. Optimaliseer de toepassing voor Service Fabric, door over te gaan op een microservicesarchitectuur.

In een echt project is het waarschijnlijk dat beide fasen elkaar overlappen. Tijdens het over Service Fabric, begint u ook met het opnieuw in de architectuur van de toepassing in microservices. Later kunt u de architectuur verder verfijnen, mogelijk door coarse-grain services te verdelen in kleinere services.

De toepassingscode is beschikbaar op GitHub. Deze repo bevat zowel de Cloud Services als de Service Fabric versie.

Waarom Service Fabric?

Service Fabric is geschikt voor dit project, omdat de meeste functies die nodig zijn in een gedistribueerd systeem zijn ingebouwd in Service Fabric, waaronder:

• Clusterbeheer. Service Fabric verwerkt automatisch failover van knooppunt, statuscontrole en andere functies voor clusterbeheer.
• Horizontaal schalen. Wanneer u knooppunten toevoegt aan Service Fabric cluster, wordt de toepassing automatisch geschaald, omdat services worden verdeeld over de nieuwe knooppunten.
• Servicedetectie. Service Fabric bevat een detectieservice waarmee het eindpunt voor een benoemde service kan worden omgezet.
• Staatloze en stateful services. Stateful services maken gebruik van betrouwbare verzamelingen, die de plaats van een cache of wachtrij kunnen in nemen en kunnen worden gepartitief.
• Levenscyclusbeheer van toepassingen. Services kunnen onafhankelijk en zonder uitvaltijd van de toepassing worden bijgewerkt.
• Service-orchestration voor een cluster van machines.
• Hogere dichtheid voor het optimaliseren van resourceverbruik. Eén knooppunt kan meerdere services hosten.

Service Fabric wordt gebruikt door verschillende Microsoft-services, waaronder Azure SQL Database, Cosmos DB, Azure Event Hubs en andere, waardoor het een bewezen platform is voor het bouwen van gedistribueerde cloudtoepassingen.

Vergelijking van Cloud Services met Service Fabric

De volgende tabel bevat een overzicht van enkele van de belangrijke verschillen tussen Cloud Services en Service Fabric toepassingen. Zie Learn about the differences between Cloud Services and Service Fabric before migrating applications(Meer informatie over de verschillen tussen Cloud Services en Service Fabric migratie van toepassingen).

* Stateful services maken gebruik van betrouwbare verzamelingen voor het opslaan van statussen op replica's, zodat alle leesingen lokaal zijn voor de knooppunten in het cluster. Schrijf schrijven wordt gerepliceerd tussen knooppunten voor betrouwbaarheid. Staatloze services kunnen een externe status hebben, met behulp van een database of andere externe opslag.

** Werkrollen kunnen ook een web-API ASP.NET hosten met behulp van OWIN.

De toepassing Surveys op Cloud Services

In het volgende diagram ziet u de architectuur van de toepassing Surveys die wordt uitgevoerd op Cloud Services.

De toepassing bestaat uit twee webrollen en een werkrol.

• De tailspin.webrol host een ASP.NET website die Tailspin-klanten gebruiken om enquêtes te maken en te beheren. Klanten gebruiken deze website ook om zich te registreren voor de toepassing en hun abonnementen te beheren. Tot slot kunnen Tailspin-beheerders deze gebruiken om de lijst met tenants te bekijken en tenantgegevens te beheren.

• De webrol Tailspin.Web.Survey.Public host een ASP.NET website waar mensen de enquêtes kunnen volgen die Tailspin-klanten publiceren.

• De werkrol Tailspin.Workers.Survey verwerkt de achtergrond. De webrollen zetten werkitems in een wachtrij en de werkrol verwerkt de items. Er zijn twee achtergrondtaken gedefinieerd: Enquête-antwoorden exporteren naar Azure SQL Database en statistieken berekenen voor enquête-antwoorden.

Naast de Cloud Services maakt de toepassing Surveys gebruik van enkele andere Azure-services:

• Azure Storage voor het opslaan van enquêtes, enquête-antwoorden en tenantinformatie.

• Azure Cache voor Redis om een deel van de gegevens die zijn opgeslagen in de cache Azure Storage voor snellere leestoegang.

• Azure Active Directory (Azure AD) om klanten en Tailspin-beheerders te verifiëren.

• Azure SQL Database de enquête-antwoorden voor analyse op te slaan.

Verplaatsen naar Service Fabric

Zoals vermeld, was het doel van deze fase migreren naar Service Fabric met de minimaal benodigde wijzigingen. Daarom hebben we stateless services gemaakt die overeenkomen met elke cloudservicerol in de oorspronkelijke toepassing:

Deze architectuur is opzettelijk vergelijkbaar met de oorspronkelijke toepassing. In het diagram worden echter enkele belangrijke verschillen verborgen. In de rest van dit artikel gaan we deze verschillen verkennen.

De cloudservicerollen converteren naar services

Voor de eerste migratie heeft Tailspin de stappen gevolgd die worden beschreven in Guide to converting Web and Worker Roles to Service Fabric stateless services(Handleiding voor het converteren van web- en werkrollen naar Service Fabric stateless services).

De webfront-endservices maken

In Service Fabric wordt een service uitgevoerd binnen een proces dat is gemaakt door de Service Fabric runtime. Voor een webfront-end betekent dit dat de service niet wordt uitgevoerd in IIS. In plaats daarvan moet de service een webserver hosten. Deze methode wordt zelf-hostend genoemd, omdat de code die in het proces wordt uitgevoerd, fungeert als de webserverhost.

De oorspronkelijke surveys-toepassing maakt gebruik van ASP.NET MVC. Omdat ASP.NET MVC niet zelf-hostend kan zijn in Service Fabric, heeft Tailspin rekening gehouden met de volgende migratieopties:

• Poort de webrollen naar ASP.NET Core, die zelf-hostend kunnen zijn.
• Converteert de website naar een toepassing met één pagina (SPA) die een web-API aanroept die is geïmplementeerd met behulp ASP.NET Web API. Hiervoor zou de web-front-end volledig opnieuw moeten worden ontworpen.
• Bewaar de bestaande ASP.NET MVC-code en implementeer IIS in een Windows Server-container voor Service Fabric. Deze aanpak vereist weinig of geen codewijziging.

Met de eerste optie, porting naar ASP.NET Core, kon Tailspin profiteren van de nieuwste functies in ASP.NET Core. Om de conversie uit te voeren, heeft Tailspin de stappen gevolgd die worden beschreven in Migreren van ASP.NET MVC naar ASP.NET Core MVC.

HTTP-listeners

In Cloud Services een web- of werkrol een HTTP-eindpunt blootstellen door dit te declareren in het servicedefinitiebestand. Een webrol moet ten minste één eindpunt hebben.

<!-- Cloud service endpoint -->
<Endpoints>
    <InputEndpoint name="HttpIn" protocol="http" port="80" />
</Endpoints>

Op dezelfde manier Service Fabric eindpunten worden gedeclareerd in een servicemanifest:

<!-- Service Fabric endpoint -->
<Endpoints>
    <Endpoint Protocol="http" Name="ServiceEndpoint" Type="Input" Port="8002" />
</Endpoints>

In tegenstelling tot een cloudservicerol kunnen Service Fabric binnen hetzelfde knooppunt worden opgeslagen. Daarom moet elke service op een afzonderlijke poort luisteren. Verder in dit artikel wordt besproken hoe clientaanvragen op poort 80 of poort 443 worden gerouteerd naar de juiste poort voor de service.

Een service moet expliciet listeners maken voor elk eindpunt. De reden hiervoor is Service Fabric communicatiestacks agnostisch zijn. Zie Build a web service front end for your application using ASP.NET Core (Een webservicefront-endvoor uw toepassing bouwen met behulp van ASP.NET Core).

Verpakking en configuratie

Een cloudservice bevat de volgende configuratie- en pakketbestanden:

Er is één CSDEF-bestand voor de hele toepassing. U kunt meerdere CSCFG-bestanden hebben voor verschillende omgevingen, zoals lokaal, test of productie. Wanneer de service wordt uitgevoerd, kunt u de .cscfg bijwerken, maar niet de .csdef. Zie Wat is het cloudservicemodel en hoe kan ik het verpakken? voor meer informatie.

Service Fabric heeft een vergelijkbare deling tussen een servicedefinitie en service-instellingen, maar de structuur is gedetailleerder. Als u Service Fabric configuratiemodel van een toepassing wilt begrijpen, helpt het om te begrijpen hoe een Service Fabric toepassing wordt verpakt. Dit is de structuur:

Application package
  - Service packages
    - Code package
    - Configuration package
    - Data package (optional)

Het toepassingspakket is wat u implementeert. Het bevat een of meer servicepakketten. Een servicepakket bevat code-, configuratie- en gegevenspakketten. Het codepakket bevat de binaire bestanden voor de services en het configuratiepakket bevat configuratie-instellingen. Met dit model kunt u afzonderlijke services upgraden zonder dat u de hele toepassing opnieuw kunt uitvoeren. U kunt hiermee ook alleen de configuratie-instellingen bijwerken, zonder de code opnieuw te moeten uitvoeren of de service opnieuw te starten.

Een Service Fabric bevat de volgende configuratiebestanden:

Zie Een toepassing modelleren in Service Fabricvoor meer Service Fabric.

Als u verschillende configuratie-instellingen voor meerdere omgevingen wilt ondersteunen, gebruikt u de volgende benadering, zoals beschreven in Toepassingsparameters voor meerdere omgevingen beheren:

1. Definieer de instelling in Setting.xml bestand voor de service.
2. Definieer in het toepassingsmanifest een override voor de instelling.
3. Plaats omgevingsspecifieke instellingen in toepassingsparameterbestanden.

De toepassing implementeren

Hoewel Azure Cloud Services een beheerde service is, Service Fabric een runtime. U kunt clusters Service Fabric in veel omgevingen, waaronder Azure en on-premises. In het volgende diagram ziet u een aanbevolen implementatie voor Azure:

Het Service Fabric cluster wordt geïmplementeerd in een virtuele-machineschaalset. Schaalsets zijn een Azure Compute resource die kan worden gebruikt voor het implementeren en beheren van een set identieke VM's.

Zoals vermeld, is het om veiligheidsredenen raadzaam om de Kestrel-webserver achter een omgekeerde proxy te plaatsen. In dit diagram Azure Application Gateway,een Azure-service die verschillende mogelijkheden voor taakverdeling op laag 7 biedt. Deze service fungeert als een omgekeerde proxyservice, beëindigt de clientverbinding en stuurt aanvragen door naar back-endeindpunten. U kunt een andere omgekeerde proxyoplossing gebruiken, zoals nginx.

Laag 7-routering

In de oorspronkelijke surveys-toepassingluistert één webrol op poort 80 en de andere webrol op poort 443.

Een andere optie is om laag 7-routering te gebruiken. Bij deze aanpak worden verschillende URL-paden gerouteerd naar verschillende poortnummers op de back-end. De openbare site kan bijvoorbeeld URL-paden gebruiken die beginnen met /public/ .

Opties voor routering op laag 7 zijn onder andere:

• Gebruik Application Gateway.
• Gebruik een virtueel netwerkapparaat (NVA), zoals nginx.
• Schrijf een aangepaste gateway als stateless service.

Overweeg deze methode als u twee of meer services met openbare HTTP-eindpunten hebt, maar u wilt dat deze worden weergegeven als één site met één domeinnaam.

Een aanpak die niet wordt aanbevolen, is externe clients toe te staan aanvragen te verzenden via de omgekeerde proxy Service Fabric. Hoewel dit mogelijk is, is de omgekeerde proxy bedoeld voor service-naar-service-communicatie. Als u de service opent voor externe clients, wordt elke service die wordt uitgevoerd in het cluster met een HTTP-eindpunt, geopend.

Beperkingen voor knooppunttypen en plaatsing

In de hierboven weergegeven implementatie worden alle services uitgevoerd op alle knooppunten. U kunt echter ook services groeperen, zodat bepaalde services alleen worden uitgevoerd op bepaalde knooppunten in het cluster. Redenen om deze methode te gebruiken zijn onder andere:

• Sommige services uitvoeren op verschillende VM-typen. Sommige services kunnen bijvoorbeeld rekenintensief zijn of GPU's vereisen. U kunt een combinatie van VM-typen in uw Service Fabric cluster.
• Om veiligheidsredenen front-endservices isoleren van back-endservices. Alle front-endservices worden uitgevoerd op één set knooppunten en de back-endservices worden uitgevoerd op verschillende knooppunten in hetzelfde cluster.
• Verschillende schaalvereisten. Sommige services moeten mogelijk worden uitgevoerd op meer knooppunten dan andere services. Als u bijvoorbeeld front-endknooppunten en back-endknooppunten definieert, kan elke set onafhankelijk worden geschaald.

In het volgende diagram ziet u een cluster dat front-end- en back-endservices van elkaar scheidt:

Deze aanpak implementeren:

1. Wanneer u het cluster maakt, definieert u twee of meer knooppunttypen.
2. Gebruik voor elke service plaatsingsbeperkingen om de service toe te wijzen aan een knooppunttype.

Wanneer u implementeert in Azure, wordt elk knooppunttype geïmplementeerd in een afzonderlijke virtuele-machineschaalset. Het Service Fabric cluster omvat alle knooppunttypen. Zie De relatie tussen de knooppunttypen Service Fabric virtuele-machineschaalsets voor meer informatie.

Als een cluster meerdere knooppunttypen heeft, wordt één knooppunttype aangewezen als het primaire knooppunttype. Service Fabric runtimeservices, zoals de clusterbeheerservice, worden uitgevoerd op het primaire knooppunttype. Inrichting van ten minste 5 knooppunten voor het primaire knooppunttype in een productieomgeving. Het andere knooppunttype moet ten minste twee knooppunten hebben.

Het cluster configureren en beheren

Clusters moeten worden beveiligd om te voorkomen dat onbevoegde gebruikers verbinding maken met uw cluster. Het wordt aanbevolen Azure AD te gebruiken voor het verifiëren van clients en X.509-certificaten voor beveiliging van knooppunt naar knooppunt. Zie Scenario's voor beveiliging van Service Fabric-cluster voor meer informatie.

Zie Resources opgeven in een servicemanifest voor het configureren van een openbaar HTTPS-eindpunt.

U kunt de toepassing uitschalen door VM's toe te voegen aan het cluster. Virtuele-machineschaalsets ondersteunen automatisch schalen met behulp van regels voor automatisch schalen op basis van prestatiemeters. Zie Scale a Service Fabric cluster in or out using autoscale rules (Een cluster in- Service Fabric uitschalen met behulp van regels voor automatisch schalen) voor meer informatie.

Terwijl het cluster wordt uitgevoerd, verzamelt u logboeken van alle knooppunten op een centrale locatie. Zie Logboeken verzamelen met behulp van Azure Diagnostics voor meer Azure Diagnostics.

De toepassing herstructureren

Nadat de toepassing is overgeplaatst naar Service Fabric, bestaat de volgende stap uit het herbouwen van de toepassing naar een gedetailleerdere architectuur. Tailspin's motivatie voor herfactoring is om het eenvoudiger te maken om de surveys-toepassing te ontwikkelen, bouwen en implementeren. Door de bestaande web- en werkrollen op te delen in een meer gedetailleerde architectuur, wil Tailspin de bestaande nauw gekoppelde communicatie- en gegevensafhankelijkheden tussen deze rollen verwijderen.

Tailspin ziet andere voordelen bij het verplaatsen van de toepassing Surveys naar een gedetailleerdere architectuur:

• Elke service kan worden verpakt in onafhankelijke projecten met een bereik dat klein genoeg is om te worden beheerd door een klein team.
• Elke service kan onafhankelijk worden geversiereerd en geïmplementeerd.
• Elke service kan worden geïmplementeerd met behulp van de beste technologie voor die service. Een Service Fabric-cluster kan bijvoorbeeld services bevatten die zijn gebouwd met behulp van verschillende versies van .Net Frameworks, Java of andere talen, zoals C of C++.
• Elke service kan onafhankelijk worden geschaald om te reageren op toenamen en afname van de belasting.

De broncode voor de gefactoreerde versie van de app is beschikbaar op GitHub.

Overwegingen bij het ontwerpen

In het volgende diagram ziet u de architectuur van de toepassing Surveys die is gefactoreerd naar een gedetailleerdere architectuur:

Tailspin.Web is een stateless service zelf-hostend een ASP.NET MVC-toepassing die Tailspin-klanten bezoeken om enquêtes te maken en enquêteresultaten weer te geven. Deze service deelt het grootste deel van de code met de Tailspin.Web-service van de gepoorte Service Fabric toepassing. Zoals eerder vermeld, maakt deze service gebruik ASP.NET core en schakelt over van het gebruik van Kestrel als webfront-end naar het implementeren van een WebListener.

Tailspin.Web.Survey.Public is een stateless service zelf-hosten van een ASP.NET MVC-site. Gebruikers gaan naar deze site om enquêtes in een lijst te selecteren en deze vervolgens in te vullen. Deze service deelt de meeste code met de Tailspin.Web.Survey.Public-service van de gepoorte Service Fabric toepassing. Deze service maakt ook gebruik ASP.NET Core en schakelt ook over van het gebruik van Kestrel als webfront-end naar het implementeren van een WebListener.

Tailspin.SurveyResponseService is een stateful service waarin enquête-antwoorden worden opgeslagen in Azure Blob Storage. Ook worden antwoorden samengevoegd in de analysegegevens van de enquête. De service wordt geïmplementeerd als een stateful service omdat deze een ReliableConcurrentQueue gebruikt om enquête-antwoorden in batches te verwerken. Deze functionaliteit is oorspronkelijk geïmplementeerd in de Tailspin.AnswerAnalysisService-service in de gepoorte Service Fabric toepassing.

Tailspin.SurveyManagementService is een stateless service die enquêtes en enquêtes opvraagt en opvraagt. De service maakt gebruik van Azure Blob Storage. Deze functionaliteit is oorspronkelijk ook geïmplementeerd in de gegevenstoegangsonderdelen van de Tailspin.Web- en Tailspin.Web.Survey.Public-services in de gepoorte Service Fabric toepassing. Tailspin heeft de oorspronkelijke functionaliteit in deze service geschaald zodat deze onafhankelijk kan worden geschaald.

Tailspin.SurveyAnswerService is een stateless service die enquêteantwoorden en enquêteanalyses opvraagt. De service maakt ook gebruik van Azure Blob Storage. Deze functionaliteit is ook oorspronkelijk geïmplementeerd in de gegevenstoegangsonderdelen van de Tailspin.Web-service in de gepoorte Service Fabric toepassing. Tailspin heeft de oorspronkelijke functionaliteit in deze service gefactoreerd omdat er minder belasting wordt verwacht en er minder exemplaren moeten worden gebruikt om resources te besparen.

Tailspin.SurveyAnalysisService is een stateless service die samenvattingsgegevens van enquêteantwoorden ophoudt in een Redis-cache om snel op te halen. Deze service wordt aangeroepen door de Tailspin.SurveyResponseService telkens als een enquête wordt beantwoord en de nieuwe enquêteantwoordgegevens worden samengevoegd in de samenvattingsgegevens. Deze service bevat de functionaliteit die oorspronkelijk is geïmplementeerd in de Tailspin.AnswerAnalysisService-service van de gepoorte Service Fabric toepassing.

Staatloze versus stateful services

Azure Service Fabric ondersteunt de volgende programmeermodellen:

• Met het uitvoerbare gastmodel kan elk uitvoerbaar bestand als een service worden verpakt en geïmplementeerd in een Service Fabric cluster. Service Fabric beheert en beheert de uitvoering van het uitvoerbare gast-bestand.
• Met het containermodel kunnen services in containerafbeeldingen worden geïmplementeerd. Service Fabric ondersteunt het maken en beheren van containers boven op Linux-kernelcontainers en Windows Server-containers.
• Met het reliable services-programmeermodel kunt u staatloze of stateful services maken die kunnen worden geïntegreerd met alle Service Fabric platformfuncties. Stateful services maken het mogelijk om de gerepliceerde status op te slaan in Service Fabric cluster. Staatloze services doen dat niet.
• Het reliable actors-programmeermodel maakt het mogelijk om services te maken waarmee het virtual actor-patroon wordt geïmplementeerd.

Alle services in de toepassing Surveys zijn staatloze betrouwbare services, met uitzondering van de Tailspin.SurveyResponseService-service. Deze service implementeert een ReliableConcurrentQueue om enquête-antwoorden te verwerken wanneer deze worden ontvangen. Antwoorden in reliableConcurrentQueue worden opgeslagen in Azure Blob Storage en doorgegeven aan tailspin.SurveyAnalysisService voor analyse. Tailspin kiest een ReliableConcurrentQueue omdat voor antwoorden geen strikte FIFO-volgorde (First-In-First Out) is vereist die wordt geleverd door een wachtrij zoals Azure Service Bus. Een ReliableConcurrentQueue is ook ontworpen om een hoge doorvoer en lage latentie te leveren voor wachtrij- en uit wachtrij- en uit wachtrijen verwijderde bewerkingen.

Bewerkingen voor het persistent maken van verwijderde items uit een ReliableConcurrentQueue moeten idealiter idempotent zijn. Als er een uitzondering wordt gemaakt tijdens de verwerking van een item uit de wachtrij, kan hetzelfde item meer dan één keer worden verwerkt. In de toepassing Surveys is de bewerking om enquête-antwoorden samen te voegen met de Tailspin.SurveyAnalysisService niet idempotent omdat Tailspin heeft besloten dat de analysegegevens van de enquête slechts een huidige momentopname van de analysegegevens zijn en niet consistent hoeven te zijn. De enquête-antwoorden die zijn opgeslagen in Azure Blob Storage uiteindelijk consistent zijn, zodat de definitieve analyse van de enquête altijd correct kan worden berekend op basis van deze gegevens.

Communicatiekader

Elke service in de toepassing Surveys communiceert met behulp van een RESTful-web-API. RESTful API's bieden de volgende voordelen:

• Gebruiksgemak: elke service wordt gebouwd met behulp van ASP.NET Core MVC, dat standaard ondersteuning biedt voor het maken van web-API's.
• Beveiliging: Hoewel voor elke service geen SSL is vereist, kan tailspin vereisen dat elke service dit doet.
• Versiering: clients kunnen worden geschreven en getest op een specifieke versie van een web-API.

Services in de Survey-toepassing maken gebruik van de omgekeerde proxy die is geïmplementeerd door Service Fabric. Omgekeerde proxy is een service die wordt uitgevoerd op elk knooppunt in het Service Fabric-cluster en eindpuntoplossing, automatisch opnieuw proberen biedt en andere typen verbindingsfouten afwerkt. Voor het gebruik van de omgekeerde proxy wordt elke RESTful API-aanroep naar een specifieke service gemaakt met behulp van een vooraf gedefinieerde omgekeerde proxypoort. Als de omgekeerde proxypoort bijvoorbeeld is ingesteld op 19081, kan als volgt een aanroep naar Tailspin.SurveyAnswerService worden gedaan:

static SurveyAnswerService()
{
    httpClient = new HttpClient
    {
        BaseAddress = new Uri("http://localhost:19081/Tailspin/SurveyAnswerService/")
    };
}

Als u omgekeerde proxy wilt inschakelen, geeft u een omgekeerde proxypoort op tijdens het maken van Service Fabric cluster. Zie omgekeerde proxy in Azure Service Fabric.

Prestatieoverwegingen

Tailspin heeft de ASP.NET Core voor Tailspin.Web en Tailspin.Web.Surveys.Public gemaakt met behulp van Visual Studio sjablonen. Standaard bevatten deze sjablonen logboekregistratie naar de console. Logboekregistratie naar de console kan worden uitgevoerd tijdens de ontwikkeling en debuggen, maar alle logboekregistratie naar de console moet worden verwijderd wanneer de toepassing voor productie wordt geïmplementeerd.

De volgende regels in startup.cs voor elk van de web-front-endservices moeten bijvoorbeeld als commentaar worden gebruikt:

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    //loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    //loggerFactory.AddDebug();

    app.UseMvc();
}

Wanneer Tailspin ten slotte de Tailspin-toepassing naar productie implementeert, schakelen ze over naar Visual Studio releasemodus.

Overwegingen bij de implementatie

De gefactoreerde surveys-toepassing bestaat uit vijf stateless services en één stateful service. Clusterplanning is dus beperkt tot het bepalen van de juiste VM-grootte en het juiste aantal knooppunten. In het applicationmanifest.xml waarin het cluster wordt beschreven, stelt Tailspin het kenmerk InstanceCount van de tag StatelessService in op -1 voor elk van de services. Met de waarde -1 wordt Service Fabric om op elk knooppunt in het cluster een exemplaar van de service te maken.

Tailspin implementeert het cluster met behulp van de Azure Portal. Het Service Fabric clusterresourcetype implementeert alle benodigde infrastructuur, inclusief virtuele-machineschaalsets en een load balancer. De aanbevolen VM-grootten worden weergegeven in de Azure Portal tijdens het inrichtingsproces voor het Service Fabric cluster. Omdat de VM's worden geïmplementeerd in een virtuele-machineschaalset, kunnen ze zowel omhoog als uit worden geschaald wanneer de gebruikersbelasting toeneemt.

Volgende stappen

De toepassingscode Surveys is beschikbaar op GitHub.

Als u net begint met Azure Service Fabric,moet u eerst uw ontwikkelomgeving instellen en vervolgens de nieuwste Azure SDK en de Azure Service Fabric SDK downloaden. De SDK bevat OneBox-clusterbeheer, zodat u de toepassing Surveys lokaal kunt implementeren en testen met volledige F5-debugging.