Dela via

Utvärdering och beredskap för mikrotjänster

  • Artikel

En arkitektur för mikrotjänster kan ge många fördelar för dina program, inklusive flexibilitet, skalbarhet och hög tillgänglighet. Tillsammans med dessa fördelar innebär den här arkitekturen 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.

Den här guiden hjälper dig att förstå 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, infrastruktur, DevOps, utvecklingsmodell med mera.

Förstå affärsprioriteringar

För att börja 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 huvudprioriteringarna vara tillförlitlighet och effektivitet.

Här följer några prioriteringar att tänka på:

  • Innovation
  • Tillförlitlighet
  • Effektivitet

Dokumentera serviceavtalen som är anpassade till olika delar av ditt program för att säkerställa ett organisationsåtagande som kan fungera som en guide till din utvärdering.

Registrera arkitektoniska beslut

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

Tänk på följande faktorer:

  • Är delad styrning på plats?
  • Spårar du beslut och deras kompromisser i en arkitekturdagbok?
  • Kan ditt team enkelt komma åt din arkitekturjournal?
  • Har du en process för att utvärdera verktyg, tekniker och ramverk?

Utvärdera teamsammansättning

Du måste ha rätt teamstruktur för att undvika onödig kommunikation mellan team. En arkitektur för mikrotjänster uppmuntrar till bildandet av små, fokuserade, tvärfunktionella team och kräver en tankeförändring, som måste föregås av en omstrukturering av teamet.

Tänk på följande faktorer:

  • Är dina team uppdelade baserat på underdomäner, enligt domändrivna designprinciper (DDD) ?
  • Är dina team korsfunktionella, med tillräckligt med kapacitet för att skapa och driva relaterade mikrotjänster oberoende av varandra?
  • Hur mycket tid ägnas åt ad hoc-aktiviteter och uppgifter som inte är relaterade till projekt?
  • Hur mycket tid ägnas åt samarbete mellan team?
  • Har du en process för att identifiera och minimera tekniska skulder?
  • Hur förmedlas lärdomar och erfarenheter mellan team?

Använd tolvfaktormetoden

Det grundläggande målet med att välja en arkitektur för mikrotjänster är att leverera värde snabbare och vara anpassningsbar till förändring genom att följa agila metoder. Metoden för tolvfaktorsappar innehåller riktlinjer för att skapa 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 delas upp från systemet som oberoende tjänster. Vi rekommenderar starkt mönster som Strangler Fig och Anti-corruption Layer för att hålla det monolitiska programmet 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.

I ett e-handelssystem kan du till exempel ha följande moduler: 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. Meddelandemodulen kan enkelt delas upp i en separat mikrotjänst, men du måste göra vissa ändringar i 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 och Anti-corruption för att stödja den här omvandlingen.

Datasynkronisering, flera skrivningar till både monolitiska gränssnitt och mikrotjänstgränssnitt, dataägarskap, schema nedbrytning, kopplingar, datavolym och dataintegritet kan göra datauppdelning och migrering svårt. 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. Den rekommenderade lösningen är att dela upp varje databas med varje tjänst. Under många omständigheter är det inte praktiskt. I dessa fall kan du använda mönster som mönstret Databasvy och mönstret Databashanteringstjänst.

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 är avsedd att 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:

  • Känner personer i din organisation till de grundläggande metoderna och principerna i DevOps?
  • Förstår teamen verktyg för källkontroll och deras integrering med CI/CD-pipelines?
  • Implementerar du DevOps-metoder korrekt?
    • Följer du agila metoder?
    • Implementeras kontinuerlig integrering?
    • Implementeras kontinuerlig leverans?
    • Implementeras kontinuerlig distribution?
    • Implementeras kontinuerlig övervakning?
    • Är infrastruktur som kod (IaC) på plats?
  • Använder du rätt verktyg för att stödja CI/CD?
  • Hur hanteras konfigurationen av mellanlagrings- och produktionsmiljöer för programmet?
  • Har verktygskedjan 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 organisationen för att fastställa vilka områden dina kollegor tror kommer att ändras 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 att släppa nya versioner.

