Monolitisk arkitektur — én deploybar enhed, én database

Monolitisk arkitektur — én deploybar enhed, én database

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

• Følg forespørgslen ind fra klienten, ned gennem de tre moduler, ind i den fælles database og ud igen — én tur frem og tilbage gennem én proces.
• Modulerne ligger inde i banegruppen »Monolitisk applikation«, fordi de deler en proces og et deployment; netop den indeslutning er definitionen på en monolit.
• Den sidste boks er pointen: skaleringsvejen går til siden og kopierer hele applikationen.

Forespørgslens vej gennem én proces

»Klienten sender en forespørgsel« fører ind i »Forespørgslen rammer den ene deploybare applikation«, derefter »UI-modulet router og gengiver«, »Forretningslogikmodulet behandler den« og »Dataadgangsmodulet forespørger databasen« — alt sammen inde i den ene bane »Monolitisk applikation«. De tre moduler er tegnet stablet for at vise, at de deler hukommelse, proces og deployment: intet ved dem kan deployes hver for sig.

Den fælles database

»Én fælles database gemmer alt« er monolittens anden definerende egenskab. Alle moduler læser og skriver det samme skema, og det gør joins og transaktioner ligetil — grunden til, at en monolit er så produktiv tidligt. Banegruppen »Database« ligger uden for »Monolitisk applikation«, fordi den er en separat proces, men den er delt: koblingen ligger i det skema, hvert modul afhænger af.

Skaleringsloftet

»Svaret vender tilbage gennem de samme moduler« afslutter turen, og »Skalering betyder at kopiere hele applikationen« er dommen. En travl funktion tvinger hele kodebasen og dens connection pool over på en anden server og spilder kapacitet på de dele, der ikke er travle. Det er den ineffektivitet og ikke nogen teknisk fejl, der til sidst motiverer opdelingen i microservices.

Key relationships and takeaways

• Alle moduler deler én proces, én kodebase og ét deployment — netop den indeslutning er definitionen.
• Den fælles database kobler hvert modul til ét skema.
• Forespørgsler rejser gennem hvert modul i én tur frem og tilbage — der er intet separat tjenestekald.
• Skaleringen er grovkornet: hele applikationen kopieres, uanset hvilken funktion der er travl.
• Monolittens udviklingshastighed er reel; skaleringsloftet er det, den bytter væk.

When to use this visual

• At forklare, hvorfor et teams applikation er svær at skalere, selv om den er let at udvikle.
• At undervise i den kontrast, der gør microservices forståelige — opdelingen giver først mening op mod monolittens loft.
• At dokumentere strukturen i et legacy-system, før I planlægger, hvordan det skal deles op.

Sådan fungerer det

1. Omdøb modulerne til jeres egen kodebase

   Erstat UI, forretningslogik og dataadgang med jeres faktiske lag og moduler, og tilføj dem, de generiske tre mangler.

2. Markér de reelle flaskehalse i skaleringen

   Notér på den sidste boks den faktiske funktion eller forespørgsel, der tvinger jeres skalering, og den kapacitet, der spildes ved at kopiere hele applikationen.

3. Tegn kandidaterne til udtrækning

   Tilføj en stiplet grænse omkring det modul, der er den bedste kandidat til at blive en tjeneste, med en note om, hvilken kobling der skal skæres over.

4. Henvis til alternativet med microservices

   Når kandidaterne til udtrækning er markeret, kan du henvise til diagrammet om microservices for at sammenligne målarkitekturen side om side.

Ofte stillede spørgsmål

Hvad er en monolitisk arkitektur?

En monolit er en applikation, hvis UI, forretningslogik og dataadgang bygges, deployes og skaleres som én enhed — én kodebase, der producerer ét deploybart artefakt, og som kører mod en fælles database. Diagrammet viser forespørgslen rejse gennem alle tre moduler inde i én applikationsbane, fordi netop den indeslutning er definitionen.

Hvorfor starter teams med en monolit?

Fordi en monolit for de fleste teams og i det meste af en applikations levetid er den hurtigste vej til at få noget ud. Der er intet netværk mellem modulerne, det fælles skema gør joins og transaktioner enkle, og deployment er ét artefakt. Diagrammets boks om den fælles database siger det direkte — byttehandlen bliver først negativ, når uafhængig skalering eller teamautonomi bliver den bindende begrænsning.

Hvad er det største problem ved en monolit?

Skaleringsloftet og koblingen. Skalering betyder at kopiere hele applikationen, så én travl funktion spilder kapacitet på alt det andet, og hver ændring rører en kodebase og et skema, som alle afhænger af. Efterhånden som teamet og kodebasen vokser, gør de to virkninger deployment langsommere og tvinger koordinering frem — de betingelser, hvorunder teams begynder at trække tjenester ud.

Hvordan bliver en monolit til microservices?

Gradvist, ved at trække én evne ud ad gangen. Første skridt er at finde et modul, der kan stå alene — med sine egne afgrænsede data — og derefter give det sin egen database, et API og til sidst uafhængigt deployment. Diagrammets trin om kandidater til udtrækning modellerer præcis det: markér modulet, skær koblingen over, og del op. Fejlen er at skrive hele monolitten om på én gang, og det er sådan, migreringer mislykkes.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis dette monolit-lærred som dit eget diagram, omdøb modulerne til jeres egen kodebase, og tegn jeres flaskehals i skaleringen.

Redigér dette diagram i QueryChart (FlowJam)