Dela via

Utvärdering och beredskap för mikrotjänster

En arkitektur för mikrotjänster kan ge många fördelar för dina program, inklusive flexibilitet, skalbarhet och hög tillgänglighet. Den här arkitekturen kan också innebära utmaningar. När du skapar mikrotjänstbaserade program eller omvandlar befintliga program till en mikrotjänstarkitektur måste du analysera och utvärdera din nuvarande situation för att identifiera områden som behöver förbättras.

I den här artikeln beskrivs några saker att tänka på när du går över till en arkitektur för mikrotjänster. Du kan använda den här guiden för att utvärdera mognaden för ditt program, din infrastruktur, DevOps och utvecklingsmodellen.

Förstå affärsprioriteringar

För att utvärdera en arkitektur för mikrotjänster måste du först förstå kärnprioriteterna i din verksamhet. Kärnprioriteringar kan till exempel vara relaterade till flexibilitet, ändringsimplementering eller snabb utveckling. Du måste analysera om din arkitektur passar bra för dina kärnprioriteringar. Tänk på att affärsprioriteringar kan ändras över tid. Innovation är till exempel högsta prioritet för nystartade företag. Men efter några år kan de viktigaste prioriteringarna vara tillförlitlighet och effektivitet.

Överväg följande prioriteringar:

  • Innovation, inklusive att främja flexibilitet och experimentering
  • Tillförlitlighet, inklusive att säkerställa hög tillgänglighet och feltolerans
  • Effektivitet, inklusive optimering av resurser och produktivitet

Dokumentera de servicenivåmål (SLO) som överensstämmer med olika delar av ditt program för att säkerställa ett organisationsåtagande som kan vägleda din utvärdering.

Registrera arkitektoniska beslut

En arkitektur för mikrotjänster hjälper team att bli autonoma. Teams kan fatta egna beslut om tekniker, metoder och infrastrukturkomponenter. Dessa val bör dock respektera de formellt överenskomna principerna som kallas delad styrning. Dessa principer uttrycker överenskommelsen mellan teamen om hur man ska hantera den bredare strategin för mikrotjänster.

Överväg följande faktorer:

  • Om delad styrning finns på plats för att vägleda arkitekturbeslut mellan team

  • Om du underhåller beslutsposter för arkitektur (ADR) som innehåller tydliga skäl, kompromisser och status

  • Oavsett om du underhåller en arkitekturjournal för att samla in designutforskningar och utvecklande kontext

  • Om ditt team enkelt kan komma åt och söka i dina adrs och arkitekturjournaler

  • Om du har ett ramverk för teknikutvärdering för att utvärdera nya verktyg och ramverk

  • Om du har fastställt principer för teknikval och standardisering

  • Om arkitektoniska beslut granskas och uppdateras regelbundet när affärs- och tekniska krav utvecklas

Utvärdera teamsammansättning

Du måste strukturera ditt team korrekt för att undvika onödig kommunikation mellan team. Små, fokuserade, tvärfunktionella team passar bäst för en arkitektur för mikrotjänster. Dessa justeringar kräver ofta en tankeförändring, som måste föregå omstruktureringen av teamet.

Överväg följande faktorer:

  • Om dina team delas upp baserat på underdomäner och följer DDD-principer (domändriven design)

  • Om dina team är korsfunktionella och har tillräckligt med kapacitet för att skapa och driva relaterade mikrotjänster oberoende av varandra

  • Den tid som ägnas åt oplanerade aktiviteter och aktiviteter som inte är relaterade till projekt

  • Den tid som ägnas åt samarbete mellan team

  • Om du har en process för att identifiera och minimera tekniska skulder

  • Hur teamen lär sig lektioner och hur de kommunicerar den här upplevelsen

Använd metoden Twelve-Factor

Det grundläggande målet med att välja en arkitektur för mikrotjänster är att leverera värde snabbare och anpassa sig till förändringar genom att följa agila metoder. Den Twelve-Factor appmetoden innehåller riktlinjer för hur du skapar underhållsbara och skalbara program. Dessa riktlinjer främjar attribut som oföränderlighet, tillfälliga egenskaper, deklarativ konfiguration och automatisering. Genom att införliva dessa riktlinjer och undvika vanliga fallgropar kan du skapa löst kopplade, fristående mikrotjänster.

Förstå nedbrytningsmetoden

Det tar tid att omvandla ett monolitiskt program till en mikrotjänstarkitektur. Börja med edge-tjänster. Edge-tjänster har färre beroenden för andra tjänster och kan enkelt separeras från systemet som oberoende tjänster. Vi rekommenderar starkt mönster som Strangler Fig och Anti-Corruption Layer för att hålla de monolitiska programmen i ett fungerande tillstånd tills alla tjänster delas upp i separata mikrotjänster. Under segregationen kan principerna för DDD hjälpa team att välja komponenter eller tjänster från det monolitiska programmet baserat på underdomäner.

Ett e-handelssystem kan till exempel ha moduler som kundvagn, produkthantering, orderhantering, prissättning, fakturagenerering och meddelande. Du bestämmer dig för att starta omvandlingen av programmet med meddelandemodulen eftersom den inte har beroenden för andra moduler. Andra moduler kan dock vara beroende av den här modulen för att skicka ut meddelanden. Du kan göra meddelandemodulen till en separat mikrotjänst, men du måste också uppdatera det monolitiska programmet för att anropa den nya meddelandetjänsten. Du bestämmer dig för att transformera fakturagenereringsmodulen härnäst. Den här modulen anropas när en order har genererats. Du kan använda mönster som Strangler Fig och Anti-Corruption Layer för att stödja den här omvandlingen.

Datasynkronisering, flera skrivningar till både monolitiska gränssnitt och mikrotjänstgränssnitt, dataägarskap, schemanedbrytning, sammanslagningar, datavolym och dataintegritet kan göra datauppdelning och migrering svåra. Det finns flera tekniker som du kan använda, till exempel att behålla en delad databas mellan mikrotjänster, skilja databaser från en grupp med tjänster baserat på affärskapacitet eller domän och isolera databaser från tjänsterna. En idealisk lösning är att dela upp varje databas med varje tjänst. Vissa omständigheter kan göra det tillvägagångssättet opraktiskt. I dessa fall kan du använda mönster som mönstret Materialiserad vy och metoder som programmodernisering med hjälp av en API-omslutning för att abstrahera och modernisera åtkomsten till äldre eller delade data.

Utvärdera DevOps-beredskap

När du övergår till en arkitektur för mikrotjänster är det viktigt att utvärdera din DevOps-kompetens. En mikrotjänstarkitektur bör underlätta flexibel utveckling i program för att öka organisationens flexibilitet. DevOps är en av de viktigaste metoderna som du bör implementera för att uppnå den här kompetensen.

När du utvärderar din DevOps-funktion för en mikrotjänstarkitektur bör du tänka på följande:

  • Om personer i din organisation känner till de grundläggande metoderna och principerna i DevOps

  • Om teamen förstår verktyg för källkontroll och hur de integreras med CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans)

  • Om du implementerar DevOps-metoder korrekt, inklusive:

    • Följ agila metoder.

    • Implementera kontinuerlig integrering.

    • Implementera kontinuerlig leverans där kodändringar skapas, testas och förbereds automatiskt för lansering till produktion. Den här metoden hjälper till att säkerställa att programvara kan släppas säkert när som helst och med manuellt godkännande.

    • Implementera kontinuerlig distribution som utökar kontinuerlig leverans genom att automatiskt distribuera kodändringar till produktion efter att alla automatiserade tester har slutförts, utan manuella åtgärder.

    • Bädda in kontinuerlig övervakning i alla faser i DevOps och IT Ops för att säkerställa kontinuerlig hälsa, prestanda och tillförlitlighet för program och infrastruktur när de övergår från utveckling till produktions- och kundmiljöer.

  • Om din strategi för bygg- och distributionsautomatisering överensstämmer med teamets leveransmål och driftskrav

  • Om du använder funktionsflaggor och strategier för distribution av progressiv exponering

  • Så här hanteras konfigurationen av mellanlagrings- och produktionsmiljöer för programmet

  • Om verktygskedjan har communitystöd och en supportmodell och tillhandahåller rätt kanaler och dokumentation