Tänk på följande faktorer:

  • Kan tjänsten distribueras oberoende av varandra?
  • Följer tjänsten DDD-principer?
  • Följer tjänsten SOLID-principer?
  • Är databasen privat för tjänsten?
  • Har du skapat tjänsten med hjälp av chassimönstret 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å. Programmets prestanda, tillgänglighet och skalbarhet påverkas om infrastrukturen inte är korrekt konfigurerad eller om rätt tjänster eller komponenter inte används. Ibland skapas ett program med alla föreslagna metoder och procedurer, men infrastrukturen är otillräcklig. Detta resulterar i dåliga prestanda och underhåll.

Tänk på dessa faktorer när du utvärderar infrastrukturens beredskap:

  • Säkerställer infrastrukturen skalbarheten för de tjänster som distribueras?
  • Stöder infrastrukturen etablering via skript som kan automatiseras via CI/CD?
  • Erbjuder distributionsinfrastrukturen ett serviceavtal för tillgänglighet?
  • Har du en haveriberedskapsplan (DR) och rutinmässiga detaljgranskningsscheman?
  • Replikeras data till olika regioner för DR?
  • Har du en plan för säkerhetskopiering av data?
  • Dokumenteras distributionsalternativen?
  • Övervakas distributionsinfrastrukturen?
  • Stöder distributionsinfrastrukturen självåterställning av tjänster?

Utvärdera lanseringscykler

Mikrotjänster är anpassningsbara för att förändra och dra nytta av flexibel utveckling för att förkorta lanseringscykler och ge kunderna mer värde. Tänk på dessa faktorer när du utvärderar dina lanseringscykler:

  • Hur ofta skapar och släpper du program?
  • Hur ofta misslyckas dina versioner efter distributionen?
  • Hur lång tid tar det att återställa eller åtgärda problem efter ett avbrott?
  • Använder du semantisk versionshantering för dina program?
  • Underhåller du olika miljöer och sprider samma version i en sekvens (till exempel först till mellanlagring och sedan till produktion)?
  • Använder du versionshantering för dina API:er?
  • Följer du rätt versionsriktlinjer för API:er?
  • När ändrar du en API-version?
  • Vad är din metod för att hantera API-versionshantering?
    • Versionshantering av URI-sökväg
    • Versionshantering av frågeparameter
    • Versionshantering av innehållstyp
    • Versionshantering av anpassat sidhuvud
  • Har du en övning 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 få tillförlitlig och pålitlig kommunikation måste du välja ett lämpligt kommunikationsprotokoll.

Ta hänsyn till följande faktorer:

  • Följer du en API-första metod, där API:er behandlas som förstklassiga medborgare?
  • Har du långkedjeåtgärder, där flera tjänster kommunicerar i ordning över ett synkront kommunikationsprotokoll?
  • Har du övervägt asynkron kommunikation någonstans i systemet?
  • Har du utvärderat meddelandekötekniken och dess funktioner?
  • Förstår du dataflödet för meddelanden som tjänster tar emot och bearbetar?
  • Använder du direkt kommunikation från klient till tjänst?
  • Behöver du spara meddelanden på meddelandekönivå?
  • Använder du mönstret Materialiserad vy för att hantera mikrotjänsters pratsamma beteende?
  • Har du implementerat Retry, Circuit Breaker, Exponential Backoff och Jitter för tillförlitlig kommunikation? Ett vanligt sätt att hantera detta är att använda ambassadörsmönstret.
  • Har du 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 när det gäller 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, falska svar och så vidare kan du göra det på API-gatewaynivå utan att göra några ändringar i tjänsterna.

Ta hänsyn till följande faktorer:

  • Används tjänsterna direkt av klienter?
  • Finns det en API-gateway som fungerar som en fasad för alla tjänster?
  • Kan API-gatewayen konfigurera principer som kvotgränser, simulera svar och filtrering av IP-adresser?
  • Använder du flera API-gatewayer för att tillgodose behoven hos olika typer av klienter, till exempel mobilappar, webbappar och partner?
  • Tillhandahåller din API-gateway en portal där klienter kan identifiera och prenumerera på tjänster, till exempel en utvecklarportal i Azure API Management?
  • Tillhandahåller din lösning L7-belastningsutjämning eller WAF-funktioner (Web Application Firewall) tillsammans med API-gatewayen?

