Cloud-deploymentarkitektur · Mindmaps

Cloud-deploymentarkitektur · 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.

Users & edge

Denne gren samler “Users reach the service through the edge”, “Static assets are served from edge locations near the visitor, cutting latency and shielding the origin from repeat downloads.”.

Traffic routing

Denne gren samler “The load balancer is the front door to the compute tier: it terminates the public connection and forwards each request to a healthy instance.”.

Application

Denne gren samler “Instances are added and removed automatically from traffic — the deployment scales out horizontally instead of buying a bigger server.”, “App instances serve requests”, “Hot data lives in memory, so the database only sees the requests that actually need it. The cache is disposable — losing it slows the system, it does not break it.”.

Data

Denne gren samler “Primary database stores the source of truth”, “Read replicas spread load; point-in-time backups and cross-region copies are the recovery story for the one thing that cannot be rebuilt.”.

Resilience

Denne gren samler “Metrics, logs and alerts cover every tier — a spike in error rate or latency is what triggers the auto-healing and rollback decisions.”, “The deployment scales and self-heals”.

Forbindelser på tværs

Robusthed er lagdelt: CDN, load balancer, autoskalering, cache, replikaer, overvågning: hvert lag beskytter det bagved.

Datalaget fejler anderledes og har brug for sine egne kontroller: replikaer til belastningen, backups til genopretningen.

Load balanceren er hoveddøren; autoskaleringen afgør, hvor mange døre der er.

Cachen kan undværes: mister du den, bliver systemet langsommere, det går ikke i stykker.

Overvågningen er det, der lukker løkken: en alarm udløser beslutningerne om skalering, rollback og genopretning.

Key relationships and takeaways

• Robusthed er lagdelt: CDN, load balancer, autoskalering, cache, replikaer, overvågning: hvert lag beskytter det bagved.
• Datalaget fejler anderledes og har brug for sine egne kontroller: replikaer til belastningen, backups til genopretningen.
• Load balanceren er hoveddøren; autoskaleringen afgør, hvor mange døre der er.
• Cachen kan undværes: mister du den, bliver systemet langsommere, det går ikke i stykker.
• Overvågningen er det, der lukker løkken: en alarm udløser beslutningerne om skalering, rollback og genopretning.

When to use this visual

• At undervise i en cloud-deployments anatomi, før et team designer sit første produktionsmiljø.
• At gennemgå en arkitektur for huller i robustheden: et lag uden redundans er et single point of failure, som lærredet afslører.
• At forankre en diskussion om cloud-omkostninger: hvert lag er en beslutning om, hvad I vil betale for redundans.

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 en cloud-deploymentarkitektur?

Det er designet af, hvordan en tjeneste kører i skyen: trafikken kommer ind via edge (CDN), en load balancer fordeler den, en autoskalerende gruppe af instanser betjener den, et datalag gemmer den, og overvågningen holder øje med det hele. Arkitekturens definerende egenskab er robusthed: ingen enkelt komponents svigt tager tjenesten ned, fordi hvert lag er redundant og justerer sig selv.

Hvorfor behandles datalaget anderledes end resten?

Fordi de tilstandsløse lag (instanser, caches) kan bygges op eller erstattes med det samme, mens databasen rummer den sandhedskilde, der ikke kan genskabes. Den har brug for sine egne kontroller: replikaer til at fordele læsebelastningen, point-in-time-backups og kopier på tværs af regioner til genopretning, og en fastlagt procedure for failover. Diagrammet giver datalaget sin egen bane, fordi dets fejlmåder og dets kontroller er anderledes end lagene ovenover.

Hvad betyder »autoskalering«, og hvorfor er det vigtigt?

Autoskalering tilføjer eller fjerner applikationsinstanser automatisk ud fra målt efterspørgsel: typisk CPU, hukommelse eller kølængde. Det er vigtigt, fordi det gør kapacitet fra et gæt til en styringssløjfe: systemet køber mere kapacitet, når der er travlt, og giver slip på den igen, når der ikke er, og det erstatter en fejlet instans uden menneskelig handling. Den selvjustering er en stor del af det, der gør en cloud-deployment robust.

Hvordan passer caching og overvågning ind i arkitekturen?

Cachen ligger mellem applikationen og databasen: varme data leveres fra hukommelsen, så databasen kun ser de forespørgsler, der reelt har brug for den. Overvågningen er sensorlaget på tværs af hvert lag: metrikker, logs og alarmer, og det er den, der udløser de øvrige robusthedsmekanismer: et udsving i fejl starter et rollback, en stigning i belastningen udløser skalering, og en fejlet instans bliver erstattet. Uden overvågning kører resten af arkitekturen i blinde.

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