您如何使用 strangler-fig 模式将 monolith 迁移到 microservices？

Question

Accepted Answer

**strangler-fig 模式**逐步进行迁移：您使用路由层包装 monolith，一次将一个功能提取到服务中，并将流量重定向到它——直到 monolith 被"扼杀"。**不需要大爆炸式重写**。

## 它如何工作

```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
```

## 选择首先提取的内容

```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
```

## 处理共享数据

最困难的部分是数据库。提取服务的表，然后使用事件或反腐层来打破共享数据库耦合，通常通过**branch-by-abstraction**技术在两者都运行的情况下进行。

## 权衡

```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
```

## 为什么这很重要

大爆炸式重写往往会失败——它们会冻结数个月的功能工作，并执行一次风险很高的全面切换。

strangler-fig 使系统在整个过程中保持活跃和可发布，让您可以在任何时刻停止或重新排列优先级，并强制您从运行系统中发现真实的服务边界，而不是提前猜测。