Microservices-arkitektur — mange små tjenester, ét system

Microservices-arkitektur — mange små tjenester, ét system

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Læs først den venstre kolonne oppefra og ned: klienter til gateway til tjenester — det er forespørgslens vej.
• Følg pilene ud fra hver tjeneste: til message bussen, til dens egen database og til observabiliteten.
• Banegrupperne til højre er systemets fælles infrastruktur — beskeder, data og observabilitet — og derfor peger hver tjeneste ind i dem.

Forespørgslens vej

»Web- og mobilklienter« starter forløbet, og »API-gateway router og samler svar« er det eneste indgangspunkt — den router hver forespørgsel til den rigtige tjeneste, håndterer autentificering og samler ofte svar fra flere tjenester. Gatewayen er den ene komponent, hver klient ser, og derfor ligger den mellem klientlaget og tjenesterne.

Tjenesterne

»Ordretjeneste«, »Brugertjeneste« og »Betalingstjeneste« er de enheder, der deployes uafhængigt. Hver af dem ejes af sit eget team og udsendes i sin egen kadence. Diagrammet forbinder hver tjeneste til message bussen — tjenester kommunikerer med hændelser frem for direkte kald — og til dens egen database, fordi det at eje sine data er dét, der gør en tjeneste mulig at deploye uafhængigt.

Den fælles infrastruktur

»Message bus afkobler tjenester« lader en tjeneste publicere en hændelse uden at vide, hvem der forbruger den. »Hver tjeneste ejer sin egen database« er den regel, der forhindrer kobling gennem fælles tilstand. »Metrikker, logs og traces samles i ét overblik« er den observabilitet, der gør et system med mange tjenester driftsmæssigt fornuftigt — uden den er en fejl usynlig på tværs af grænserne. De tre banegrupper er både prisen for og gevinsten ved arkitekturen.

Key relationships and takeaways

• Hver tjeneste kan deployes uafhængigt — den egenskab, alt andet i arkitekturen findes for at beskytte.
• Tjenester kommunikerer gennem message bussen og ejer deres egne databaser; fælles tilstand er antimønsteret.
• API-gatewayen er systemets eneste hoveddør; klienter taler aldrig direkte med tjenesterne.
• Uafhængigheden skal betales med observabilitet — mange tjenester er kun til at styre, når ét overblik dækker dem alle.
• Microservices orkestrerer de containere, Docker pakker — de to diagrammer hænger sammen.

When to use this visual

• At lære et team, hvorfor microservices findes, og hvad afvejningerne faktisk er, før de tager dem i brug.
• At dokumentere et eksisterende systems tjenestegrænser, beskedtopics og dataejerskab til onboarding.
• At gennemgå for antimønstre: en fælles database eller en tjeneste, der kalder en anden tjeneste direkte, er en lækket grænse.

Sådan fungerer det

1. Omdøb tjenesterne til jeres eget system

   Erstat Ordre, Bruger og Betaling med jeres faktiske tjenester, og tilføj dem, de generiske tre mangler, hver som sin egen boks i banegruppen »Tjenester«.

2. Navngiv jeres beskedtopics

   Notér på message bussen de reelle hændelser, jeres tjenester publicerer og abonnerer på, så afkoblingen bliver konkret frem for blot hævdet.

3. Kortlæg dataejerskabet

   På hver tjenestes pil til sin database noterer du det faktiske lager (PostgreSQL, en cache, et søgeindeks), og hvad det ejer, så du kan tjekke, at reglen om én database pr. tjeneste holder.

4. Tilføj grenene for fejl og skalering

   Indsæt de reelle veje — en tjenestes retry og circuit breaker på bussen, en udskaleret replika af en tjeneste under pres — der hver ender i en eksplicit tilstand.

Ofte stillede spørgsmål

Hvad er microservices-arkitektur?

Det er en arkitekturstil, hvor en applikation bygges af mange små tjenester, der hver har ansvaret for én forretningsevne, deployes uafhængigt og ejer sine egne data. Tjenesterne kommunikerer over et netværk — typisk HTTP og en message bus — frem for at dele hukommelse eller database. Fordelene er uafhængig deployment og teamautonomi; omkostningerne er netværkskompleksitet og behovet for observabilitet.

Hvorfor ejer hver microservice sin egen database?

Fordi fælles data er den kobling, der ødelægger uafhængig deployment. Læser og skriver to tjenester den samme tabel, kan de ikke ændre skema, skalere eller deploye uden at koordinere. At eje sit eget datalager er dét, der lader en tjeneste udvikle sig og skalere i sit eget tempo — den regel, banegruppen »Hver tjeneste ejer sin egen database« i diagrammet håndhæver.

Hvilken rolle spiller API-gatewayen i microservices?

Gatewayen er systemets eneste indgangspunkt. Den router forespørgsler til den rigtige tjeneste, håndterer tværgående hensyn som autentificering og rate limiting og kan samle svar fra flere tjenester til ét. Klienter taler med gatewayen, aldrig direkte med de enkelte tjenester, og det holder tjenestetopologien fri til at ændre sig bagved.

Hvornår skal du IKKE bruge microservices?

Når systemet er lille, eller teamet er lille. Microservices bytter arkitektonisk kompleksitet — netværksfejl, distribuerede transaktioner, observabilitet — for uafhængig deployment, og den byttehandel betaler sig først, når et team er stort nok til, at uafhængig deployment er den bindende begrænsning. Mange teams' problemer løses af en velmodulariseret monolit, som er emnet for diagrammet om monolitisk arkitektur.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis dette microservices-lærred som dit eget diagram, omdøb tjenesterne til jeres eget system, og tegn jeres reelle grænser.

Redigér dette diagram i QueryChart (FlowJam)