Utvärdera transaktionshantering

Distribuerade transaktioner underlättar körningen av flera åtgärder som en enda arbetsenhet. I en arkitektur för mikrotjänster delas systemet upp i flera tjänster. Ett enskilt affärsanvändningsfall hanteras av flera mikrotjänster 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 och så vidare tills alla transaktioner har slutförts eller återställts, beroende på om transaktionen lyckas.

Ta hänsyn till följande:

  • Hur många distribuerade transaktioner finns det i systemet?
  • Hur hanterar du distribuerade transaktioner? Utvärdera användningen av Saga-mönstret med orkestrering eller koreografi.
  • Hur många transaktioner omfattar flera tjänster?
  • Följer du en ACID- eller BASE-transaktionsmodell för att uppnå datakonsekvens och integritet?
  • Använder du långlänkningsåtgärder för transaktioner som omfattar flera tjänster?

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.

Tänk på följande faktorer:

  • Använder du en tjänstmall för att starta ny tjänstutveckling?
  • Följer du metoden för tolvfaktorappen och använder en enda kodbas för mikrotjänster, isolerar beroenden och externaliserar konfigurationen?
  • Har du känslig konfiguration i nyckelvalv?
  • Containeriserar du dina tjänster?
  • Känner du till kraven 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 med traditionella program.

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

  • Har du en strategi för att distribuera dina tjänster?
  • Använder du moderna verktyg och tekniker för att distribuera dina tjänster?
  • Vilken typ av samarbete krävs mellan teamen när du distribuerar tjänster?
  • Etablerar du infrastruktur med hjälp av Infrastruktur som kod (IaC)?
  • Använder du DevOps-funktioner för att automatisera distributioner?
  • Sprider du samma versioner till flera miljöer, enligt tolvfaktorappmetoden?

Utvärdera din värdplattform

Skalbarhet är en av de viktigaste fördelarna med mikrotjänstarkitekturer. Det beror på att mikrotjänster mappas till affärsdomäner, så att varje tjänst kan skalas separat. Ett monolitiskt program distribueras som en enda enhet på en värdplattform och måste skalas holistiskt. Det resulterar i stilleståndstid, distributionsrisk och underhåll. Ditt monolitiska program kan vara väl utformat med komponenter som hanterar enskilda affärsdomäner. Men på grund av bristen på processgränser blir det svårare att bryta mot principerna om enskilt ansvar. Detta resulterar så småningom i spaghettikod. Eftersom programmet består och distribueras som en enda värdprocess är skalbarheten svår.

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 är tillgängliga för att hantera dessa utmaningar genom att tillhandahålla funktioner som autoskalning, elastisk etablering, högre tillgänglighet, snabbare distribution och enkel övervakning.

Tänk på följande faktorer:

  • Vilken värdplattform använder du för att distribuera dina tjänster (virtuella datorer, containrar, serverlösa)?
  • Är värdplattformen skalbar? Har den stöd för autoskalning?
  • Hur lång tid tar det att skala din värdplattform?
  • Förstår du de serviceavtal som olika värdplattformar tillhandahåller?
  • Stöder din värdplattform haveriberedskap?

Utvärdera övervakning av tjänster

Övervakning är en viktig del av ett mikrotjänstbaserat program. Eftersom programmet är indelat i ett antal tjänster som körs oberoende av varandra kan felsökningsfel vara skrämmande. 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.

