Vad är mikrotjänster?
Molnet driver dagens programutveckling och IT-systemhantering. Moderna molnprogram måste vara snabba, flexibla, massivt skalbara och tillförlitliga.
Med hjälp av containrar kan du distribuera program som uppfyller alla dessa krav. Men att sätta ett program i en container utan att följa ett strategiskt designmönster är som att komma in i ett fordon och hoppas hitta din väg till en ny stad utan att använda en karta eller GPS. Du kan hamna på målet, men vägen är förmodligen inte direkt eller den mest effektiva.
En mikrotjänstarkitektur är användbar i det här scenariot. Mikrotjänster ger dig en metod för utveckling och distribution av programvara som passar perfekt för kraven på flexibilitet, skalbarhet och tillförlitlighet i moderna molnprogram.
Vad är en arkitektur för mikrotjänster?
I en arkitektur för mikrotjänster delas ett stort program upp i en uppsättning mindre tjänster. Varje tjänst körs i sin egen process och kommunicerar med andra processer med hjälp av protokoll som HTTP/HTTPS, WebSocket eller Advanced Message Queuing Protocol (AMQP). Varje mikrotjänst implementerar en specifik domän eller affärskapacitet från slutpunkt till slutpunkt inom en viss kontextgräns. Varje mikrotjänst måste utvecklas självständigt och måste kunna distribueras separat. Slutligen bör varje mikrotjänst äga sin relaterade domändatamodell och domänlogik. Mikrotjänster kan baseras på olika datalagringstekniker (SQL, NoSQL) och olika programmeringsspråk.
Här följer några viktiga egenskaper för mikrotjänster:
- De är små, oberoende och löst kopplade.
- Varje mikrotjänst har en separat kodbas som ett litet utvecklingsteam kan hantera.
- De distribueras oberoende av varandra. Ett team kan uppdatera en befintlig mikrotjänst utan att återskapa och distribuera om hela programmet.
- De bevarar sina data eller det externa tillståndet i sina respektive databaser. Till skillnad från i en monolitisk arkitektur delar mikrotjänster inte databaser.
- De kommunicerar med varandra med hjälp av väldefinierade API:er. Interna implementeringsdetaljer för varje tjänst är dolda från andra tjänster.
- De stöder flerspråkig programmering. Mikrotjänster som utgör ett webbprogram behöver till exempel inte dela samma teknikstack, bibliotek eller ramverk.
Varför utvecklas med hjälp av en arkitektur för mikrotjänster?
Mikrotjänster kapslar vanligtvis in enklare funktioner för kundkrav, som du kan skala ut eller skala in. Du kan testa, distribuera och hantera dem oberoende av varandra. En viktig fördel med en mikrotjänstmetod är att teamen drivs mer av kundscenarier än med hjälp av specifik teknik. Varje litet utvecklingsteam utvecklar en mikrotjänst baserat på ett kundscenario. Teamet väljer de tekniker som används.
Mikrotjänster ger långsiktig flexibilitet. Mikrotjänster stöder underhåll i komplexa, stora och mycket skalbara system genom att du kan skapa program baserat på många oberoende distributionsbara tjänster som var och en har detaljerade och autonoma livscykeler.
Som en annan fördel kan mikrotjänster skalas ut oberoende av varandra. I stället för att ha ett enda monolitiskt program som du måste skala ut som en enhet kan du i stället skala ut specifika mikrotjänster. Du kan bara skala det funktionella området som behöver mer processorkraft eller nätverksbandbredd för att stödja efterfrågan i stället för att skala ut andra områden i programmet som inte behöver skalas. Det innebär kostnadsbesparingar eftersom du behöver mindre maskinvara.
Mikrotjänstmetoden tillåter smidiga ändringar och snabb iteration av varje mikrotjänst eftersom du kan ändra specifika, små områden i komplexa, stora och skalbara program.
Att utforma detaljerade mikrotjänstbaserade program möjliggör kontinuerlig integrering och kontinuerlig leveranspraxis. Det påskyndar också leveransen av nya funktioner till programmet. Du kan köra och testa mikrotjänster isolerat och utveckla dem självständigt samtidigt som du upprätthåller tydliga kontrakt mellan tjänster. Så länge du inte ändrar gränssnitten eller kontrakten kan du ändra den interna implementeringen av mikrotjänster eller lägga till nya funktioner utan att bryta andra mikrotjänster.
Vilken roll spelar containrar?
Containerisering är en metod för programvaruutveckling där ett program eller en tjänst, dess beroenden och dess konfiguration (abstraherade som distributionsmanifestfiler) paketeras tillsammans som en containeravbildning. Du kan testa det containerbaserade programmet som en enhet och distribuera det som en containeravbildningsinstans på värdoperativsystemet.
Precis som fraktcontainrar tillåter att varor av alla slag transporteras med fartyg, tåg eller lastbil fungerar programvarucontainrar som en standardenhet för programvarudistribution som kan innehålla olika kod och beroenden. Utvecklare och IT-proffs kan använda containerbaserad programvara för att distribuera kod och beroenden i miljöer med liten eller ingen ändring.
Om det låter som att containerstorlek för ett program kan vara ett bra sätt att implementera arkitekturmönstret för mikrotjänster är det det. Fördelarna med att använda containrar överensstämmer nästan exakt med fördelarna med att använda en arkitektur för mikrotjänster.
Kommentar
Att containerisera ett program är inte det enda sättet att distribuera mikrotjänster. Du kan distribuera mikrotjänster som enskilda tjänster i Azure App Service, på virtuella datorer eller på flera olika sätt. Containrar är det distributionsverktyg som vi ska använda för våra mikrotjänster för resten av den här modulen.
En annan fördel med containerisering är skalbarhet. Du kan skala ut snabbt genom att skapa nya containrar som ska användas för kortsiktiga uppgifter. Ur programsynpunkt liknar instansiering av en avbildning (att skapa en container) instansiera en process som en tjänst eller webbapp.
I korthet erbjuder containrar fördelarna med isolering, portabilitet, flexibilitet, skalbarhet och kontroll över hela arbetsflödet för programlivscykeln.
De mikrotjänster som du skapar i den här modulen körs i en Docker-container som publiceras med hjälp av .NET CLI.
.NET SDK-containerpublicering
I .NET 7 fick .NET SDK möjlighet att skapa containeravbildningar via dotnet publish kommandot . Verktygen för att göra detta gör en massa slutsatsdragningar baserat på egenskaperna för projektet och dess utdata. .NET skapar sedan samma avbildning som en Dockerfile skulle skapa. Det kan ta så få som två kommandon att skapa ett nytt program och publicera det som en avbildning:
dotnet new webapi
dotnet publish --os linux --arch x64 /t:PublishContainer -c Release
De föregående .NET CLI-kommandona skapar ett nytt webb-API och publicerar appen som en container:
- Rikta in sig på Linux som operativsystem (--os linux).
- Ange en x64-arkitektur (--arch x64).
- Använda versionskonfigurationen (-c Release).
Du kan styra många aspekter av den genererade containern via MSBuild-egenskaper. Om du kan använda ett kommando i en Dockerfile för att ange en konfiguration kan du göra samma sak via MSBuild.
Varför skapa mikrotjänster i .NET?
Från och med .NET Core och fortsätter till aktuella iterationer skapas .NET för att vara molnbaserat först. Den körs plattformsoberoende, så docker-avbildningen kan baseras på en linux-variant och .NET-koden körs fortfarande. Microsoft har redan skapat .NET-avbildningar för Docker. Dessutom är .NET extremt snabbt. ASP.NET Kestrel-webbservern överträffar rutinmässigt andra webbservrar.
Docker
Docker är en plattform med öppen källkod som du kan använda för att automatisera distributionen av program som bärbara, självförsörjande containrar som kan köras i molnet eller lokalt. Docker är också det företag som främjar och utvecklar denna teknik. Docker som organisation fungerar i samarbete med moln-, Linux- och Windows-leverantörer, inklusive Microsoft.
Docker-containrar kan köras var som helst: lokalt i kundens datacenter, i en extern tjänstleverantör eller i molnet. Docker-avbildningscontainrar kan köras internt i Linux och Windows.
Vad är en bild?
När en utvecklare använder Docker skapar de en app eller tjänst och paketera sedan appen eller tjänsten och dess beroenden i en containeravbildning. En avbildning är en statisk representation av appen eller tjänsten och dess konfiguration och beroenden.
Avbildningen blir containern när den körs. Containern är den instans av en avbildning som finns i minnet.
Containeravbildningar är oföränderliga. När du har skapat en avbildning kan avbildningen inte ändras. Eftersom du inte kan ändra en bild skapar du en ny avbildning om du behöver göra ändringar i appen eller tjänsten och dess beroenden. Den här funktionen garanterar att den imageF som du använder i produktion är samma avbildning som används i utveckling och testning.
Vad är en Dockerfile?
En Dockerfile är en textfil som innehåller instruktioner för hur du skapar en Docker-avbildning. Dockerfiles skrivs på ett minimalt skriptspråk som är utformat för att skapa och konfigurera avbildningar. Dockerfiles dokumenterar också de åtgärder som krävs för att skapa en avbildning, med början i en basavbildning.
Om du vill skapa en Docker-avbildning som innehåller ditt program börjar du vanligtvis med att identifiera en basavbildning. Sedan lägger du till fler filer och konfigurationer i basavbildningen. Processen för att identifiera en lämplig basavbildning börjar vanligtvis med en Docker Hub-sökning efter en färdig avbildning som redan innehåller ett programramverk och alla verktyg för en Linux-distribution som Ubuntu eller Alpine. Om du till exempel har ett ASP.NET program som du vill paketera i en container publicerar Microsoft en avbildning med namnet mcr.microsoft.com/dotnet/aspnet som redan innehåller ASP.NET-körningen.
Du kan anpassa en avbildning genom att starta en container med en basavbildning och sedan göra ändringar i den. Ändringar omfattar vanligtvis aktiviteter som att kopiera filer till containern från det lokala filsystemet och köra olika verktyg och verktyg för att kompilera kod.
En Dockerfile är en uppsättning instruktioner som skapar en Docker-avbildning som har exakt den programvara som du behöver i den för att köra ditt program, inklusive själva programmet.