Dela via


Arkitektur med mikrotjänster

Dricks

Det här innehållet är ett utdrag från eBook, .NET Microservices Architecture for Containerized .NET Applications, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Som namnet antyder är en mikrotjänstarkitektur en metod för att skapa ett serverprogram som en uppsättning små tjänster. Det innebär att en mikrotjänstarkitektur huvudsakligen är inriktad på serverdelen, även om metoden också används för klientdelen. Varje tjänst körs i sin egen process och kommunicerar med andra processer med hjälp av protokoll som HTTP/HTTPS, WebSockets eller AMQP. Varje mikrotjänst implementerar en specifik domän eller affärskapacitet från slutpunkt till slutpunkt inom en viss kontextgräns, och var och en måste utvecklas självständigt och kunna distribueras oberoende av varandra. Slutligen bör varje mikrotjänst äga sin relaterade domändatamodell och domänlogik (suveränitet och decentraliserad datahantering) och kan baseras på olika datalagringstekniker (SQL, NoSQL) och olika programmeringsspråk.

Vilken storlek ska en mikrotjänst vara? När du utvecklar en mikrotjänst bör storleken inte vara den viktiga punkten. I stället bör den viktiga punkten vara att skapa löst kopplade tjänster så att du har självbestämmande för utveckling, distribution och skalning för varje tjänst. När du identifierar och utformar mikrotjänster bör du naturligtvis försöka göra dem så små som möjligt så länge du inte har för många direkta beroenden med andra mikrotjänster. Viktigare än mikrotjänstens storlek är den interna sammanhållning som den måste ha och dess oberoende från andra tjänster.

Varför en arkitektur för mikrotjänster? Kort och kort ger det långsiktig flexibilitet. Mikrotjänster möjliggör bättre 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 ytterligare en 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. På så sätt kan du skala bara det funktionella området som behöver mer bearbetningskraft 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.

Diagram of the differences between the two deployment methods.

Bild 4-6. Monolitisk distribution jämfört med mikrotjänstmetoden

Som bild 4–6 visar skalar programmet i den traditionella monolitiska metoden genom att klona hela appen på flera servrar/virtuella datorer. I mikrotjänstmetoden är funktionerna åtskilda i mindre tjänster, så att varje tjänst kan skalas separat. Mikrotjänstmetoden tillåter smidiga ändringar och snabb iteration av varje mikrotjänst, eftersom du kan ändra specifika, små områden med 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. Med detaljerad sammansättning av program kan du också köra och testa mikrotjänster isolerat och utveckla dem självständigt samtidigt som tydliga kontrakt mellan dem upprätthålls. 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.

Följande är viktiga aspekter för att göra det möjligt att gå in i produktion med ett mikrotjänstbaserat system:

  • Övervakning och hälsokontroller av tjänster och infrastruktur.

  • Skalbar infrastruktur för tjänsterna (det vill: moln- och orkestrerare).

  • Säkerhetsdesign och implementering på flera nivåer: autentisering, auktorisering, hantering av hemligheter, säker kommunikation osv.

  • Snabb programleverans, vanligtvis med olika team som fokuserar på olika mikrotjänster.

  • DevOps- och CI/CD-metoder och infrastruktur.

Av dessa omfattas eller introduceras endast de tre första i den här guiden. De två sista punkterna, som är relaterade till programmets livscykel, beskrivs i den ytterligare containerbaserade Docker-programlivscykeln med Microsoft Platform and Tools e-bok.

Ytterligare resurser