Tänk på följande faktorer:

  • Övervakar du dina distribuerade tjänster?
  • Har du en loggningsmekanism? Vilka verktyg använder du?
  • Har du en distribuerad spårningsinfrastruktur på plats?
  • Registrerar du undantag?
  • Har du koder för affärsfel för snabb identifiering av problem?
  • Använder du hälsoavsökningar för tjänster?
  • Använder du semantisk loggning? Har du implementerat viktiga mått, tröskelvärden och indikatorer?
  • Maskerar du känsliga data under loggningen?

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 rotorsaken till ett problem, utvärdera effekten och fastställa 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 senare försöka utföra transaktionen igen. För att framtvinga idempotens kommer endast tjänster som inte har korrelationstoken att hantera begäran.

Om du till exempel har en lång kedja av åtgärder som omfattar många tjänster kan det vara enklare att skicka en korrelationstoken till tjänster om någon av tjänsterna misslyckas under en transaktion. Varje tjänst har vanligtvis en egen databas. Korrelationstoken sparas i databasposten. Vid en transaktionsrepris ignorerar tjänster som har den specifika korrelationstoken i sina databaser begäran. Endast tjänster som inte har token hanterar begäran.

Tänk på följande faktorer:

  • I vilket skede tilldelar du korrelationstoken?
  • Vilken komponent tilldelar korrelationstoken?
  • Sparar du korrelationstoken i tjänstens databas?
  • Vilket format har korrelationstoken?
  • Loggar du korrelationstoken och annan information om begäran?

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

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 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.

Tänk på följande faktorer:

  • Använder du ett ramverk för mikrotjänsters chassi?
  • Använder du Dapr för att interagera med övergripande problem?
  • Är ditt chassiramverksspråk agnostiskt?
  • Är ditt chassiramverk allmänt, så det stöder alla typer av program? Ett chassiramverk får inte innehålla programspecifik logik.
  • Tillhandahåller chassiramverket en mekanism för att använda de valda komponenterna eller tjänsterna efter behov?

Utvärdera din metod för programtestning

Traditionellt utförs testning när utvecklingen har slutförts och programmet är redo att distribueras till användargodkännandetestning (UAT) och produktionsmiljöer. Det finns för närvarande en förändring i den här metoden, vilket flyttar testningen tidigt (till vänster) i livscykeln för programutveckling. Skift-vänster-testning ökar kvaliteten på program eftersom testning görs 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 använda andra analysverktyg för att upptäcka problem. När du har distribuerat programmet kan du använda verktyg som DAST (Dynamic Application Security Testing) för att testa det när det finns. Funktionell testning, kaostestning, intrångstestning och andra typer av tester sker senare.

Tänk på följande faktorer:

  • Skriver du testplaner som täcker hela utvecklingslivscykeln?
  • Inkluderar du testare i kravmöten och i hela livscykeln för programutveckling?
  • Använder du testdriven design eller beteendedriven design?
  • Testar du användarberättelser? Inkluderar du acceptanskriterier i dina användarberättelser?
  • Testar du din design med hjälp av verktyg som Microsoft Threat Modeling?
  • Skriver du enhetstester?
  • Använder du statiska kodanalysverktyg eller andra verktyg för att mäta kodkvaliteten?
  • Använder du automatiserade verktyg för att testa program?
  • Implementerar du Secure DevOps-metoder ?
  • Utför du integreringstestning, programtestning från slutpunkt till slutpunkt, belastnings-/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. Detta system skulle påverka det övergripande systemets flexibilitet och potentialen att införa implementeringsavvikelser mellan tjänster.

Säkerhetsproblem hanteras vanligtvis av API-gatewayen och programbrandväggen. 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 snarare än det övergripande säkerhetsproblemet.

Tänk på följande faktorer:

  • Krävs autentisering och auktorisering för tjänsten?
  • Använder du en API-gateway för att verifiera token och inkommande begäranden?
  • Använder du SSL eller mTLS för att tillhandahålla säkerhet för tjänstkommunikation?
  • Har du nätverkssäkerhetsprinciper på plats för att tillåta nödvändig kommunikation mellan tjänster?
  • Använder du brandväggar (L4, L7) i tillämpliga fall för att tillhandahålla säkerhet för intern och extern kommunikation?
  • Använder du säkerhetsprinciper i API Gateway för att styra trafik?

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg