Microservices-arkitektur · Mindmaps

Microservices-arkitektur · Mindmaps

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

Sådan læser du mindmappet

• Begynd ved emnet i midten, og følg en farvet gren til de tilhørende idéer.
• Buede linjer viser sammenhænge; pile bruges, når retningen har betydning.

Clients & gateway

Denne gren samler “Web and mobile clients”, “The gateway is the single entry point: it routes each request to the right service, handles authentication and often aggregates responses from several services.”.

Independent services

Denne gren samler “Orders service”, “Payments service”, “Teams deploy and scale services independently”, “Users service”.

Messaging

Denne gren samler “Services communicate by publishing events rather than calling each other directly — so one service's change or outage never blocks another.”.

Owned data

Denne gren samler “The defining rule of microservices: no shared schema. Each service's data is private to it, which is what allows teams to deploy independently.”.

Observability

Denne gren samler “Metrics, logs and traces feed one view”.

Forbindelser på tværs

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.

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. Tilpas emnet i midten

   Giv emnet et navn, der passer til dit projekt eller din undervisning.

2. Udbyg grenene

   Rediger idéerne, og tilføj eksempler eller noter.

3. Forbind beslægtede idéer

   Tegn forbindelser på tværs af grene; brug kun pile, når retningen betyder noget.

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.

Rediger dette mindmap i QueryChart

Åbn mindmappet på et redigerbart lærred. Flyt idéer, tilføj grene, og tegn forbindelser.

Rediger dette mindmap i QueryChart