Wie migrieren Sie einen Monolithen zu Microservices mit dem Strangler-Fig-Muster?

Question

Accepted Answer

Das **Strangler-Fig-Muster** migriert schrittweise: Sie umhüllen den Monolithen mit einer Routing-Schicht, extrahieren jeweils eine Fähigkeit in einen Service und leiten den Traffic dorthin um – bis der Monolith "abgewürgt" ist. Es gibt **keinen Big-Bang-Rewrite**.

## Warum es wichtig ist

```text
Step 1: route all traffic through a facade/proxy to the monolith
Step 2: extract ONE capability → new service
Step 3: route just that path to the new service
Step 4: repeat; delete that code from the monolith

Client ─▶ [ Proxy ] ─┬─▶ /orders  ─▶ NEW Orders service
                       └─▶ everything else ─▶ Monolith
```

## Auswahl dessen, was zuerst extrahiert werden soll

```text
✓ A bounded context with clear boundaries
✓ Something that needs independent scaling or deploys
✓ A part with few inbound dependencies (low risk)
✗ Don't start with the tangled core
```

## Umgang mit gemeinsamen Daten

Der schwierige Teil ist die Datenbank. Extrahieren Sie die Tabellen des Service, dann unterbrechen Sie die Kopplung der gemeinsamen DB mit Events oder einem Anti-Corruption-Layer, oft über die **Branch-by-Abstraction**-Technik, während beide laufen.

## Kompromisse

```text
✓ Low risk — small, reversible steps, always shippable
✓ Value early, learn the seams as you go
✗ Slow; you run a hybrid system for a long time
✗ Temporary duplication and routing complexity
```

## Por qué es importante

Big-Bang-Rewrites schlagen bekanntlich fehl – sie frieren Feature-Arbeiten monatelang ein und führen zu einer riskanten Umstellung auf einmal.

Das Strangler-Fig-Muster hält das System die ganze Zeit über live und releasbar, ermöglicht es Ihnen, jederzeit zu stoppen oder Prioritäten zu ändern, und zwingt Sie, echte Service-Grenzen aus dem laufenden System zu erkennen, anstatt sie im Voraus zu erraten.