Identifiera affärsområden som ändras ofta

En mikrotjänstarkitektur är flexibel och anpassningsbar. Under utvärderingen skapar du en diskussion i din organisation för att fastställa vilka områden dina kollegor förväntar sig att ändra ofta. Genom att skapa mikrotjänster kan team snabbt svara på ändringar som kunderna begär och minimera regressionstestningsarbetet. I ett monolitiskt program kräver en ändring i en modul flera nivåer av regressionstestning och minskar flexibiliteten i nya versioner.

Överväg följande faktorer:

  • Om tjänsten kan distribueras oberoende

  • Om tjänsten följer DDD-principer

  • Om tjänsten följer principerna för enkel ansvarighet, öppet-och-stängt, Liskov-substitution, gränssnittssegregeringsprincipen och beroendeinversion (SOLID)

  • Om databasen är privat för tjänsten

  • Om du skapar tjänsten med hjälp av chassiramverket för mikrotjänster som stöds

Utvärdera infrastrukturberedskap

När du övergår till en arkitektur för mikrotjänster är infrastrukturberedskap en viktig punkt att tänka på. Felaktig installation av infrastrukturen eller att inte använda lämpliga tjänster eller komponenter påverkar programmets prestanda, tillgänglighet och skalbarhet. Du kan använda alla föreslagna metoder och procedurer för att skapa ett program. Men om infrastrukturen är otillräcklig kan programmet fungera dåligt och kräva extra underhåll.

Tänk på följande faktorer när du utvärderar infrastrukturens beredskap:

  • Om infrastrukturen säkerställer skalbarheten för de distribuerade tjänsterna

  • Om du har containerinfrastruktur redo för distribution av mikrotjänster

  • Om infrastrukturen stöder etablering via skript som kan automatiseras via CI/CD

  • Om distributionsinfrastrukturen erbjuder ett serviceavtal (SLA) för tillgänglighet

  • Om du har en haveriberedskapsplan (DR) och rutintestscheman

  • Om data replikeras till olika regioner för DR

  • Om du har en plan för säkerhetskopiering av data

  • Om distributionsalternativen är dokumenterade

  • Om distributionsinfrastrukturen övervakas

  • Om distributionsinfrastrukturen stöder självåterställning av tjänster

Utvärdera lanseringscykler

Mikrotjänster kan anpassas till förändringar och dra nytta av flexibel utveckling för att förkorta lanseringscyklerna och ge kunderna ett värde snabbare. Tänk på följande faktorer när du utvärderar dina lanseringscykler:

  • Hur ofta du skapar och släpper program.

  • Hur ofta dina versioner misslyckas efter distributionen.

  • Hur lång tid det tar att återställa eller åtgärda problem efter ett avbrott.

  • Om du använder semantisk versionshantering för dina program.

  • Om du underhåller olika miljöer och distribuerar samma version sekventiellt. Du kan till exempel frigöra till mellanlagring först och sedan till produktion.

  • Om du använder versionshantering för dina API:er.

  • Om du följer rätt versionsriktlinjer för API:er.

  • När du ändrar en API-version.

  • Vad din metod för att hantera API-versionshantering är, inklusive:

    • Versionshantering av URI-sökväg.
    • Versionshantering av frågeparametrar.
    • Versionshantering av innehållstyp.
    • Versionshantering för anpassat sidhuvud.

  • Om du har en praxis på plats för versionshantering av händelser.

Utvärdera kommunikation mellan tjänster

Mikrotjänster är fristående tjänster som kommunicerar med varandra över processgränser för att hantera affärsscenarier. För att uppnå tillförlitlig och pålitlig kommunikation måste du välja ett lämpligt kommunikationsprotokoll.

Överväg följande faktorer:

  • Oavsett om du följer en API-första metod, där du utformar och underhåller API:er som primära komponenter i systemarkitekturen.

  • Oavsett om du utvärderar protokoll med höga prestanda, till exempel gRPC, HTTP/2 eller asynkrona meddelanden som Kafka eller NATS, för effektiv tjänst-till-tjänst-kommunikation.

  • Oavsett om du har långkedjeåtgärder, där flera tjänster kommunicerar i följd över ett synkront kommunikationsprotokoll.

  • Om du använder plattformar för händelseströmning för databearbetning i realtid.

  • Om du planerar att implementera asynkron kommunikation var som helst i systemet.

  • Om du planerar att utvärdera meddelandebrokerteknologin och dess funktioner.

  • Om du förstår dataflödet för meddelanden som tjänster tar emot och bearbetar.

  • Om du använder direkt kommunikation från klient till tjänst.

  • Om du behöver spara meddelanden på meddelandemäklarnivå.

  • Om du använder mönstret Materialiserad vy för att hantera mikrotjänsters chattiga beteende.

  • Oavsett om du planerar att implementera mönster som Återförsök, Circuit Breaker, Exponentiell Backoff eller Jitter för tillförlitlig kommunikation. Ett vanligt sätt att hantera dessa funktioner är att använda mönstret Ambassadör.

  • Om du har definierat domänhändelser för att underlätta kommunikationen mellan mikrotjänster.

Utvärdera hur tjänster exponeras för klienter

En API-gateway är en av kärnkomponenterna i en mikrotjänstarkitektur. Att direkt exponera tjänster för klienterna skapar problem med hanterbarhet, kontroll och pålitlig kommunikation. En API-gateway fungerar som en proxyserver som fångar upp trafik och dirigerar den till serverdelstjänster. Om du behöver filtrera trafik efter IP-adress, auktorisering eller falska svar kan du filtrera den på API Gateway-nivå utan att göra några ändringar i tjänsterna.

Överväg följande faktorer:

  • Om klienter använder tjänsterna direkt

  • Om en API-gateway fungerar som en enhetlig fasad för alla tjänster

  • Om du implementerar BFF-mönstret (Backends for Frontends) för olika klienttyper

  • Om API-gatewayen kan konfigurera principer som kvotgränser, falska svar och IP-adressfiltrering

  • Om du använder flera API-gatewayer för att tillgodose behoven hos olika typer av klienter, till exempel mobilappar, webbappar och partner

  • Om din API-gateway tillhandahåller en portal där klienter kan identifiera och prenumerera på tjänster, till exempel en utvecklarportal i Azure API Management

  • Oavsett om din lösning tillhandahåller funktioner för L7-belastningsutjämning eller brandvägg för webbprogram (WAF) tillsammans med API-gatewayen

Utvärdera transaktionshantering

Distribuerade transaktioner hjälper dig att köra flera åtgärder som en enda arbetsenhet. I en arkitektur för mikrotjänster delas systemet upp i flera tjänster. Flera mikrotjänster hanterar ett enskilt affärsanvändningsfall som en del av en enda distribuerad transaktion. I en distribuerad transaktion är ett kommando en åtgärd som startar när en händelse inträffar. Händelsen utlöser en åtgärd i systemet. Om åtgärden lyckas kan det utlösa ett annat kommando, som sedan kan utlösa en annan händelse. Den här processen fortsätter tills alla transaktioner har slutförts eller återställts, beroende på om transaktionen lyckas.

Överväg följande faktorer:

  • Antalet distribuerade transaktioner i systemet

  • Hur du hanterar distribuerade transaktioner, inklusive användningen av Saga-mönstret med orkestrering eller koreografi

  • Om du använder event sourcing för att upprätthålla transaktionshistorik och tillstånd

  • Om du implementerar CQRS-mönster (Command Query Responsibility Segregation)

  • Hur många transaktioner sträcker sig över flera tjänster

  • Oavsett om du följer en transaktionsmodell för atomicitet, konsekvens, isolering och hållbarhet (ACID) eller en i princip tillgänglig, mjuk och så småningom konsekvent transaktionsmodell (BASE) för att uppnå datakonsekvens och integritet

  • Om du använder kedjeåtgärder för transaktioner som sträcker sig över flera tjänster

  • Om du implementerar kompensationsmönster utöver Saga för transaktionsåterställning

Utvärdera din tjänstutvecklingsmodell

En av de största fördelarna med mikrotjänstarkitekturer är teknikdiversitet. Mikrotjänstbaserade system gör det möjligt för team att utveckla tjänster med hjälp av de tekniker som de väljer. I traditionell programutveckling kan du återanvända befintlig kod när du skapar nya komponenter eller skapa ett internt utvecklingsramverk för att minska utvecklingsinsatsen. Användning av flera tekniker kan förhindra återanvändning av kod.

Överväg följande faktorer:

  • Om du använder en standardiserad tjänstmall för att påskynda ny tjänstutveckling och säkerställa konsekvens i arkitektur, distribution och DevOps-metoder

  • Om du följer Twelve-Factor appmetodik och använder en enda kodbas för mikrotjänster för att isolera beroenden och externalisera konfiguration

  • Om du behåller känslig konfiguration i nyckelvalv

  • Om du containeriserar dina tjänster

  • Om du känner till dina krav på datakonsekvens

Utvärdera distributionsmetoden

Distributionsmetoden är din metod för att släppa versioner av ditt program i olika distributionsmiljöer. Mikrotjänstbaserade system ger flexibiliteten att släppa versioner snabbare än vad du kan för traditionella program.

När du utvärderar distributionsplanen bör du tänka på följande faktorer:

  • Om du har en strategi för att distribuera dina tjänster

  • Om du använder moderna verktyg och tekniker för att distribuera dina tjänster

  • Vilken typ av samarbete som teamen behöver när du distribuerar tjänster

  • Om du tillhandahåller infrastruktur med hjälp av infrastruktur som kod (IaC)

  • Om du följer oföränderliga infrastrukturprinciper

  • Om du använder DevOps-funktioner för att automatisera distributioner

  • Om du distribuerar samma versioner till flera miljöer, enligt Twelve-Factor app-metodik

Utvärdera din värdplattform

Skalbarhet är en av de viktigaste fördelarna med mikrotjänstarkitekturer. Mikrotjänster mappas till affärsdomäner så att du kan skala varje tjänst separat. Ett monolitiskt program distribueras som en enda enhet på en värdplattform, så du måste skala det holistiskt. Den här metoden resulterar i stilleståndstid, distributionsrisk och underhåll. Ditt monolitiska program kan vara väl utformat och ha komponenter som hanterar enskilda affärsdomäner. Men på grund av brist på processgränser ökar risken för att bryta mot principerna om enskilt ansvar. Insatser för att säkerställa principerna för enskilt ansvar kan resultera i kod som saknar struktur och är svår att underhålla. Eftersom programmet består och distribueras som en enda värdprocess är skalbarhet svårt att uppnå.

Mikrotjänster gör det möjligt för team att välja rätt värdplattform för att stödja deras skalbarhetsbehov. Olika värdplattformar kan hantera dessa utmaningar genom att tillhandahålla funktioner som autoskalning, elastisk etablering, högre tillgänglighet, snabbare distribution och enkel övervakning.

Överväg följande faktorer:

  • Vilken värdplattform, som virtuella datorer, containrar eller serverlösa plattformar, använder du för att distribuera dina tjänster

  • Om värdplattformen är skalbar och stöder automatisk skalning

  • Hur lång tid det tar att skala din värdplattform

  • Om du förstår de serviceavtal som olika värdplattformar tillhandahåller

  • Om din värdplattform stöder DR

Utvärdera övervakning av tjänster

