Migrera ett Azure Cloud Services till Azure Service Fabric

Exempelkod

Den här artikeln beskriver hur du migrerar ett program från Azure Cloud Services till Azure Service Fabric. Den fokuserar på arkitektoniska beslut och rekommenderade metoder.

För det här projektet började vi med ett Cloud Services program som heter Surveys och portade det till Service Fabric. Målet var att migrera programmet med så få ändringar som möjligt. Senare i artikeln visar vi hur du optimerar programmet för Service Fabric.

Innan du läser den här artikeln är det bra att förstå grunderna i Service Fabric. Se Översikt över Azure Service Fabric

Om programmet Surveys

Ett fiktivt företag som heter Tailspin skapade ett program som heter Surveys-appen som gör det möjligt för kunder att skapa undersökningar. När en kund registrerar sig för programmet kan användarna skapa och publicera undersökningar och samla in resultaten för analys. Programmet innehåller en offentlig webbplats där personer kan göra en undersökning. Läs mer om det ursprungliga Tailspin-scenariot här.

Nu vill Tailspin flytta programmet Surveys till en mikrotjänstarkitektur med hjälp av Service Fabric körs på Azure. Eftersom programmet redan har distribuerats som Cloud Services program använder Tailspin en metod i flera faser:

1. Porta molntjänsterna till Service Fabric, samtidigt som ändringarna i programmet minimeras.
2. Optimera programmet för Service Fabric genom att flytta till en arkitektur för mikrotjänster.

I ett verkligt projekt är det troligt att båda faserna överlappar varandra. När du portar till Service Fabric skulle du också börja omarbetning av programmet till mikrotjänster. Senare kan du förfina arkitekturen ytterligare, och kanske dela upp grovkorniga tjänster i mindre tjänster.

Programkoden finns på GitHub. Den här lagringsplatsen innehåller både Cloud Services-programmet och Service Fabric versionen.

Varför Service Fabric?

Service Fabric passar bra för det här projektet eftersom de flesta funktioner som behövs i ett distribuerat system är inbyggda i Service Fabric, inklusive:

• Klusterhantering. Service Fabric hanterar automatiskt nod-redundans, hälsoövervakning och andra klusterhanteringsfunktioner.
• Horisontell skalning. När du lägger till noder Service Fabric ett kluster skalas programmet automatiskt när tjänsterna distribueras mellan de nya noderna.
• Tjänstidentifiering. Service Fabric tillhandahåller en identifieringstjänst som kan lösa slutpunkten för en namngiven tjänst.
• Tillståndslösa och tillståndslösa tjänster. Tillståndsful-tjänster använder tillförlitligasamlingar , som kan ta plats i en cache eller kö och kan partitioneras.
• Programlivscykelhantering. Tjänster kan uppgraderas oberoende av varandra och utan avbrott i programmet.
• Tjänstorkestrering över ett kluster med datorer.
• Högre densitet för att optimera resursförbrukningen. En enda nod kan vara värd för flera tjänster.

Service Fabric används av olika Microsoft-tjänster, inklusive Azure SQL Database, Cosmos DB, Azure Event Hubs och andra, vilket gör det till en beprövad plattform för att skapa distribuerade molnprogram.

Jämföra Cloud Services med Service Fabric

I följande tabell sammanfattas några av de viktiga skillnaderna mellan Cloud Services och Service Fabric program. En mer detaljerad diskussion finns i Lär dig mer om skillnaderna mellan Cloud Services och Service Fabric innan du migrerar program.

* Tillståndsful services använder tillförlitliga samlingar för att lagra tillstånd över repliker, så att alla läsningar är lokala för noderna i klustret. Skrivningar replikeras mellan noder för tillförlitlighet. Tillståndslösa tjänster kan ha externt tillstånd med hjälp av en databas eller annan extern lagring.

** Arbetsroller kan också vara värd för ASP.NET webb-API med hjälp av OWIN.

Programmet Surveys på Cloud Services

Följande diagram visar arkitekturen för programmet Surveys som körs på Cloud Services.

Programmet består av två webbroller och en arbetsroll.

• Webbrollen Tailspin.Web är värd för en ASP.NET som Tailspin-kunder använder för att skapa och hantera undersökningar. Kunder använder också den här webbplatsen för att registrera sig för programmet och hantera sina prenumerationer. Slutligen kan Tailspin-administratörer använda den för att se listan över klienter och hantera klientorganisationsdata.

• Webbrollen Tailspin.Web.Survey.Public är värd för ASP.NET webbplats där användare kan ta de undersökningar som Tailspin-kunder publicerar.

• Arbetsrollen Tailspin.Workers.Survey gör bakgrundsbearbetning. Webbrollerna lägger arbetsobjekt i en kö, och arbetsrollen bearbetar objekten. Två bakgrundsuppgifter definieras: Exportera undersökningssvar till Azure SQL Database och beräkna statistik för undersökningssvar.

Förutom att Cloud Services använder surveys-programmet vissa andra Azure-tjänster:

• Azure Storage att lagra undersökningar, undersökningar och klientinformation.

• Azure Cache for Redis cachelagrar en del av de data som lagras i Azure Storage, för snabbare läsåtkomst.

• Azure Active Directory (Azure AD) för att autentisera kunder och Tailspin-administratörer.

• Azure SQL Database att lagra undersökningssvaren för analys.

Flytta till Service Fabric

Som tidigare nämnts var målet med den här fasen att migrera till Service Fabric med minsta nödvändiga ändringar. Därför skapade vi tillståndslösa tjänster som motsvarar varje molntjänstroll i det ursprungliga programmet:

Den här arkitekturen liknar avsiktligt det ursprungliga programmet. Diagrammet döljer dock några viktiga skillnader. I resten av den här artikeln kommer vi att utforska dessa skillnader.

Konvertera molntjänstroller till tjänster

För den första migreringen följde Tailspin stegen som beskrivs i Guide to converting Web and Worker Roles to Service Fabric stateless services.

Skapa frontwebbtjänster

I Service Fabric körs en tjänst i en process som skapats av Service Fabric runtime. För en webb-frontwebb innebär det att tjänsten inte körs i IIS. I stället måste tjänsten vara värd för en webbserver. Den här metoden kallas självvärd eftersomden kod som körs i processen fungerar som webbservervärd.

Det ursprungliga surveys-programmet använder ASP.NET MVC. Eftersom ASP.NET MVC inte kan ha egen värd i Service Fabric, övervägde Tailspin följande migreringsalternativ:

• Porta webbrollerna till ASP.NET Core, som kan ha egen värd.
• Konvertera webbplatsen till en ensidesapplikation (SPA) som anropar ett webb-API som implementeras med hjälp ASP.NET webb-API. Detta skulle ha krävt en fullständig omdesign av webbwebbdelen.
• Behåll den befintliga ASP.NET MVC-koden och distribuera IIS i en Windows Server-container till Service Fabric. Den här metoden kräver lite eller ingen kodändring.

Det första alternativet, portning till ASP.NET Core, gjorde att Tailspin kunde dra nytta av de senaste funktionerna i ASP.NET Core. För att göra konverteringen följde Tailspin stegen som beskrivs i Migrera från MVC ASP.NET till MVC ASP.NET Core.

HTTP-lyssnare

I Cloud Services en webb- eller arbetsroll en HTTP-slutpunkt genom att deklarera den i tjänstdefinitionsfilen. En webbroll måste ha minst en slutpunkt.

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

På samma Service Fabric deklareras slutpunkter i ett tjänstmanifest:

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

Till skillnad från en molntjänstroll kan Service Fabric-tjänster samplaceras inom samma nod. Därför måste varje tjänst lyssna på en distinkt port. Senare i den här artikeln diskuterar vi hur klientbegäranden på port 80 eller port 443 dirigeras till rätt port för tjänsten.

En tjänst måste uttryckligen skapa lyssnare för varje slutpunkt. Anledningen är att Service Fabric är oberoende om kommunikationsstackar. Mer information finns i Skapa en webbtjänst för ditt program med hjälp av ASP.NET Core.

Paketering och konfiguration

En molntjänst innehåller följande konfigurations- och paketfiler:

Det finns en .csdef-fil för hela programmet. Du kan ha flera .cscfg-filer för olika miljöer, till exempel lokala, test eller produktion. När tjänsten körs kan du uppdatera .cscfg men inte .csdef. Mer information finns i Vad är Cloud Service-modellen och hur paketerar jag den?

Service Fabric har en liknande uppdelning mellan en tjänstdefinition och tjänstinställningar,men strukturen är mer detaljerad. För att Service Fabric förstå konfigurationsmodellen hjälper det att förstå hur ett Service Fabric-program paketeras. Här är strukturen:

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

Programpaketet är det du distribuerar. Den innehåller ett eller flera tjänstpaket. Ett tjänstpaket innehåller kod, konfiguration och datapaket. Kodpaketet innehåller binärfilerna för tjänsterna och konfigurationspaketet innehåller konfigurationsinställningar. Med den här modellen kan du uppgradera enskilda tjänster utan att omdistribuera hela programmet. Du kan också uppdatera bara konfigurationsinställningarna utan att omdistribuera koden eller starta om tjänsten.

Ett Service Fabric-program innehåller följande konfigurationsfiler:

Mer information finns i Modellera ett program i Service Fabric.

Om du vill ha stöd för olika konfigurationsinställningar för flera miljöer använder du följande metod, som beskrivs i Hantera programparametrar för flera miljöer:

1. Definiera inställningen i Setting.xml för tjänsten.
2. I programmanifestet definierar du en åsidosättning för inställningen.
3. Placera miljöspecifika inställningar i programparameterfiler.

Distribuera programmet

Medan Azure Cloud Services är en hanterad tjänst Service Fabric en körning. Du kan skapa Service Fabric kluster i många miljöer, inklusive Azure och lokalt. Följande diagram visar en rekommenderad distribution för Azure:

Klustret Service Fabric distribueras till en VM-skalningsuppsättning. Skalningsuppsättningar är Azure Compute resurs som kan användas för att distribuera och hantera en uppsättning identiska virtuella datorer.

Som tidigare nämnts rekommenderar vi att du placerar Kestrel-webbservern bakom en omvänd proxy av säkerhetsskäl. Det här diagrammet Azure Application Gateway, som är en Azure-tjänst som erbjuder olika layer 7-belastningsutjämningsfunktioner. Den fungerar som en omvänd proxy-tjänst och avslutar klientanslutningen och vidarebefordrar begäranden till slutpunkter i serverdelen. Du kan använda en annan omvänd proxylösning, till exempel nginx.

Layer 7-routning

I det ursprungliga surveys-programmetlyssnar en webbroll på port 80 och den andra webbrollen på port 443.

Ett annat alternativ är att använda Layer 7-routning. Med den här metoden dirigeras olika URL-sökvägar till olika portnummer på backend-adressen. Den offentliga platsen kan till exempel använda URL-sökvägar som börjar med /public/ .

Alternativen för Layer 7-routning är:

• Använd Application Gateway.
• Använd en virtuell nätverksinstallation (NVA), till exempel nginx.
• Skriv en anpassad gateway som en tillståndslös tjänst.

Överväg den här metoden om du har två eller flera tjänster med offentliga HTTP-slutpunkter, men vill att de ska visas som en plats med ett enda domännamn.

En metod som vi inte rekommenderar är att tillåta att externa klienter skickar begäranden via Service Fabric omvänd proxy. Även om detta är möjligt är den omvända proxyn avsedd för tjänst-till-tjänst-kommunikation. Om du öppnar den för externa klienter exponeras alla tjänster som körs i klustret som har en HTTP-slutpunkt.

Nodtyper och placeringsbegränsningar

I distributionen som visas ovan körs alla tjänster på alla noder. Men du kan också gruppera tjänster, så att vissa tjänster endast körs på vissa noder i klustret. Skäl att använda den här metoden är:

• Kör vissa tjänster på olika typer av virtuella datorer. Vissa tjänster kan till exempel vara beräkningsintensiva eller kräva GPU:er. Du kan ha en blandning av VM-typer i Service Fabric kluster.
• Isolera frontend-tjänster från backend-tjänster av säkerhetsskäl. Alla tjänster på frontend-sidan körs på en uppsättning noder och servertjänster körs på olika noder i samma kluster.
• Olika skalningskrav. Vissa tjänster kan behöva köras på fler noder än andra tjänster. Om du till exempel definierar frontend-noder och backend-noder kan varje uppsättning skalas oberoende av varandra.

Följande diagram visar ett kluster som avgränsar tjänster på frontend- och serversidan:

Så här implementerar du den här metoden:

1. Definiera två eller flera nodtyper när du skapar klustret.
2. För varje tjänst använder du placeringsbegränsningar för att tilldela tjänsten till en nodtyp.

När du distribuerar till Azure distribueras varje nodtyp till en separat VM-skalningsuppsättning. Klustret Service Fabric omfattar alla nodtyper. Mer information finns i Relationen mellan olika Service Fabric och VM-skalningsuppsättningar.

Om ett kluster har flera nodtyper anges en nodtyp som primär nodtyp. Service Fabric-körningstjänster, till exempel klusterhanteringstjänsten, körs på den primära nodtypen. Etablera minst 5 noder för den primära nodtypen i en produktionsmiljö. Den andra nodtypen ska ha minst 2 noder.

Konfigurera och hantera klustret

Kluster måste skyddas för att förhindra att obehöriga användare ansluter till klustret. Vi rekommenderar att du använder Azure AD för att autentisera klienter och X.509-certifikat för nod-till-nod-säkerhet. Mer information finns i Service Fabric cluster security scenarios (Säkerhetsscenarier för Service Fabric-kluster).

Information om hur du konfigurerar en offentlig HTTPS-slutpunkt finns i Ange resurser i ett tjänstmanifest.

Du kan skala ut programmet genom att lägga till virtuella datorer i klustret. VM-skalningsuppsättningar stöder autoskalning med regler för automatisk skalning baserat på prestandaräknare. Mer information finns i Skala ett kluster Service Fabric in eller ut med autoskalningsregler.

När klustret körs samlar du in loggar från alla noder på en central plats. Mer information finns i Samla in loggar med hjälp av Azure Diagnostics.

Strukturera om programmet

När programmet har portats till Service Fabric är nästa steg att omstrukturera det till en mer detaljerad arkitektur. Tailspins motivation för refaktorering är att göra det enklare att utveckla, bygga och distribuera programmet Surveys. Genom att de befintliga webb- och arbetsrollerna tas bort i en mer detaljerad arkitektur vill Tailspin ta bort de befintliga nära kopplade kommunikations- och databeroendena mellan rollerna.

Tailspin ser andra fördelar med att flytta programmet Surveys till en mer detaljerad arkitektur:

• Varje tjänst kan paketeras i oberoende projekt med ett omfång som är tillräckligt litet för att hanteras av ett litet team.
• Varje tjänst kan versions versioneras och distribueras oberoende av varandra.
• Varje tjänst kan implementeras med den bästa tekniken för den tjänsten. Ett Service Fabric-kluster kan till exempel innehålla tjänster som skapats med olika versioner av .Net Framework, Java eller andra språk som C eller C++.
• Varje tjänst kan skalas oberoende för att svara på ökningar och minskningar i belastningen.

Källkoden för den omstrukturerade versionen av appen finns på GitHub.

Designöverväganden

Följande diagram visar arkitekturen för programmet Surveys som omstrukturerats till en mer detaljerad arkitektur:

Tailspin.Web är en tillståndslös tjänst som själv är värd för ett ASP.NET MVC-program som Tailspin-kunder besöker för att skapa undersökningar och visa undersökningsresultat. Den här tjänsten delar merparten av sin kod med Tailspin.Web-tjänsten från det porterade Service Fabric programmet. Som tidigare nämnts använder den här ASP.NET core och växlar från att använda Kestrel som webb-frontend till att implementera en WebListener.

Tailspin.Web.Survey.Public är en tillståndslös tjänst som också är värd för en ASP.NET MVC-webbplats. Användarna besöker den här webbplatsen för att välja undersökningar från en lista och sedan fylla i dem. Den här tjänsten delar merparten av sin kod med tjänsten Tailspin.Web.Survey.Public från det porterade Service Fabric programmet. Den här tjänsten använder ASP.NET Core och växlar även från att använda Kestrel som webb-frontend till att implementera en WebListener.

Tailspin.SurveyResponseService är en tillståndskänslig tjänst som lagrar undersökningssvar i Azure Blob Storage. Den sammanfogar även svar i undersökningsanalysdata. Tjänsten implementeras som en tillståndsfull tjänst eftersom den använder en ReliableConcurrentQueue för att bearbeta undersökningssvar i batchar. Den här funktionen implementerades ursprungligen i tjänsten Tailspin.AnswerAnalysisService i det porterade Service Fabric programmet.

Tailspin.SurveyManagementService är en tillståndslös tjänst som lagrar och hämtar undersökningar och undersökningsfrågor. Tjänsten använder Azure Blob Storage. Den här funktionen implementerades också ursprungligen i dataåtkomstkomponenterna i Tjänsterna Tailspin.Web och Tailspin.Web.Survey.Public i det porterade Service Fabric-programmet. Tailspin omstrukturerade de ursprungliga funktionerna i den här tjänsten så att den kan skalas oberoende av varandra.

Tailspin.SurveyAnswerService är en tillståndslös tjänst som hämtar undersökningssvar och undersökningsanalys. Tjänsten använder också Azure Blob Storage. Den här funktionen implementerades också ursprungligen i dataåtkomstkomponenterna i Tailspin.Web-tjänsten i det porterade Service Fabric program. Tailspin omstrukturerade den ursprungliga funktionen i den här tjänsten eftersom den förväntar sig mindre belastning och vill använda färre instanser för att spara resurser.

Tailspin.SurveyAnalysisService är en tillståndslös tjänst som bevarar sammanfattningsdata för undersökningssvar i en Redis-cache för snabb hämtning. Den här tjänsten anropas av Tailspin.SurveyResponseService varje gång en undersökning besvaras och de nya undersökningssvarsdata sammanfogas i sammanfattningsdata. Den här tjänsten innehåller de funktioner som ursprungligen implementerades i tjänsten Tailspin.AnswerAnalysisService från det porterade Service Fabric programmet.

Tillståndslösa jämfört med tillståndslösa tjänster

Azure Service Fabric stöder följande programmeringsmodeller:

• Den körbara gästmodellen gör att alla körbara filer kan paketeras som en tjänst och distribueras till ett Service Fabric kluster. Service Fabric dirigerar och hanterar körningen av den körbara gästen.
• Containermodellen möjliggör distribution av tjänster i containeravbildningar. Service Fabric har stöd för att skapa och hantera containrar ovanpå Linux-kernelcontainrar samt Windows Server-containrar.
• Programmeringsmodellen reliable services gör det möjligt att skapa tillståndslösa eller tillståndslösa tjänster som integreras med alla Service Fabric plattformsfunktioner. Tillståndsful-tjänster tillåter att replikerat tillstånd lagras i Service Fabric klustret. Tillståndslösa tjänster gör det inte.
• Programmeringsmodellen Reliable Actors gör det möjligt att skapa tjänster som implementerar mönstret för virtuella aktörer.

Alla tjänster i programmet Surveys är tillståndslösa tillförlitliga tjänster, förutom tjänsten Tailspin.SurveyResponseService. Den här tjänsten implementerar en ReliableConcurrentQueue för att bearbeta undersökningssvar när de tas emot. Svar i ReliableConcurrentQueue sparas i Azure Blob Storage och skickas till Tailspin.SurveyAnalysisService för analys. Tailspin väljer ReliableConcurrentQueue eftersom svar inte kräver strikt FIFO-beställning (först in först ut) som tillhandahålls av en kö, till exempel Azure Service Bus. En ReliableConcurrentQueue är också utformad för att leverera högt dataflöde och låg latens för kö- och köåtgärder.

Åtgärder för att bevara dequeued-objekt från en ReliableConcurrentQueue bör helst vara idempotent. Om ett undantag utlöstes under bearbetningen av ett objekt från kön kan samma objekt bearbetas mer än en gång. I programmet Surveys är åtgärden för att slå samman undersökningssvar till Tailspin.SurveyAnalysisService inte idempotent eftersom Tailspin har bestämt att undersökningsanalysdata endast är en aktuell ögonblicksbild av analysdata och inte behöver vara konsekventa. Undersökningssvaren som sparats i Azure Blob Storage är så småningom konsekventa, så den slutliga undersökningen kan alltid beräknas om korrekt från dessa data.

Kommunikationsramverk

Varje tjänst i surveys-programmet kommunicerar med hjälp av ett RESTful-webb-API. RESTful-API:er har följande fördelar:

• Användarvänlighet: varje tjänst skapas med hjälp ASP.NET Core MVC, som har inbyggt stöd för att skapa webb-API:er.
• Säkerhet: Även om varje tjänst inte kräver SSL kan Tailspin kräva att varje tjänst gör det.
• Versionshantering: klienter kan skrivas och testas mot en specifik version av ett webb-API.

Tjänster i undersökningsprogrammet använder den omvända proxy som implementeras av Service Fabric. Omvänd proxy är en tjänst som körs på varje nod Service Fabric klustret och tillhandahåller slutpunktsmatchning, automatiska återförsök och hanterar andra typer av anslutningsfel. Om du vill använda omvänd proxy görs varje RESTful-API-anrop till en specifik tjänst med hjälp av en fördefinierad omvänd proxyport. Om den omvända proxyporten till exempel har angetts till 19081kan ett anrop till Tailspin.SurveyAnswerService göras på följande sätt:

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

Om du vill aktivera omvänd proxy anger du en omvänd proxyport när Service Fabric klustret. Mer information finns i omvänd proxy i Azure Service Fabric.

Saker att tänka på gällande prestanda

Tailspin skapade ASP.NET Core för Tailspin.Web och Tailspin.Web.Surveys.Public med hjälp Visual Studio mallar. Som standard inkluderar dessa mallar loggning till konsolen. Loggning till konsolen kan göras under utveckling och felsökning, men all loggning till konsolen bör tas bort när programmet distribueras till produktion.

Följande rader i startup.cs för varje frontwebbtjänst bör till exempel kommenteras bort:

// 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();
}

När Tailspin distribuerar Tailspin-programmet till produktion växlar de slutligen Visual Studio till versionsläge.

Distributionsöverväganden

Programmet refaktorerade undersökningar består av fem tillståndslösa tjänster och en tillståndsfull tjänst, så klusterplaneringen begränsas till att fastställa rätt VM-storlek och antal noder. I den applicationmanifest.xml som beskriver klustret anger Tailspin attributet InstanceCount för taggen StatelessService till -1 för var och en av tjänsterna. Värdet -1 uppmanar Service Fabric att skapa en instans av tjänsten på varje nod i klustret.

Tailspin distribuerar klustret med hjälp av Azure Portal. Resurstypen Service Fabric distribuerar all nödvändig infrastruktur, inklusive VM-skalningsuppsättningar och en lastbalanserare. De rekommenderade VM-storlekarna visas i Azure Portal under etableringsprocessen för Service Fabric klustret. Eftersom de virtuella datorerna distribueras i en VM-skalningsuppsättning kan de både skalas upp och ut när användarbelastningen ökar.

Nästa steg

Surveys-programkoden finns på GitHub.

Om du precis har börjat med Azure Service Fabricbörjar du med att konfigurera utvecklingsmiljön och laddar sedan ned den senaste Azure SDK:n och Azure Service Fabric SDK. SDK innehåller OneBox-klusterhanteraren så att du kan distribuera och testa surveys-programmet lokalt med fullständig F5-felsökning.