Övervakning är en viktig del av ett mikrotjänstbaserat program. Felsökningsfel kan vara skrämmande eftersom programmet är indelat i många tjänster som körs oberoende av varandra. Om du använder rätt semantik för att övervaka dina tjänster kan dina team enkelt övervaka, undersöka och svara på fel.

Överväg följande faktorer:

  • Om du övervakar dina distribuerade tjänster

  • Om du har definierat SLO:er

  • Om du har en loggningsmekanism och vilka verktyg du använder

  • Om du har en distribuerad spårningsinfrastruktur på plats

  • Om du registrerar undantag

  • Om du underhåller affärsfelkoder för att snabbt identifiera problem

  • Om du använder hälsokontroller för tjänster

  • Om du använder semantisk loggning och implementerar nyckelmått, tröskelvärden och indikatorer

  • Om du maskerar känsliga data under loggning

  • Om du övervakar tjänstberoenden och externa integreringar

Utvärdera tilldelning av korrelationstoken

I en mikrotjänstarkitektur består ett program av olika mikrotjänster som hanteras oberoende av varandra och interagerar med varandra för att hantera olika affärsanvändningsfall. När ett program interagerar med serverdelstjänster för att utföra en åtgärd kan du tilldela ett unikt nummer, som kallas en korrelationstoken, till begäran. Vi rekommenderar att du överväger att använda korrelationstoken eftersom de kan hjälpa dig att felsöka fel. De hjälper dig att fastställa grundorsaken till ett problem, bedöma effekten och bestämma en metod för att åtgärda problemet.

Du kan använda korrelationstoken för att hämta begärandespåret genom att identifiera vilka tjänster som innehåller korrelationstoken och vilka som inte gör det. De tjänster som inte har korrelationstoken för den begäran misslyckades. Om ett fel inträffar kan du försöka utföra transaktionen igen. För att framtvinga idempotens hanterar endast tjänster som inte har korrelationstoken begäran.

Om du till exempel har en lång kedja av åtgärder som innehåller många tjänster, kan det hjälpa att skicka en korrelationstoken till tjänsterna för att enklare undersöka problem om någon av tjänsterna skulle misslyckas under en transaktion. Varje tjänst har vanligtvis en egen databas. Korrelationstoken sparas i databasposten. Om en transaktion spelas upp igen ignorerar tjänster som har den specifika korrelationstoken i sina databaser begäran. Endast tjänster som inte har token hanterar begäran.

Överväg följande faktorer:

  • I vilket skede du tilldelar korrelationstoken

  • Vilken komponent tilldelar korrelationstoken

  • Om du sparar korrelationstoken i tjänstens databas

  • Formatet för korrelationstoken

  • Om du loggar korrelationstoken och annan begäransinformation

Utvärdera behovet av ett ramverk för mikrotjänsters infrastruktur

Ett chassiramverk för mikrotjänster är ett basramverk som tillhandahåller funktioner för övergripande problem som loggning, undantagshantering, distribuerad spårning, säkerhet och kommunikation. När du använder ett chassiramverk fokuserar du mer på att implementera tjänstgränsen än på att interagera med infrastrukturfunktioner.

Anta till exempel att du skapar en kundvagnshanteringstjänst. Du vill verifiera den inkommande token, skriva loggar till loggningsdatabasen och kommunicera med en annan tjänst genom att anropa tjänstens slutpunkt. Om du använder ett chassiramverk för mikrotjänster kan du minska utvecklingsinsatserna. Dapr är ett system som tillhandahåller olika byggstenar för att implementera övergripande problem.

Överväg följande faktorer:

  • Om du använder ett chassiramverk för mikrotjänster.

  • Om du använder Dapr för att interagera med övergripande problem.

  • Om ditt chassiramverk är språkagnostiskt.

  • Om ditt chassiramverk är allmänt så att det kan stödja alla typer av program. Ett chassiramverk får inte innehålla programspecifik logik.

  • Om ditt chassiramverk tillhandahåller en mekanism för att använda de valda komponenterna eller tjänsterna efter behov.

Utvärdera din metod för programtestning

Du testar vanligtvis programmet när utvecklingen är klar och den är redo att distribueras till användargodkännandetestning (UAT) och produktionsmiljöer. Överväg att testa tidigare i livscykeln för programutveckling. Den här metoden kallas skift-vänster-testning. Det ökar kvaliteten på program eftersom du testar under varje fas i livscykeln för programutveckling, inklusive design-, utvecklings- och efterutvecklingsfaserna.

När du till exempel skapar ett program börjar du med att utforma en arkitektur. När du använder metoden skift-vänster testar du designen för sårbarheter med hjälp av verktyg som Microsoft Threat Modeling. När du börjar utveckla kan du genomsöka källkoden genom att köra verktyg som SAST (Static Application Security Testing) och med hjälp av andra analysverktyg för att upptäcka problem. När du har distribuerat applikationen kan du använda verktyg som dynamisk applikationssäkerhetstestning (DAST) för att testa den medan den är i drift. Funktionell testning, kaostestning, intrångstestning och andra typer av tester sker senare.

Överväg följande faktorer:

  • Om du skriver testplaner som täcker hela utvecklingslivscykeln

  • Om du inkluderar testare i kravmöten och i hela livscykeln för programutveckling

  • Oavsett om du använder testdriven design eller beteendedriven design

  • Om du testar användarberättelser och inkluderar acceptanskriterier i dina användarberättelser

  • Om du testar din design med hjälp av verktyg som Microsoft Threat Modeling

  • Oavsett om du skriver enhetstester

  • Oavsett om du använder statiska kodanalysverktyg eller andra verktyg för att mäta kodkvaliteten

  • Om du använder automatiserade verktyg för att testa program

  • Om du implementerar säkra DevOps-metoder

  • Oavsett om du utför integreringstestning, programtestning från slutpunkt till slutpunkt, belastnings- och prestandatestning, intrångstestning och kaostestning

Utvärdera säkerheten för mikrotjänster

Tjänstskydd, säker åtkomst och säker kommunikation är några av de viktigaste övervägandena för en arkitektur för mikrotjänster. Ett mikrotjänstbaserat system som omfattar flera tjänster och använder tokenverifiering för varje tjänst är till exempel inte en genomförbar lösning. Den här typen av system påverkar det övergripande systemets flexibilitet och kan leda till implementeringsavvikelser mellan tjänster.

API-gatewayen och programbrandväggen hanterar vanligtvis säkerhetsproblem. Gatewayen och brandväggen tar inkommande begäranden, validerar token och tillämpar olika filter och principer, till exempel implementering av OWASP Top 10-principer för att fånga upp trafik. Slutligen skickar de begäran till serverdelsmikrotjänsterna. Den här konfigurationen hjälper utvecklare att fokusera på affärsbehov i stället för att oroa sig för det övergripande säkerhetsproblemet.

Överväg följande faktorer:

  • Om tjänsten kräver autentisering och auktorisering och om du implementerar zero trust-arkitekturprinciper

  • Oavsett om du har en omfattande strategi för hantering av hemligheter som omfattar nyckelrotation, livscykelhantering och granskning, utöver att bara lagra hemligheter i ett nyckelvalv

  • Om du använder en API-gateway för att verifiera token och inkommande begäranden

  • Oavsett om du använder Secure Sockets Layer (SSL) eller ömsesidig transportnivåsäkerhet (mTLS) för att tillhandahålla säkerhet för tjänstkommunikation

  • Om du implementerar genomsökning av container- och avbildningssäkerhet

  • Om du implementerar nätverkssäkerhetsprinciper för att tillåta nödvändig kommunikation mellan tjänster

  • Oavsett om du använder brandväggar, till exempel L4 eller L7, i förekommande fall för att ge mer säkerhet för intern och extern kommunikation

  • Om du använder säkerhetsprinciper i API-gatewayer för att styra trafik

  • Om du har körningssäkerhetsövervakning för att identifiera avvikande beteende

Contributors

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudsakliga författare:

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg